Redundancy in Design

Giving users more than one way to do something.

When we don't know

In early stage products we don't know much about who our users are. This makes it hard to know their preferences. Maybe your users are mainly colourblind and use computers once a week. Maybe your users are mostly 16 year old boys who play Fortnite 6 hours a day. Maybe your users don't understand what that glyph means.

You can design a decent experience for both of them by following good design principles and adding redundancy. To optimise a product for each one of them you'll need to know about who they are and what their preferences are.

Balancing risk

It's not always worth it to add redundancy. If a particular workflow is crucial and you're not sure which workflow is going to align to their mental model then it might be.

In most businesses it's highly unlikely you are going to get agreement to build two completely different workflows without some serious risk aversion or a low barrier to building both.

Testing Redundancy

User testing can teach you what your user preferences are. If you have easy access to your users and the time and money to test. Designing redundancy into prototypes can teach you a lot about what works.

Use fake door testing to save more time building prototypes. Build the entrance of the alternative workflow and see who uses it, ask them what they expected to happen. Be careful about what people say, focus on what they do.

Finding multiple user types

In the course of testing or researching you might become aware that you have more than one distinct type of users. These users can require different workflows. Small icons for shortcuts might work for some users and more verbose workflows are preferable to others.

You can now start to build in redundancy knowing it's demonstrably worthwhile. Assuming both user types are equally important to you.

A crutch for indecision

Don't use redundancy every time you're not sure. No redundancy is preferable. Where redundancy exists in your product you should have an experiment running or proof it's worthwhile.

As the product develops, consider existing redundancies again. Things will change, users will change. Your aim is always to remove redundancy if there is no proof its useful.

Basement Files 92

Reading "The first 10 years of your career are for learning what you want to do. The next 10 are for getting great at it. The next 10 are for making an impact and making money.” The worst-case scenario is someone looking up to pop stars or athletes for

Basement Files 91

Reading Career paths aren’t linear progressions. They’re complex graphs of relationships, often invisible until you step back and map them. Each node represents not just a job or a skill, but a person who took a chance, offered guidance, or simply showed up at the right moment. Don’

Basement Files 90

Reading * This great story about how the calculator was designed on the Mac. * Things like this are why I am not too concerned about AI, there will always be humans making wonderful things just because they can. * Things are feeling really gloomy in UX right now At Linear, I’ve

Basement Files 89

On Quality Great design springs from personal conviction, not just objective analysis. Instead of striving for objectivity—which can compromise your vision and potential—design something that inspires you. The quality of your designs is directly correlated to how well you understand the underlying problem. More often than not we