Alexander Klimetschek's Blog On Software Design and Development

User-Centered Design in practice

Yesterday I presented the results of our UCD process for the next release of Mindquarry to our team. As we did this for the first time, and some of us were quite sceptical about the usefulness of the process, I also talked about the lessons learned in the last three weeks. As everybody was convinced of UCD after the presentation, I'd like to share our experiences with you.

Reasons to do UCD

• It is easy and can be cheap: Read Jacob Nielsen's (a user design guru) interesting texts about cheap, fast and good UCD and the small number of users needed. Then learn about paper prototyping.
  
• Forced Internal Design & Thinking: It forces you to previously think about all interfaces and processes in your application: no area is left out if you test mockups with users, no decisions developers will make later during implementation based on technical simplicity (and not on usability) that lead to akward issues in the interface.
  
• Valuable Input Through External Users (Suprises): Users that see the design of your application for the first time will note problems you definitely won't think about - because you as a designer/developer know all the context information about the application, what features are available, how they work; a new user doesn't know this - he can only act upon the GUI provided to him. This not only applies to the geeky developers that don't care about user interfaces but also to people who have a good intuition about good interfaces - they still make mistakes that are not seen until a user actually tries it.
• Useable Guideline For Implementation: If you create a printable pdf containing all the final mockups and annotations why something is done that way and how things should behave, you have a perfect requirements specification for your developers (it mostly contains images, not boring texts). This does not only apply to frontend developers: if you test entire processes you also indirectly specify many parts of the backend's behaviour and of the data to be stored.
  

As one can see, it is more of a top-down software design process: from user interface to implementation. The more traditional way is mostly bottom-up: it starts by specifying the features (requirements), typically from the customer, then you identify the data and its relations, specify the database layout... and later during development someone (the developer) hacks some user interface which is driven by the data definition and the backend design. He typically decides upon the backend, not on what would be a usable interface. This is ok, since in most cases he has limited time and his context is the existing code base of the backend. If you do usability tests at this late stage and find issues, resolving them is very costly since you already implemented most of the system and thus spent a lot time and money on it.

How to do UCD

• Define your goals: define the basic features before the UCD, so that you know don't have to work that out completely (asking users what they want gives you too much input...). That step is something you should align with the business and marketing part of your company anyway.
  
• Focus on small areas: Designing the complete application that will be developed over 1 or 2 years is overkill - you will never stop talking about what you could do and what features would be cool. Instead, focus on selected areas (definied by the goals) so that you can quickly stop discussions that cross the border.
  
• Look out for test users early: Getting test users can take some time, everyone is just so busy... Contact them early (3-4 weeks in advance) and provide a free installation of your software or a similar advantage (if you grab users from the street, simply pay them).
• Part 1 - Think & Design: Collect all ideas around the features to be done, both older ones you have collected over the time (and I bet you have) and add new ideas while talking about it. Then focus on what to design and define the steps needed to do something, eg. pages in a web application (this also gets called design maps). Now identify the questions and problems that should be tested with the user.
  
• Part 2 - Incrementally Design Mockups & Test: After you have your first design, prepare mockups along with a few test scenarios. The mockups should contain useful content (at least to a certain amount), so that the user can actually read meaningful things and fulfill the tasks (eg. with a forum: "you posted a message yesterday about a problem with your servers, now you want to look for a possible answer"). During the test you will easily spot the problems - user not finding a button, thinking too long about the next stop, clicking on areas where you did not think about a link, etc. After those tests (1 user ~ 1-1/2 hour, 2 users per session) you should discuss the noted problems and think about solutions. Don't wait for the next day, the quick turn-around time is very effective. With improved mockups you can go into the next round of user testing. Do this until you think that your design is good (we had 3 rounds with a total of 5 users).
  
• Part 3 - Collect The Results And Communicate Them: Make a PDF with all mockups (if you use paper prototypes simply scan them) and add explanations of the controls/buttons/text etc. Prepare a presentation with the mockups as well and get all people working on the product to it (developers must attend, as well as marketing), so that everybody knows what your product will look like in the future.

I will publish the results of our UCD process for navigation and talk in my next post.

Posted at 03:34PM Mar 29, 2007 by Alexander Klimetschek in General  |