🍃 Leaf

Don’t Make Me Think

Written by Steve Krug.

Guiding Principles

Don’t make me think

”Krug’s first law of usability.”

People don’t read, people scan, they should be capable of instantly finding what they need without wasting time and effort to figure out where it is, how to use it, or even identifying more options. Webs should be self-explanatory and speak the user’s language. If something is not self-evident, at least it should be self-explanatory.

How we really use the Web

”Scanning, satisficing, and muddling through.”

Sometimes people don’t use the Web the way we expect as designers and developers. People are usually in a hurry. As said before, they don’t read pages, they scan them. We need (or want) to get something done fast. We try to find the closest option that looks relevant to us, even if it’s not the right one.

Most of the time people don’t make an optimal choice, instead people guess and choose the most reasonable option. Usually getting wrong, but, when they’re right, it’s faster, surprising and pleasant.

Sometimes people don’t actually know how things work, they muddle through. It’s not important for them to ignore things, however, if they know, they’ll feel smarter.

Billboard Design 101

”Designing for scanning, not reading.”

Take advantage of conventions

Standards and conventions are the safest solutions (where the things are, how they work, how they look). Innovate only when you know you have a better idea that is clear, self-explanatory, and doesn’t hurt consistency.

Create effective visual hierarchies

Make obvious which things are more important, what things do, and what things are part of. In other words, show visual cues about hierarchy, functionality and relationship.

Break pages up into clearly defined areas

Divide the page into clearly defined areas so users can easily decide which areas to focus on, and what they can ignore.

Make it obvious what’s clickable

On the Web, almost all we can do are clicks. Use visual cues to show what’s clickable, color, shape, underlining, location, and more.

Eliminate distractions

Reduce visual noise. Clamoring for attention, disorganization, and clutter is overwhelming. That leads to lots of noise, not much information, and noise obscures the useful stuff.

Format content to support scanning

Use headings and make them distinctive. Keep paragraphs short, avoid creating a “wall of words.” Use bulleted lists whenever you can. Highlight key terms when appropriate.

Animal, Vegetable, or Mineral?

”Why users like mindless choices.”

People don’t care how many clicks they have to make, but how much they have to think to make them. If you know something is difficult, give some help, guidance should be brief, timely, and unavoidable.

Omit needless words

”The art of not writing for the web.”

By writing less, we reduce the noise level, make the useful content more prominent, and save time for the users. Try to avoid happy talk, small talk, and instructions on your products.

Things You Need to Get Right

Street signs and Breadcrumbs

”Designing navigation.”

Web Navigation 101

The unbearable lightness of browsing

We have to give the missing cues for the user, as while searching on the web we have no sense of scale, direction, and location.

The overlooked purposes of navigation

Navigation:

Web navigation conventions

Follow standards on appearance and location of navigation systems, so people can know what to look for and where to look when they need.

Don’t look now, but I think it’s following us

Persistent navigation (or global navigation) should say:

Persistent navigation usually contains the Site ID, Utilities, Sections, and a Search bar.

Did I say every page?

We need to avoid unnecessary distractions while filling forms, paying on e-commerce, registering, or subscribing. It’s fine to simplify the persistent navigation to ensure that people can finish these activities.

Now I know we’re not in Kansas

Use the Site ID as a sign to let the people know where they are. Usually it will be on the top left corner of the site, that way it will frame the entire page.

The Sections

They are the primary navigation, they can show (while clicking or pointing) the subsections or secondary navigation.

The Utilities

They are even less prominent than the sections. They can help people use the site, usually presented as groups of no more than four elements (other elements would be on the footer).

Some of the most common utility elements are:

Just click your heels three times and say, “There’s no place like home”

Users expect to have access to the Site ID button at any time, so they can reset and go back to the home page no matter how lost they are while navigating.

Stick to the formula of a box and a button labeled as “Search” (or a magnifying glass icon).

Avoid:

Secondary, tertiary, and whatever comes after tertiary

After primary and secondary navigation levels, we often don’t give priority to lower levels.

That happens because of:

Page names, or Why I love to drive in L.A

In L.A.:

Four things about page names:

”You are here”

To counteract the “lost in space” feeling on the Web, we need to highlight the current location on the navigation bar, list, or menu elements.

We can do this by adding cues like:

Breadcrumbs allows users to back up a level or go Home. They’re most useful in large sites with a deep hierarchy, self explanatory, and don’t take up much room.

Best practices:

Three reasons why I still love tabs

Tabs are one of the only few physical metaphors used in UIs, easy to identify and use. Effective when we bring the active one to the front and use a distinctive shape and color to make them “pop” on the screen.

They are:

Try the trunk test

No matter where you are on a Web site, or if you have use it before or not, you should always be able to answer these questions at a glance:

The Big Bang Theory of Web Design

”The importance of getting people off on the right foot.”

Designing the Home page can be complex, here you need to cover all the bases, and, a few other things:

And you have to do it…blindfolded

About the Home page:

The First Casualty of War

As said, we tend to put a lot of things in the Home page, but we can’t. We start filtering and removing things and sometimes we get rid of the most important one, to make it easy to see the big picture.

Questions that a Home page has to answer:

It’s better if we can answer these questions at a glance and with very little effort. The first few seconds you spend on a new Web site are critical, (that’s the Big Bang Theory of Web Design). People often form wrong ideas of what things are and how they work, so they end up creating more misinterpretations.

The Top Four Plausible Excuses for not Spelling Out the Big Picture on the Home Page
  1. ”We don’t need to. It’s obvious”: No, it’s not obvious for everybody.
  2. ”After people have seen the explanation once, they’ll find it annoying”: No, it will not (and should not) be annoying at all.
  3. ”Anybody who really needs our site will know what it is”: No, even the people who need it, may not “get” it if done wrong.
  4. ”That’s what our advertising is for”: No, the TV/radio/Web/print ads will not necessarily be remembered when people get to the site.

But…the Home page? Really?

Even knowing that nowadays most of the times people get on a site from an external link, the behavior tends to be that: if they like what they see, they will visit the home page to see who made it and what more they can find.

How to get the message across

There are three things to make it clear what the site is about:

People will often get it without even noticing these three elements. But if they can’t guess, there should be a place where they can go to find out.

A few guidelines for getting the message across:

Nothing beats a good tagline!™

A tagline is a pithy phrase that characterizes the whole enterprise, summing up what it is and what makes it great.

A good tagline is one that no one else in the world could use except you. (Jakob Nielsen)

A good tagline is:

Tagline? We don’t need no stinking tagline

Some sites don’t actually need taglines. When they come from an already achieved household word status, or they are well known from their offline origins. Even in these cases, sites would benefit from a tagline.

The fifth question

Once we know what we are looking at, we need to answer where to start if I want to:

If it’s a step-by-step process site, it should be obvious, if not, it should be easy to find, for example, the Log In or Sign In buttons. Unfortunately, the need to promote everything can obscure the important stuff. Then we need to make the entry points visible. It helps to label them like “Search,” “Sign In,” “Start Here,” etc.

Why Golden Geese make such tempting targets

One of the worst behaviors is to try to promote everything. Promoting things in the Home page guarantees more traffic to the promoted section. The cost of a promotional overload is an overall loss in effectiveness of the Home page as it gets overpopulated.

That’s The Tragedy of the Commons (William Foster Lloyd, 1833 and Garret Hardin, 1968):

Any shared resource (a “commons”) will inevitably be destroyed by overuse.

Making Sure You Got them Right

”The Farmer and the Cowman Should Be Friends"

"Why most arguments about usability are a waste of time, and how to avoid them.”

The team (PMs, designers, marketing, devs, etc) needs to make decisions about usability. Unfortunately they/we end up having an endless discussion consisting of personal beliefs that cannot be proven, such as a “religious debate.” Instead of solving problems, these arguments create tension among the team members, and result in a waste of time.

”Everybody likes ___.”

We are not only Web creators, but also Web users. So we have our own feelings and opinions about it. Often, we tend to think that others like and dislike the same as we do. We tend to think that most users are like us. That happens even when we actually know that other people can hate what we like, in fact, some of them belong to our own Web team. Not always sensible people, there aren’t many of them.

Farmers vs. cowmen

On top of that personal passion, we have the professional passion. We don’t only have our own point of view about each specific element, but about the whole target of the project.

I.e., devs tend to like ingenious features, while designers enjoy pleasant visual experiences. And maybe the CEO doesn’t care about any of these things and just wants to make something that came out from a dream (true story).

The myth of the Average User

While building a Web site, we figure out that not only team members are different from each other, they are different from the Web user, and even more, each Web user is different from each other. Then, thinking that most Web users are like anything is just a myth. There is no Average User.

”All Web users are unique and all Web use is basically idiosyncratic.”

Each Web user has its own intentions, motivations, knowledge, etc. Their individual reactions are based on so many variables that it’s almost impossible to describe the Average User. It’s even counter-productive.

There is no “right” answer to design questions, they just need to be carefully thought out, well executed, and tested. There are some things we should never do, and some others that we should rarely do, but usually Web teams don’t even argue about these ones.

The antidote for religious debates

At the end, there is no point in trying to generalize, saying what is good and what is bad. What we really need is a specific solution for a specific problem in a specific context. The only thing that is good is the one that works. And the only way to know it is by testing. There’s no substitute for it.

We have to use our collective skill, experience, creativity, and common sense to build “the solution.” Watch people as they try and (if possible) finally use it. That’s all. Debates about what we like and what the user (supposedly) likes are just a waste of time and energy, what really matters is what works.

Usability testing on 10 cents a day

”Keeping testing simple -so you do enough of it.”

Usability testing has to make part of the project from the beginning. Sadly, a lot of it still gets done: too little, too late, and for wrong reasons.

Repeat after me: Focus groups are not usability tests

The main difference is that in usability, you watch people use and behave, instead of listening to opinions and past experiences.

Focus groups are good for determining what your audience wants, needs, and likes (in the abstract). They let you know if your product makes sense and your value proposition is attractive. They are best used in planning stages. They’re not good for learning about whether your site works and how to improve it. That’s what usability testing does, and it should be done through the entire process.

Several true things about usability testing

Do-it-yourself usability testing

At the beginning it was very expensive. Recruiting lots of participants, a professional to plan the tests, the resources to execute and analyze it, etc.

In 1989, Jakob Nielsen wrote a paper titled “Usability Engineering at a Discount.” He pointed out that it didn’t have to be that expensive and dropped the costs to about 20% from the amount people were paying until the date (e.g: from 50.000to50.000 to 10.000, which is still a lot of money).

Traditional testingDo-it-yourself testing
Time spent for each round of testing:1-2 days of tests, then a week to prepare a briefing or report, followed by some process to decide what to fix.One morning a month includes testing, debriefing, and deciding what to fix.
When do you test?When the site is nearly complete.Continually, throughout the development process.
Number of rounds of testing:Typically one or two per project.One every month.
Number of participants in each round:Eight or more.Three.
How do you choose the participants?Recruit carefully to find people who are like your target audience.Recruit loosely, if necessary. Doing frequent testing is more important than testing “actual” users.
Where do you test?Off-site, in a rented facility with an observation room with a one-way mirror.On-site, with an observer in a conference room using screen sharing software to watch.
Who watches?Full days of off-site testing means not many people will observe firsthand.Half day of on-site testing means more people can see the tests “live.”
Reporting:Someone takes at least a week to prepare a briefing or write a Big Honkin’ Report (25-50 pages).A 1-2 page email summarizes decisions made during the team’s debriefing.
Who identifies the problems?The person running the tests usually analyzes the results and recommends changes.The entire development team and any interested stakeholders meet over lunch the same day to compare notes and decide what to fix.
Primary purpose:Identify as many problems as possible (sometimes hundreds), then categorize them and prioritize them by severity.Identify the most serious problems and commit to fixing them before the next round of testing.
Out-of-pocket costs:5.000to5.000 to 10.000 per round if you hire someone to do it.A few hundred dollars or less per round.

How often should you test?

We should spend one morning a month doing usability testing (or every two weeks if doing agile development).

Why a morning a month?

How many users do you need?

The ideal number is three. It may seem too small to prove anything and won’t uncover all of the problems. But it’s not true, and here’s why:

How do you choose the participants?

People often spend a lot of time trying to recruit users who they think will precisely reflect their audience. Truth is that testing with these users isn’t that important.

For many sites, you can do testing with almost anybody. The earlier the tests, the greater the amount of usability flaws that will cause problems. Problems that affect both specific and non-specific users, things that anybody will encounter.

Recruit loosely and grade on a curve.

Recruiting people who fit a narrow profile usually requires more work and money. Try to find users that reflect your target audience, but don’t get hung up by it. Simply ask yourself “Would our users have that problem?”

Using participants that aren’t from your target audience:

How do you find participants?

There isn’t a single way of finding people. Trade shows, Twitter, customer forums, a pop-up on your site, or even asking friends and neighbors.

Typical participants’ incentives for a one-hour test session range from 50to50 to 100 for “average” users, and several hundreds for highly paid professionals. It’s nice to offer a little more than the going rate.

Where do you test?

It’s quite obvious. We always need a quiet space with no interruptions (an office or a conference room), a table, a couple of chairs, a computer with internet access, and its accessories.

The most “special” item is a screen sharing software to allow the team members, stakeholders, and anyone else who’s interested. We should also run a screen recording software.

Who should do the testing?

The person who sits with the participant and leads them through the test is called the facilitator. Almost anyone can facilitate a usability test. It tends to be someone who is patient, calm, empathic, and a good listener.

Other than keeping the participants comfortable and focused on doing the tasks, the facilitator’s main job is to encourage them to think out loud as much as possible.

Who should observe?

As many people as possible!

One of the most valuable things is the effect that usability testing has on the observers, it’s a transformative experience that dramatically changes the way they think about users. Everyone should come and watch the test sessions. We’ll need an observation room with a large screen monitor or projector so everyone can see what’s happening.

After each test session, observers need to write down the three most serious usability problems they noticed, so they get fixed first.

What do you test, and when do you test it?

It’s important to start testing as early as possible and to keep doing it through the entire process. In fact, it’s never too early to start.

Even before the design process, it’s a good idea to test competitive sites, like sites from competitors or just sites that may have the same style, organization, or features. If you are redesigning, you’ll also want to test, so you’ll know what’s not working (and needs to be changed) and what is working (so you don’t break it).

How do you choose the tasks to test?

The tasks (the things the participants will try to do) will depend partly on what you have available to test. If you only have a rough sketch, the task may consist of simply asking what they think it is. If it’s more than a sketch, make a list of tasks people need to be able to do.

Choose enough tasks to fill the available time (about 35 minutes in a one-hour test) keeping in mind that some people will finish faster than you expect. Then word each task carefully, include any information as needed, or allow the participants to choose some of the details (it’s much better as it increases the emotional investment).

What happens during the test?

For presentation or explanation the wording has to be carefully chosen.

Typical problems

Some of the problems you’re going to see more often:

The debriefing: Deciding what to fix

As soon as possible we must decide which problems to fix and what we’re going to do to fix them. We should debrief immediately after the tests, so everything is still fresh in our (the observers’) minds.

Whenever we test, we’re almost always going to find some serious usability problems. Unfortunately, they aren’t always fixed. Sometimes people decide to postpone them, or simply choose to fix the easier and shorter ones.

Focus ruthlessly on fixing the most serious problems first.

That maxim can be achieved by:

Tips about deciding what to fix -and what not to:

Alternative lifestyles

Two other ways to do testing that have distinct advantages:

Try it, you’ll like it

Whatever method we use, we’re likely to keep doing it.

The Top Five Plausible Reasons for not Testing Web Sites
  1. We don’t have the time: It’s true that we usually “don’t have time” in Web development, but it’s also true that by making testing and keeping it as simple as possible, we end up saving time.
  2. We don’t have the money: We don’t need to spend 5.000to5.000 to 10.000, investing a few hundred dollars per round of testing is enough to get it done (at least the most important).
  3. We don’t have the expertise: Usability testing is incredibly easy to do. For sure, more experience and knowledge will be better, but even a poorly conducted testing session will produce useful results.
  4. We don’t have a usability lab: We don’t need one, all we really need is a room with a desk, a computer, two chairs where you won’t be interrupted and another room for the observers with a large screen.
  5. We wouldn’t know how to interpret the results: One of the nicest things is that the most serious problems are hard to miss, they are quite obvious to everyone who’s watching.

Larger Concerns and Outside Influences

Mobile: It’s not just a city in Alabama anymore

”Welcome to the 21th century -you may experience a slight sense of vertigo.”

Phones have been getting gradually smarter for years, even more after the iPhone introduction in June 2007. And it was about this same time that the Mobile Web finally came into its own. There had been Web browsers on phones before, but they sucked.

One of Apple’s great inventions was the ability to scroll and zoom in and out (by just swiping and pinching the screen) very quickly. For the first time, the Web was fun to use on a device that you could carry with you at all times. We could look up anything anywhere anytime.

There’s not much denying that mobile devices are the wave of the future, except for things where we need enormous horsepower or a big playing surface (video editing, Photoshop, CAD, etc).

What’s the difference?

The answer is: Not much, the basic principles are still the same.

There are some significant differences about mobile that make for challenging new usability problems. But the fact is that Web and app design for mobile devices is still in its formative days in many ways, so it’s going to take another few years for things to shake out. Prevailing conventions probably haven’t emerged yet.

It’s all about tradeoffs

Constraints and tradeoffs in design.

The best you can do is please some of the people some of the time.

Constraints actually make design easier rather than limited, they have a focusing effect, while liberating and unlimited options can have a paralyzing effect.

Where there are constraints, there are tradeoffs to be made.

Many of the serious usability problems are the result of a poor decision about a tradeoff.

The tyranny of the itty-bitty living space

The most obvious thing about mobile screens is that they’re small. Thus, the amount of tradeoffs to make in the Home page is quite big. One of the only ways to deal with it is to leave things out, the tricky question is: Which parts do we leave out?

One approach was Mobile First. Where we define the most important features and contents, then we use them for the design, and finally we add on more things to create the desktop/full version. Mobile First forces us to work hard to determine what’s really essential, what people need more (as it should always be).

Often it happens that we tend to design for mobile as the users were “on the move”. That’s wrong, users are just as likely to be using their mobile device while sitting at home, and they want (and expect) to be able to do the same things they do on desktop.

The main idea is not to remove features or content, it’s to prioritize them.

At the end, it results in a navigation with a few more “taps” than the full version, and that’s OK. As long as the user continues to feel confident that what they want is further down the screen or behind a link or button, they’ll keep going.

Managing real estate challenges shouldn’t be done at the cost of usability.

Breeding chameleons

Facts about scalable design (aka. responsive design):

The one-size-fits-all-sizes promise broke since mobile development is a thing. Scalable design doubles the effort and guarantees that either things won’t be updated or the versions will be out of sync. It has real revenue implications.

Three suggestions to “solve” that problems:

Don’t hide your affordances under a bushel

Even in the need of removing and hiding things, avoid hiding affordances (aka. signifiers or visual clues) of elements on visual user interfaces. By definition, they are the last thing we should hide. They need to be noticeable, and some characteristics of mobile devices have made them less noticeable, or worse, invisible. Affordances don’t need to hit you in the face, they just have to be visible enough.

No cursor = no hover = no clue

When designing for mobile, we cannot rely on the hover feature as it doesn’t actually exist. We do need to find ways to replace the cues or entire features that depend on that behavior.

Flat design: Friend or foe?

Affordances need to be distinctive to be effective. Flat design, if done wrong, removes all the visual information for the sake of “looking good”, then it’s harder to differentiate things.

You actually can be too rich or too thin

Internet connection is quite fast nowadays. Anyways, people leave the fast wi-fi and revert to a slow 4G/3G so often that download speeds are unreliable. We shouldn’t force the user to download a huge amount of code and images larger than needed on mobile screens.

Mobile apps, usability attributes of

Krug’s definition of usability:

A person of average ability and experience can figure out how to use the thing (learnable) to accomplish something (effective) without it being more trouble than it’s worth (efficient).

Three important concepts are delight, learnability, and memorability (next three sections are about these applied on mobile apps).

Delightful is the new black

In general it’s hard to define delightful, but people describe it as something fun, surprising, impressive, clever, and even magical. It happens when people figure out that they can do something that they don’t imagine is possible, it’s something that people really enjoy being able to do.

Apps need to be learnable

One of the biggest problems comes when we add too many features, new ones and the ones that don’t follow any convention and need to be explained. It makes the app too complicated and not easy to learn.

Even an innovative app can be depreciated by users if its demo/training/tutorial is done wrong. No matter how much creativity we bring on the table, users need to figure out how the thing works.

Apps need to be memorable, too

Once the users have figured out how to use an app, they should be able to remember or relearn it again with no much effort. To ensure that, we have to make things incredibly clear and easy. If it’s easy the first time, it’ll be easy the second time.

Usability testing on mobile devices

It’s quite the same as the testing on non-mobile devices. The only thing that can change is the logistics.

The logistics of mobile testing

As mentioned before, when testing on a personal computer:

Setup isn’t the same for mobile devices, we cannot rely on the same tools, some of them don’t even exist yet.

My recommendations

Until better technology comes along:

Proof of concept: My Brundleyfly camera

Brundlefly is the name I give to a hand-crafted solution that consists of a lightweight webcam and a clip from a book light, so we don’t need to use a heavy camera attached to the device.

The traditional way with mounted cameras:

The rest of the setup:

Usability as common courtesy

”Why your Web site should be a mensch*.”

*Mensch: a German-derived word, a person with integrity and honor, someone who does the right thing.

Besides being just clear, the site should behave like a mensch -being considerate of the user, bringing the content and utility the people need and isn’t that obvious.

The reservoir of goodwill

It’s useful to imagine that every time we enter a Web site, we start out with a reservoir of goodwill. Each problem we encounter on the site lowers the level.

The reservoir is limited, and if we treat users badly enough and exhaust it there’s a good chance that they’ll leave. It can get even worse, they may not be as eager to use your site in the future and savage you on Facebook or Twitter. Thinking in marketing, the NPS (Net Promoter Score) will go down.

A few things worth noting about this reservoir:

Things that diminish goodwill

Things that increase goodwill

Most of these items are just the flip side of the previous list:

Accessibility and you

”Just when you think you’re done, a cat floats by with buttered toast strapped to its back.”

Unless we’re going to make a blanket decision that people with disabilities aren’t part of our audience, we must make sure the site is accessible to really make it usable.

What developers and designers hear

Reasons why they need to make their sites accessible:

In the end, doing an accessible site is the right thing to do because it makes some people’s lives extraordinarily better.

What developers and designers fear

As they learn more about accessibility, two fears tend to emerge:

The truth is, it can be complicated

Sometimes it seems like we can get the job done by just using a validator to make sure the site complies with the WCAG guidelines, but it’s not that easy. It does cover some of the problems, but not all of them. It gives us vague warnings about things that may be wrong, and a long list of things that can be improved but we don’t actually need.

This can be very discouraging for developers and designers that are not going to become accessibility experts and figure out that it’s much harder than they thought.

At the end:

The four things you can do right now

Even with current technology and standards, it’s possible to make any site accessible without an awful lot of effort by focusing on a few things that will have the most impact.

#1. Fix the usability problems that confuse everyone

If something confuses most people who use the site, it’s almost certain to confuse users who have accessibility issues (or even to confuse them harder). The single best thing we can do to improve our site’s accessibility is to test it often.

#2. Read an article

There are a lot of articles from people who had time and motivation to do tests with users that have some accessibility issues. As usual, they produced invaluable insights.

#3. Read a book

Some recommendations:

#4. Go for the low-hanging fruit

The most important things to do, implementing specific changes in our pages:

Guide for the perplexed

”Making usability happen where you live.”

What can you do if you find yourself in an environment where your desire to “do usability” isn’t supported?

Ya gotta know the territory

In the 1990s The terms used to describe this were Usability and User Centered Design (UCD). And there were essentially two “professions,” Usability (making sure things are designed in a way that enables people to use them successfully) and Information Architecture (making sure the content is organized in a way that allows people to find what they need).

Now the term we hear most often is User Experience Design or just User Experience (UXD, UX), and there are a lot of specialties involved, like Interaction Design, Interface Design, Visual Design, Content Design, Content Management, Usability, Information Architecture, and more.

One difference between UCD and UX is that:

The usual advice

Here are the two suggestions for convincing management to support usability work:

If I were you(…)

Some tried and tested ways to make it work based on successful experiences:

At the end, it’s all about sharing what we know, not to tell people what to do.

Resist the dark forces

Usability is about serving people better by building better products, but there’s a trend, mainly from the marketing team, to try to get usability practitioners to help them figure out how to manipulate users rather than serve their needs.

There’s even a book called Evil by Design: Interaction Design to Lead Us into Temptation by Chris Nodder about human frailties and design decisions. Whether something is desirable or not is a marketing question, best answered by using market research tools.

It’s fine to use usability tests to determine whether something is desirable, or even for help in figuring out how to make something more desirable. What’s wrong is to use usability to make users think something is desirable, to manipulate them.

Books that can lead us to influence people the right way:

A few definitive answers

Almost all in this book has been answered with “it depends,” but there is a collection of things that are definitive answers: