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.
