Have Opinions Instead of Preferences

A preference: is not a definition or declaration.

- An opinion: On the other hand, extends beyond one’s personal jurisdiction. An opinion,
more often than not, is something we seek to assert or enforce on others, for
whatever reason
“If there’s a choice between setting a value to A or B and you always choose A, why not just
make A the main, unsettable, unchangeable choice? If you think A is the best decision, why
even let people choose B?”

- Mike Rundle
- Genie Effects
- Scale Effects

You are trained to make these decisions, and you have the necessary information to do so
correctly Your users probably don’t.

What I’m Not Talking About

Terms:
Settings
A global change the user can make to your product’s function or behavior.

Configuration
Settings that are necessary for your product to work correctly, such as the screen resolution
or network settings.

Preferences
Settings that change your product’s behavior and are not strictly necessary but that some
people may prefer to be set differently.

Personalization
Settings that have purely visual effects and do not change the actual behavior of your
product.

It’s not always completely clear whether a setting should be considered a configuration,
preference, or personalization. But thinking about settings in terms of these three categories
will help you make better decisions about what to keep and what to throw out.

Why Preferences Are Bad?

Preferences make your product unnecessarily complex in various ways

First, since people will look in your product’s settings area for things that they need to be
able to change, every needless choice you offer makes it harder for them to find what they’re
looking for. Every preference they have to look through makes the one they actually need a
little bit harder to find, and the search a little bit more frustrating.

Second, preferences make your product inconsistent by introducing modes.

Third, preferences make your product harder to use for the people who pick the wrong
choice.

Fourth, leaving the choice up to the user also means you’ll have to support several different
ways of using your product for the rest of its lifetime.

How To Avoid Preferences

- Say no to your users

- Say no to yourself
- Be consistent
- Run a usability test
- Have opinions
- Have implicit preferences

If You Can’t Avoid Preferences

Make sure that the default choice for each preference works well for a majority of your users.
Most people stick with the default values and never change them.
Speed
“ Speed is more than a feature. Speed is the most important feature. If your application slow,
people won’t use it” - Fred Wilson

Speed in Usability Test

In UT, speed and responsiveness are less likely to show obviously and measured.
Since people’s goal is to test your product while customers want to use it and might abandon
it.
Power users something have a sympathetic eye since they also see the challenges but for
mainstream users, if something is slow, they’re just gone.

Responsiveness
0.1 second
- How responsive your product is
- If an action takes less than 0.1 second to finish, the user perceives it as instanta
neous.
- If it takes less than 1 second to finish, the user no longer perceives it as instanta
neous but will not lose track of what is going on.
- If an action takes longer than a second, the chance increases that the user gets dis
tracted while waiting for it to finish.

Responsiveness
- Continuous interations
- Performance is especially important, the response must be immediate and fluid.
- UI must keep up with the user's actions at a high frame rate.
- This creates the impression of interacting with actual physical objects & make users
consciously noticing that they are giving commands to a computer.
- Input lag or choppy animations can destroy the user's mental model of your product
and can be extremely irritating.

Progress Feedback
Instant feedback
- If an action takes longer than 0.1 second, provide some kind of feedback. The type of
feedback depends on:
+ How long the action takes
+ What kind of action it is
- Goal is not to tell how long the action will take, make it obvious that the computer has
received the user's command and is working on it. User might think the app system
didn't respond in their first try and repeat edly clicking it.

Progress Feedback
Processing Feedback
- Add some short explanatory text or even a little animation representing the active
task near the progress bar, giving the user some indication of what is currently going
on, why the whole process is taking so long, and can help make them more
comfortable waitting.
 - if a task takes a long time, people will focus on something else and might forget the
task. You can use audio feedback to notify them.
Perceived speed
speed is perception
- people are not going to measure your product’s response time with stopwatches.
- what really counts isn’t how long an action takes in seconds and milliseconds but
how your user perceive your product’s speed

Perceived speed
improve speed in design
- Start showing partial results as soon as possible
- Make sure that actions that take a long time dont block your product’s user interface.
- Add simple ripple effect can make the progress bar appear to move faster

Slowing down
- Slow products are annoying, but sometimes, things can be too fast: for example,
scrolling. or the application was simply too fast, the workflow took a fraction of a
second.
- The slow and obvious part reassured users that somethong subtantial had
happened. and it makes people view the process is more credible.

Takeaway Points
Responsiveness and speed are extremely important, while Usability tests don't always
reveal these problems.
- Actions should take less than 0.1s.
- For long actions, show some indicator that the app is working. (where the user's
focus is)
- Perceived speed is more important than actual speed.
- In some case, artificially limiting the speed can improve the user experience.

Avoiding Features
- As you add new features, your product can quickly grow from its original state - an
elegant solution to a well-defined problem - into a byzantine mess of unrelated
functions.
- “A product could sold many problems is meaningless if its user have trouble figuring
out how to find the features that solve their particular problem.”
Remember your User ’s Goals
Takeaway Points
Adding more features can make your product more desirable to people who need those
features but less desirable to the people who don’t. Usually, for any given feature, the
second group is the large one.

• Use the “The Five Whys” to evaluate user feedback and find the root of the problem.
• Instead of adding a new feature, improve an existing one.
• try to add features that solve several problems at once and perhaps allow you to remove
existing feactures from your product.
• Consider the cost of a new feature as well as its benefits
• Focus on features that make your product better without increasing user interface
complexity.
• Do proper user research before adding new features to find out whether people really need
the feature and what they need for.
• If you implement every “I just need this one feature” request, you end up with a product
where most features are unpopular.

Don’t have to be expensive!

- Basic Goal is to observe users

- to identify areas of your user interface that might be difficult for people to navigate.
- Doing poor tests is still a lot better than doing no tests at all.
-

How often to test?

- Usability Tests is like jogging
- The more you do it, the easier it gets and the better you become at it
- Spending a few days each month (sometime it is not easy)
- Alternatively, set aside half a day each week.
How many Testers?
- Jakob Nielsen famously wrote that only five (5) users to find almost all the usability
problems
- In half a day, doing only one test with only one person each week. Of course, given
sufficient time, budget, and helpers testing with three to five users offers more insight
- more extensive tests that require more preparation.
- A pretty big investment can result in a pretty meager outcome
Advantages of 1 person
- Easier to find testers since you have to find only one person at a time.
- Remove the overhead
- To match the schedules of several people.
- It’s usually easy to find a date
- that works for two people: the designer and the tester
- The more people participate in, the more complex in scheduling
- Easy to run the whole thing by yourself
Who should test?
 - Typically doesn’t matter much Unless you are designing a product that targets a
very specific group of people
- Even if we do target a particular group testing with people from outside of that group
is reasonable.
- People are surprisingly consistent in how they behave.
- If you have big problems in your design, you’ll probably find them regardless
of who you recruit as a tester the members of this group may not be entirely
homogeneous.
- Certain people will be more experienced with the topic than others.
- Cultural background can be matter a lot.
Accessibility?
Tests with people with
- poor eyesight,
- older,
- generally who have disabilities
Uncover accessibility issues
- that would have gone unnoticed.
How to find Testers?
Many different avenues
- Friends and relatives
- Easiest way, but don’t over do
- by using the same people over and over
Don’t use workmates for testing
- They tend to have at least some level of insight into your product
- Normal users won’t have – it’s better
Professional recruiting agencies
- Definitely compare costs before committing
- May not get people who’ve got characteristics what you are looking for
Through your website
- likely to get existing users of your product, it’s the downside
Through a local newspaper
- Work well

Session 20 A/B Testing

A/B Testing

- test different fully implemented designs.

- can find out which one of two (or more) designs works best.
Multivariate Testing
- A version of A/B Testing
- test different versions of individual parts of your design at the same time.
- running a number of concurrent A/B tests on small parts of your design
- avoid doing it, Unless you have reasons

When do?
There are two situations:
- You’ve redesigned or rewritten something, and you want to know whether the new
design or the new copy works better than the previous version.
- There are several possible solutions to a problem, and you want to find out which
one works best.
What’s success?
An inherent problem with A/B Testing
What exactly does “works better” mean?
At what point has the user successfully used your product?

What’s Success?
- Sometimes, the answer is obvious.
- For example, in designing a checkout system,
- the system “works” when the user is able to finish the checkout
process.
- Often, however, there is no immediately obvious answer to what constitutes
“success.”
- One way to define “success” is to go back to the very beginning of the design
process
- and think about your users’ goals.
- If you know why they use the product, then you can define
success:
- the product works better if a higher percentage of your
users are able to reach their goals.
- Sometimes, all it takes is to measure
- the percentage of people who click a link on a website
- or the percentage of your website visitors who sign up for your
service.
- Other times, answering this question is more involved.
- How many people who start a task actually finish it?
- The definition of success depends on your product