• Introduction to User Experience (UX) Design

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:

1. 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.
2. 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.
3. 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.

In this series of blog posts (tagged with UX Methodology), we at Veracity Solutions will try to elucidate how this process works for us.

This post is an effort to clear up some misconceptions about UX design and identify some common terms and roles to expect when doing UX design… especially within an Agile development environment.

The 5 Roles of User Experience

There are five terms that cover the tasks that can be expected in a project implementing effective user experience design. Keep in mind that this does not mean you need a small army to run your UX design initiative. Most UX designers can spearhead more than one of these roles. But it is important to remember that these roles each involve time (also known as money) and each role is important to the process.

Without further ado, the five UX roles are:

• User Research
• Information Architecture (IA)
• Interaction Design (IxD)
• Visual Design (VisD)
• UI Development (UI Dev)

For each of these roles, we will cover the following:

• Definition of the role (what it is, what it’s for, how it’s done)
• Deliverable (what do other people on the team see)
• Where in the dev process this role take place
• Tangible (profitable) benefits
• Silverlight/WPF technologies that facilitate this task

All of our work is done in using the Agile methodology and a good deal of it is done in Microsoft technologies. As a result, we’re focusing this series with those two concepts in mind. This doesn’t mean that people who work in non-Microsoft technologies will be lost at sea. Only that those who do use the Microsoft technologies will find additional information specific to WPF and Silverlight development.

The chart below is quick summary of how these roles fit together. The blocks indicate where the roles take place and the text near the arrows indicate what kind of deliverables come from each role and inform the next role or step in the design or development process. We’ll highlight how these roles work together in more detail in the coming posts.

For more on UX and Agile, make sure you read the Scott Barnes post Can You Mix UX with Agile and Anthony Colfelt’s Bringing User Centered Design to the Agile Environment.

More to come…