by Chris Myhill
Director of Experience
We work on a lot of websites and apps. One of the most common requirements we get from our clients is that the interface should be simple, clean and obvious. It’s a worthy aim. After all, simplicity is a hallmark of good usability.
Think about the best user interfaces you’ve ever encountered. They probably didn’t look cluttered. They probably didn’t make you feel overwhelmed. They probably didn’t show too much information at once.
We’ve talked before about the dreaded phenomenon of ‘choice paralysis’. Ultimately, it’s the notion that the more stuff you put in front the user, the more they’ll feel overloaded and struggle with their tasks. Killing complexity and keeping things simple is the way to go.
Designing a simple user experience feels like it ought to be effortless. After all, being simple involves doing less… right?
Unfortunately, nailing simplicity isn’t quite so easy. It needs to be earned. The art of deciding what not to show requires cooperation across the project team. It involves us being fully aligned on priorities.
The Merriam-Webster definition of prioritisation is to “make something the most important thing in a group”. To design an effective user experience, we must absolutely prioritise our requirements from the outset.
A single website or app can have several audiences, each with their own distinct goals. Organisations themselves are also complicated, and that complexity can easily creep into a user interface. Departments often push for their own (sometimes conflicting) business objectives to be reflected in a website’s navigation with no consideration for the user. Home pages can end up becoming cluttered for no other reason than to appease various stakeholders.
Designing effectively means establishing the priority of content and features across the whole product. What’s the most important thing to the majority of the users? What’s the second most important thing? And the third?
Once we’ve established the priority of user tasks, we can then plan an information hierarchy. This forms the basis of navigation, page structure, and even details such as button placement and wording. It’s all about sharing the relevant message at the best possible time. This is what leads to increased user engagement, and websites that convert more effectively.
Deciding on our ‘top tasks’ isn’t a solo activity. It involves collaboration between the project stakeholders, along with evidence to support our decision making.
In most cases, priority is informed by a combination of user needs and organisational goals. We need to find the intersection between what people want, and the behaviours that profit the organisation. The top priorities exist in this sweet spot.
So how do we on agree what our priorities are? We find workshops to be the most effective technique. By getting stakeholders from across departments together, we can identify what constitutes ‘ideal’ user behaviour. We can also see where content, features and user tasks overlap between departments.
Once we’ve listed out the different user tasks as a team, we like to run a ‘dot voting’ activity. We’ll give the group a number of little stickers. We call them prioritisation dots. The group has to agree how to spend the dots.
Multiple dots can be put on a single feature, meaning that important ideas should be allocated more dots. We’ll stress that the dots shouldn’t be spread evenly across every task. If we spread ourselves too thin, we fail to prioritise. It will result in a user experience that is cluttered and unfocused. The process can take some deliberation, but the outcome should paint a good picture of task and feature priority.
Of course, there are other ways to achieve this result. We often vary the activity depending on the product complexity, or the outlook of the team. Another approach involves playing ‘higher or lower’ with site requirements. We’ll write all of the site content & features down on sticky-notes, and simply arrange them in priority order on the wall. This works better when the team is equipped to agree the order through discussion, rather than putting things to a vote.
There are also a number of visual ways we can map requirements against importance. This can mean plotting user tasks on a scale of impact (how beneficial is this behaviour to the user and/or organisation) vs usage frequency (how often do users have this need?). When we can visualise the overlap between highly profitable and frequently occurring user behaviours, it can be much easier to establish priority.
Naturally, designing great websites and apps isn’t only about what the organisation wants. After all, we want to make products that people love to use. To do this, we need to understand why they came to us in the first place. How can we best help them?
Doing the right kinds of user research before committing to any prioritisation is really important. We want to make decisions that are backed by evidence, and not just assumption. There are loads of ways we can factor user insight into our decision making.
Entering the workshop equipped with this data is a great way to fast-track the process. It helps us to resolve disputes, by putting indecisions to rest with real evidence. There’s no single ‘right way’ to approach research. Like everything else, the techniques will vary depending on the project budget, and our level of access to end-users.
By understanding the priority of website requirements in the earliest stages, we can ensure the design is simple & focused.
The act of prioritisation is central to the discovery process.
By understanding the priority of website requirements in the earliest stages, we can ensure the design is simple & focused. Our philosophy is that prioritisation results in better user interfaces. Ones that are more likely to convert & delight our audiences.
13th September 2022
By using real content in the early stages of design, we can ensure the right messages are delivered at the right times.
21st June 2022
What does it mean to design for everyone?
7th June 2022
The internet is entering a new era for privacy and authentication. But what could this mean for the applications we create?