|A basic wireframe. A powerful UCD tool|
I'm not saying if they'd followed this list thousands of jobs would have been saved, or that half of Britain's high streets would still have a sense of dignity and pride rather than resembling the Texan outback.
But when done in a timely and orderly manner most of this is common sense and, well...who doesn't enjoy a nice list? So here goes...
Well yeah, duh. But seriously this is so often given lip service and 'completed' haphazardly. Ignoring internal stakeholders to focus purely on users isn't the right way to go about it. Often you'll get interesting nuggets of gold from colleagues who've analysed before, or get valuable anecdotes from the sales teams who are on the frontline. But this is UCD so:
- Get cross-business expertise together to formulate analytical objectives
- Conduct usability studies and field research
- Look at what your competitors are doing (remembering it might not always be right)
- Set a ground rule - personal opinions do not count! 'Content experts' are not users
2. Document objectives & requirements
This is where you develop a deep understanding of your users needs and wants. Use this information to formulate your objectives. Be sure to consider and include technical constraints and obstacles as well as the things you want. Make sure these blockers are dealt with. Ensure that everyone involved in the project reads and understands the document. You want to avoid one person being the guardian of the requirements who everyone goes to as it breeds laziness and disturbs continuity.
Now you can start being creative! It's wise not to rush in here, for reasons that will become apparent in step four. Key activities here include:
- Brainstorming. Don't dismiss ideas immediately, but ensure they are benchmarked against your insight and objectives
- Create sketches, wireframes and paper prototypes. The advantage of these are that they are quick and give people an immediate feel for how it might work. There are a number of useful tools out there such as Axure and Balsamiq to help.
- Overlay design concepts. Useful if you have time, but no need to be detailed
- Walk your ideas through with stakeholders
No design process centred on the user is complete without an assessment by them. This is why it's important not to over-commit time and resource in step three. If they hate your proposal you'll be miffed you or your team spent two weeks developing it when they could have spent two days.
- Conduct usability sessions
- Record how the user reacts and what they say throughout the session. Morae is a good tool to help with this
- Adapt your proposal accordingly, creating a final interactive prototype if possible
- Complete design concepts
5. Build and test
Only now is it safe to build, bringing all the preceding steps together. If you have a final prototype this will go a long way to reducing development time as it negates the need for clarification along the way (although regular progress briefings are good!)
An Agile approach to development is recommended. This works on the basis of short development 'sprints' - normally two weeks each - at the end of which progress is monitored against expectations with opportunities to adapt the work planned for the next sprint if necessary (often external factors come into play and disrupt development which Agile can navigate around).
Finally it goes without saying that ongoing review and testing is a must. Nothing ever stands still. Rather than leaving it for two or three years to repeat this process it's best to plan smaller, more manageable analytical sessions to sense check. This will help you spot potential problems sooner than you would otherwise, the result being less work needed to address the findings.
What you get is evolutionary and that's a user centred approach to design.