Best practices

Users Don't Hate Change. They Hate Our Design Choices.

For years, we studied teams rolling out new designs, to see if we could mitigate negative reaction to new releases and design changes. We studied hundreds of product and service rollouts. We watched and learned from the reactions of thousands of users.

When we dug into what those users’ reactions, patterns emerged. The users told us the changes inconvenienced them. They had no idea the change was coming and suddenly it was in their face. Users were upset because they were surprised.

They also told us the old version worked fine. Even when it took a while to get comfortable, they learned it. Many users mastered difficult-to-use designs.

Everything was different when the new version arrived. What they’d mastered before didn’t help them now. The company said it was an improved design, but they couldn’t see the improvements. Why should these users learn something new that doesn’t help them? Users were upset because they couldn’t see the value.

We also saw many instances where users didn’t react negatively to changes. Often, they didn’t react at all. We saw new designs that didn’t affect the users’ behaviors and they didn’t pay attention to it.

In these cases, the changes were often not noticeable. Sometimes the changes were small and isolated. Yet, we also saw users seemingly not notice several updates with extensive changes. (In more than one instance, an entire application’s infrastructure had been rewritten without a single user noticing.)

In cases when the design changes were noticeable, the designers gave the users control to switch when they wanted. The designers showed why the change was valuable to the users. And the designers made the transition easy by taking the knowledge and experience their users already had with the product into account.

Measure Performance with the RAIL Model

RAIL is a user-centric performance model that breaks down the user’s experience into key actions. RAIL’s goals and guidelines aim to help developers and designers ensure a good user experience for each of these actions. By laying out a structure for thinking about performance, RAIL enables designers and developers to reliably target the work that has the highest impact on user experience.

Every web app has four distinct aspects to its life cycle, and performance fits into them in different ways:

Image

Summary

RAIL is a lens for looking at a website’s user experience as a journey composed of distinct interactions. Understand how users perceive your site in order to set performance goals with the greatest impact on user experience.

  • Focus on the user.
  • Respond to user input in under 100ms.
  • Produce a frame in under 10ms when animating or scrolling.
  • Maximize main thread idle time.
  • Load interactive content in under 5000ms.

What if images don't arrive? A tale of a badly designed lazy loader

If you’re looking for an example of exactly what not to do in terms of front-end performance, I can’t think of a better one than this - they threw away a lot of the performance optimizations browsers give us for free in a bizarre attempt at improving page loading, which ended up doing the opposite:

I was recently conducting some exploratory work for a potential client when I hit upon a pretty severe flaw in a design decision they’d made: They’d built a responsive image lazyloader in JavaScript which, by design, worked by:

  1. immediately applying display: none; to the <body>;
  2. waiting until the very last of the page’s images had arrived;
  3. once they’d arrived, removing the display: none; and gradually fading the page into visibility.

Not only does this strike me as an unusual design decision—setting out to build a lazyloader and then having it intentionally block rendering—there had been no defensive strategy to answer the question: what if something goes wrong with image delivery?

‘Something wrong’ is exactly what happened. Due to an imperfect combination of:

  1. images being completely unoptimised, plus;
  2. a misconfiguration with their image transformation service leading to double downloads for all images;

…they’d managed to place 27.9MB of images onto the Critical Path. Almost 30MB of previously non-render blocking assets had just been turned into blocking ones on purpose with no escape hatch. Start render time was as high as 27.1s over a cable connection1.

If you’re going to build an image loader that hides the whole page until all images are ready, you must also ask yourself what if the images don’t arrive?

Reader Mode: The Button to Beat

A reminder of why reader modes exist in browsers and to embrace them as a user’s right:

Good design isn’t about forcing someone to walk a tightrope across your carefully manicured lawn. Nor is it a puzzle box casually tossed to the user, hoping they’ll unlock it to reveal a hidden treasure. Good design is about doing the hard work to accommodate the different ways people access a solution to an identified problem.

For reading articles, the core problem is turning my ignorance about an issue into understanding (the funding model for this is a whole other complicated concern). The more obstructions you throw in my way to achieve this goal, the more I am inclined to leave and get my understanding elsewhere—all I’ll remember is how poor a time I had while trying to access your content. What is the value of an ad impression if it ultimately leads to that user never returning?

shame.css, or documenting your hacks

You’d be forgiven for thinking the point of this whole exercise is to shame the developers (you can always pick a name other than shame.css) but it’s really not. I am well aware of (and responsible for) hacks and quick fixes; your product owner doesn’t care if you used an !important, they just want the new feature out of the door. Hacks happen, fact.

shame.css is jokingly titled to make it a little light-hearted whilst also indicating that anything in there is a bit of a shame; a shame to have to have done, a shame to pollute the codebase with and so on…

By isolating all your hacks and bodge-jobs in their own file you can really easily keep tabs on them; isolating them isn’t to shame the developers, not at all, it’s merely to make the team aware of them and make them painfully, unmissably obvious.

The rules

Obviously you need some kind of rules and criteria:

  1. If it’s a hack, it goes in shame.css.
  2. Document all hacks fully:
    1. What part of the codebase does it relate to?
    2. Why was this needed?
    3. How does this fix it?
    4. How might you fix it properly, given more time?
  3. Do not blame the developer; if they explained why they had to do it then their reasons are probably (hopefully) valid.
  4. Try and clean shame.css up when you have some down time.
    1. Even better, get a tech-debt story in which you can dedicate actual sprint time to it.

This certainly seems like a good approach. That said, I personally prefer to have everything related to a component living with the component, but documented as a hack, possibly searchable via some sort of comment tag, like @hack <description>.

Material Design as gospel

“We went out with the original Material Design with what was a very fresh and very opinionated style. We wanted to get attention,” says Matias Duarte, the head of the Material Design group at Google. “And it was so strong and so opinionated and so successful, a lot of both the designer and developer community took it as a ‘gospel,’ perhaps is the right word.”

[…]

”We spent two years telling people ‘this is how to make Material yours,’” Duarte says, “and it didn’t work.” But he doesn’t blame developers. The problem is that Google didn’t provide the right tools. Specifically, he believes Google’s guidelines didn’t separate out the styling of the button from its function. Google wants apps to work like other Material Design apps, but it never meant for all Android apps to look like each other.

Global Accessibility Awareness Day

May 17th is Global Accessibility Awareness Day. See the source link for more. The participate page is a great list of things to test for and be aware of.

The target audience of GAAD is the design, development, usability, and related communities who build, shape, fund and influence technology and its use. While people may be interested in the topic of making technology accessible and usable by persons with disabilities, the reality is that they often do not know how or where to start. Awareness comes first.