Roles of User Experience Design: User Research
This is the second post in a series on User Experience design. See other posts here:
User Research
Definition
User research means learning about your users – your customers – by gathering data and testing designs for the two purposes of discovery and evaluation. User research answers questions like the following:
- What is the user’s workflow for their job (or given tasks)?
- What do users want to ultimately do?
- What terminology do they use? (what’s their domain language?)
- How well does your software help users do what they need to do?
- How well does the software match users’ mental model of what they expect it should do?
- What parts of your software do users find confusing?
- What parts of your software do users love?
The data you get from user research is both quantitative (hard numbers and statistics that tell you what is happening) and qualitative (observed behaviors and user rationales that give you the context of why).
How it fits into Agile
The trick about Agile and UX is that Agile development already involves user research.
Agile has a discovery process, in which we gather user stories from actual users and map them into goals, activities, and stories on a story wall. Discovery is about learning how users do their tasks and how your software can help them do what they need to do efficiently.
We also do evaluations, in which we show our designs or working prototype code to the customer (as a user or user advocate) for feedback, at the end of each iteration. Usability testing has a reputation for being formal and summative (when everything is done), but it’s just as useful when formative (while you’re building things) and the Agile methodology (done right) actually has an insertion point where the user research that has been gathered can usefully inform the on-going product development.
Making it a more formal part of the process gives Agile development three benefits:
- It makes getting feedback from users an explicit part of Agile development, so that we can get the info we need at the end of each iteration, throughout the design and development process, and make quick course corrections.
- It gives us a “utility belt” of best practices for gathering data and evaluating software with users, so that the information we have is more accurate, and saves money and time.
- The data we gather helps us make models of how users think and act, and having a rich model means that designing (and redesigning) is much more rapid.
User Research methods
User research gathers data through a variety of methods. The methods we most commonly advocate are:
Field observations (watching users’ behavior in context)
- semi-structured interviews (asking users both prepared and extemporaneous questions)
- data logging (collecting statistics on software usage)
- diary studies (asking users to record their experiences)
Usability testing puts designs (sketches, or prototype code) in front of users, and then uses all of the methods above to get feedback and evaluate design decisions. [We've written far more information about these methods over here.]
What deliverables can I expect from User Research?
Data gathering gives us the information we need to build a model of the users. This generally manifests itself in personas (write-ups describing the different typical users of your software) and in the user stories of an Agile story wall. As further data is gathered, the stories may change, and the story wall is an evolving model for a user’s workflow and needs.
Evaluation findings and raw data are kept in whatever system the team is using to document design. We recommend a wiki or blog as a repository for user research findings (and as a journal of design decisions for the rest of the UX design).
Findings should identify problems that need fixing and provide data to support the finding.
Example: a wiki page with video that shows a user getting confused when trying to submit a form on a specific screen of your application. (There should be video of both the person’s reaction and the screen they see.)
User research informs decisions and makes recommendations, but should not prescribe how to fix the problems identified.
Keep in mind that there is no such thing as “fixing problems proactively”. Every piece of software is going to have problems and every piece of software is going to need to have the experience fixed. Many people have the idea that a good enough UX designer will be able to spot problems with their magical designer intuition and fix them without any contact with the target users. While there are best practices in terms of layout, color, type and flow, it is impossible to build a perfect application on the first try.
Where in the development process does User Research fit?
User research should occur throughout the entire design and development process. Before any coding begins and iterations begin in earnest, it is a vital component for properly identifying stories and the tasks associated with them.
For more specific information about how to implement the various user research tasks into the development process, see the chart in “User Experience and App Workflow”.
What benefits can I expect from User Research?
As mentioned before, user research is already a native part of Agile methodology; you’re not buying something extra by doing user research. If you don’t do it, you’re taking something OUT of Agile and weakening the strength of the methodology in the process.
As stated above, formalizing user research helps you set up an infrastructure for getting feedback on a more regular basis so that you can be more agile, and helps you be the most efficient and get the most accurate data when gathering feedback from users. User research helps you better understand the needs of your customers, identify software requirements, prioritize features and drive product strategy. This results in spending appropriate time and money on features that deliver the greatest return on investment (ROI).
(Silverlight/WPF technologies have some specific ROI benefits for gathering data. See below.)
How do Silverlight/WPF technologies help me with User Research?
The biggest aspect of the current Silvelright/WPF technogies that aids in user research is the SketchFlow application that comes as a part of Blend 3 (and later versions).
In early product planning and development, SketchFlow lets you mock-up an interactive prototype that you can put in front of users in order to quickly collect feedback. While the system is not yet perfected, it offers significant savings over traditional shoe-leather data gathering.
For more developed projects, it is possible to hook Google Analytics into Silverlight projects and let it listen for certain events. However, the most effective (and cheapest) method we’ve found is the old fashioned methods of user interviews and observation.
Additional User Research links
D. Chisnell. Usability Testing Demystified. (2009)
http://www.alistapart.com/articles/usability-testing-demystified/
Straight-forward explanation of what usability testing is, how to do it, and why it doesn’t need to be formal summative testing.
S. Krug. Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition. (2005)
http://www.amazon.com/exec/obidos/ASIN/0321344758/ref=nosim/advancedcommonse
S. Krug. Rocket Surgery Made Easy: A Do-It-Yourself Guide to Finding and Fixing Usability Problems. (2009)
http://www.amazon.com/exec/obidos/ASIN/0321657292/ref=nosim/advancedcommonse
Excellent books, with some of the best advice on low/no-budget usability testing we’ve seen.
R. Jones, N. Milic-Frayling, K. Rodden, A. Blackwell, “Contextual Method for the Redesign of Existing Software Products,” International Journal of Human-Computer Interaction, 2007, 22(1-2). (Original paper dated 2004.)
http://research.microsoft.com/apps/pubs/default.aspx?id=70095
Great practical overview of many of the methods described above, courtesy Microsoft Research.
