Many usability issues exist because users were never put (and kept) at the centre of the design process. The site is for them so it makes sense that it should meet their needs, not those of the business.
Fixing a site that was wasn’t designed around users in the first place can be costly, difficult and sometimes impossible to fully achieve. Development costs inevitably increase if you have to make changes once a site has gone live.
How do I create a website that works for my visitors?
Are you starting with a blank canvas? Probably not. Quite likely you’ll have an existing site that you’re looking to replace or upgrade. What does your data tell you about how people use your current site?
What goals do they have?
What routes do they typically use to get to their goal?
How do they choose to access or filter information?
Where do they drop out of the process?
Do they use the search function and what terms do they tend to search for (successfully and unsuccessfully)?
Retain what people like and understand
Remember the outcry when Microsoft removed the Start button from Windows 8? In many ways the Start button was illogical - press start when you want to stop the computer, for example. But it was familiar. Users had become used to it and it was a convenient starting point whenever you couldn’t work out how to make Windows do what you wanted.
Your loyal customers may have similar favourite tools and functions. Your upgrade might offer better, more flexible and more logical options, but remove the familiar and well-used at your peril.
Observe issues and improve those areas
A key part of user-centred design is involving the user themselves! Nowadays it is inexpensive to gather the information you need. Tools like Hotjar and services like WhatUsersDo allow you to understand what people look for, and when they get in trouble and pinpoint the areas that you need to make changes to.
Map user journeys
Each site user group will have specific goals. Clearly you want to get them to each goal in the minimum number of steps. For each goal document the following:
The process steps that must be completed and in which order.
Specific data fields that have to be completed.
Any questions that users may need answered or additional information they might need at each step.
Fears, uncertainties and doubts that could prevent goal completion.
Anything that will motivate or convince them to complete the goal.
Armed with these insights you can sketch out goal completion maps and use these to drive the site structure and design.
There’s nothing radical about creating wireframes. But too often the focus in mainly on design and appearance. What often seems to get missed is using the wireframes to do cognitive and functional walkthroughs based on the defined user journeys. It’s like a theoretical usability test using schematic wireframes.
This simple step can reveal flaws in your information architecture, navigation, or proposed screen or form layouts that would be expensive to fix after the site is launched or prototyped. Above all it ensures that the site is developed in a way that makes it as simple and painless as possible for users to complete their goals, and that this is what drives the design rather than just appearance.
As the design progresses the wireframes become increasingly detailed and more like finished web pages. Just make sure you keep referring back to your user journeys and usability characteristics at each stage and every time somebody suggests an ‘improvement’ or design change.
Regularly put your site in front of visitors and observe them
This can be done at any time, and I would recommend doing this as early as possible. Paper prototyping, low-fidelity wireframes or full-built sites, but the sooner you get feedback the easier it is to make the changes.
Once you have a usable development site, carry out usability studies again before launch to make sure that what you think should work actually does work in practice.
When you do launch you can have confidence that you’ve delivered something you have validated and known to have made improvements.