What development process should we use to ensure the product (or web site or software) is usable? When should you start usability? I think I’ve said before that you should start usability right at the beginning of the process. It should be integrated right into the systems engineering process or any other development process you’re using. Bringing a usability person on at the end to “bless” your project is NOT going to work. I wouldn’t want my name on any project that approaches usability this way–yet this seems to be how most projects want to do usability. Bringing usability in late is, admittedly, better than never, but to really benefit from usability practices, you have to use it throughout the entire development process, right from the start of the project.
There are established processes for usability and many different tools you can use along the way. Usability.gov and NASA both have process models. James Williams Helms of Virginia Tech wrote a paper on the LUCID/Star Usability process model.
Here is the process in a nutshell:
- Research and Planning: this part involves researching your user community, gathering statistics, usability testing the existing site/product/software, performing surveys, interviewing users, developing personas, and determining the requirements and goals for the site/product/software. Make sure you understand your users’ goals, motivations, and work flows. Know what they come to your site for, what tasks they are trying to complete, what information they seek. This is critical.
- Conceptual Design & UI Structure: Use card sorts to help you with your UI structure. Sketch out pages, show them to users and see if they understand them. Modify as appropriate. Remember what Frank Lloyd Wright said:
“You can use an eraser on the drafting table or a sledge hammer on the construction site.”
Now is the time when changes are cheap, so take full advantage of it. Don’t try to lock down your design too soon. Iterate your design with feedback from real users. Present the feedback from your tests to management and explain the logic behind your design. Don’t be afraid to push back if management asks for something that doesn’t make sense, or if they want to change something on a whim. They expect us to deliver the best solution–we have to tell them what approach we should use, and why, to get the best possible product.
- Detailed Design & Usability Test: For a web site, you might start to mock up some pages now, and develop the flow of the site, but don’t start programming too soon. Use simple HTML hyperlinks or even Powerpoint to show the flow. Let users hack away at your prototype (via usability tests) and revise the design appropriately. Be open to change, if it’s needed. This is the time to change, before you’ve started programming. Programming is expensive. Making changes later will cost much more. Make sure management understands that. Talk a lot about the user experience, use statistics, show user feedback. Our management wants our end users to be happy, and most of the people on the leadership team have said to me (in interviews) that their opinion doesn’t count–it’s the users’ opinions that count. Make sure you make it count by giving the users plenty of opportunity to express their opinion along the way.
- Develop & Usability Test: Now that you’ve iterated the UI design, you can start making it work. Hopefully your usability tests to this point have uncovered a lot of the gotchas. But still, do more usability testing as you go, especially when you run into questions about how something should work. It’s best to just test it. Always include usability test results in your management meetings. They show very clearly the reasons for every design decision. Let management make the decisions, but give them enough information to make the decisions that make sense for the user.
- QA test, etc. and Launch: Usability testing doesn’t ensure you’ve caught all the end cases, the bugs, etc. Make sure you test for bugs and handle errors with care. Treat the user with respect, and make sure all error messages are in user (not programmer) terminology, that they are kind and they blame the software, not the user, for the error (even when it is the user’s fault). Nobody likes a product, web site or software that makes them feel stupid.
That’s pretty much it in a nutshell. Notice usability isn’t just a usability blessing at the end–it’s involved from the very start, when you’re doing user research, developing personas, formulating your requirements. Don’t get stuck in “the way we’ve always done it.”
Projects that incorporate usability practices get meaningful results–I’ve seen metrics reported like improvements in sales of 100 to 700%. Notice there’s a wide range there. Projects that incorporate usability from the very beginning get much better results (closer to 700%). Projects that invite usability at the end aren’t going to see as much difference.
The same amount of effort, applied at the right time in the process, can have a huge impact.