In the eyes of some (read ‘many’) a user experience professional does two things — Makes wireframes and performs usability. And those are generally the people who know a thing or two about building sites. That is fine with me. But I do think once we are sitting at the table with said people, we can educate them about the opportunities to gather really important user information and add some color to the term usability.
I accept the occasional genius design project, and i am not suggesting all of these steps for every project. Just pointing out that, just because it gets cut from one area, does not mean we have to abandon the user’s voice altogether.
Opportunity One: Before the pen hits the paper
“User Research” (Two types)
Shadowing: Your looking to make observations about behavior (am routines, workarounds to clunky software, etc.) and uncover evidence to support/debunk certain features and initial assumptions. This exercise is stimulus-free and relies on the observer/researcher to recognize tasks and trends in behavior.
Interviews: If shadowing is not an option, taking even 15-30 minutes of several user’s time can yield actionable trends. The key is not to focus on gripes about the current state. It’s not that great – that is why the project has been initiated. Focus the interview on tasks, goals, and needs. Try to observe the area the user sits too. Sticky notes and team calendars can tell a lot about the structure of the user’s time.
Opportunity Two: Once you have some sketches
To collect user feedback, show them some light stimulus — designs that represent a particular solution, or a few key flows. This excercis can provide a temperature check on that whiz-bang feature. The important thing at this stage is not to throw the baby out with the bath water. You’ve just got a sketch and the feedback collected is valuable, but the user only sees a part of the whole. User Feedback allows you to establish desirability of concepts.
Opportunity Three: Once you’ve fleshed out the experience
We always tell the user ‘this is not a test of you.’ It’s not. So this excercise is more about testing the experience. Depending on the fidelity of the designs at this point, it can also border on testing design choices. The key informatioon to gather are things like — Can people perform key tasks? Are the pathways clear? Are the labels understood?
This excercise is also a good place to settle the debates (political, design choice, etc) that often come up about certain features. The test can be used to find evidence (not a yes or no answer) that you are right or wrong in your assumption about the desirability and usability of the feature. A guerrilla version of this test can be used to get input from non-users on tasks that are not domain specific (e.g., “Hey Bob, How would you submit this form?”).
If you only have one shot – this is probably the one to take. It is not too late in the game and not too early for the experience to be understood. Many testing budgets (time and $$$) run out about here.
Opportunity Four: Once it works with the bells and whistles
Now the stakes are high. Its too late to change anything major, right? But you can finally get a sense of user’s success with tasks while using the living breathing app. This one makes it difficult to affect change on a release. If the process is one that allows for integrating such feedback into to shorter cycles or the feedback can be collected for a future release, this can still be a useful opportunity.
Opportunity Five: Once the users are actually using it
Ok. This name is a stretch, but theres a lot that can be learned by watching what users actually do with what was designed. It so frequently strays from what was intended in both delightful and painful ways (from a experience designer’s perspective).
This requires planning the behaviors you want to observe and determining the best metrics to accomplish that.
…the end… go on… see you next post.