Tutorial: Collaboratively Designing and Testing User Interface From User Stories, User Scenarios, or Use Cases
This 3-4 hour tutorial describes a practical approach to translating the goals users would like to achieve and the tasks they wish to accomplish into user interface designs that effectively support those goals and tasks.
You’ve gathered requirements for your new project as some set of features or user stories that users and stakeholders value most. You’ve prioritized these features and now it’s time for developers to estimate how long it might take to build. They’ve got questions on exactly what the user interface looks like and how it behaves. As a matter of fact, so do you.
You don’t have the luxury of halting everything for a few days or weeks while you locate a specialist to do the user interface design work. You’ve tried to draw a few pictures on the whiteboard, but you’re not confident they really solve the problem. How can you quickly and predictably move from a simple feature request to a user interface you feel confident in?
This tutorial will introduce a practical approach to translating the goals users would like to achieve and the tasks they wish to accomplish into user interface designs that effectively support those goals and tasks.
Participants will learn how a User Centered Design practitioner moves quickly from user task to user interface. Participants will learn through practice by taking a set of features and transforming them into tangible user scenarios, then collaboratively building and testing paper prototypes of their proposed user interface. In addition to paper prototyping skills and basic usability testing skills, participants will learn essential visual design skills that can help improve the appeal of your user interface.
What’s really going on here?
User interface design to many seems somewhat mystical. But, Larry Constantine & Lucy Lockwood’s Usage Centered Design offers a simple approach to move from a narrative of usage to an abstract user interface prototype. We then make that prototype more tangible using approaches described by Carolyn Snyder. Finally paper prototypes are testing using Snyder’s suggested approaches to usability testing of paper prototypes. Garrett’s Elements of User Experience Model frames the discussion so those involved understand the dependency usability has on user goals and tasks.
This work as been presented as a tutorial at a variety of conferences.
Gerard’s Agile-Usability Experience Report
Adding Usability Testing to an Agile Project
In the paper Gerard Meszaros and Janice Aston of Canadian Pacific Railway describe the injection of paper prototyping and lightweight usability testing into their project. Gerard has explained to me that after injecting the practice the amount of rework they normally saw after each release went down to a fraction of what it had been. And, business stakeholders and users are more actively involved and engaged than ever before.
The UCD Perspective Before and After Agile
The UCD Perspective Before and After Agile
In this paper Heather Williams and Andrew Furguson describe performing lightweight usability testing electronically with customers over a long distance. It’s a minor point of a strong paper that gives great tactical advice for UCD practitioners working on Agile projects.
The RITE Method
Using the RITE method to improve products; a definition and a case study
This paper from several folks at Microsoft describes the RITE method – or rapid iterative testing and evaluation method for using usability testing to find tune and improve the design of software. This approach to testing is highly aligned with agile thinking, and is the approach I’m taking in the Use to User Interface course.
Decisions and continuous flow
I’ll start with introducing my first bit of information.
Yesterday I sat in on a class my friend Alistair taught at a local college. Alistair was speaking specifically about process efficiency and applying lean manufacturing principles to it. Well, designing and building software isn’t exactly the same as building a product in a production line… but, Alistair (and others) assert that it’s similar. The “parts” that move from station to station in our software production line aren’t car-doors, or engine parts, but decisions that people make. In “knowledge work,” decisions are the parts that eventually end up in our finished software. And, we don’t get real value out of that software until that software – the product of those decisions – is put into use. (more…)