Derived from IDEO’s Method Cards, I’ve used these to help designers and developers learn to step back from their assumptions and view the product (both the UI and the UX) from the user’s perspective. They really help break the ‘curse of knowledge‘ that I encounter from people who know how the system should work but can’t see it from a person’s perspective that is not an engineer or a developer.
The Method Cards are broken down into four categories: Learn, Look, Ask, Try.
- Learn: Collect information, codify, gain insights.
- Look: What people do and what they say they do differs. Watch people while they work, including facial expressions and body language.
- Ask: Get people to interact with you and open up.
- Try: Do the role yourself. See where you struggle.
Whatever category you use make sure that the people you’re working with are comfortable and feel safe. This isn’t a critique of them, their knowledge, or their skill sets. It’s not an IQ test. You’re here to judge the products they’re using, not them. If they’re not comfortable giving their name or being on camera, don’t do it. Get their ok first, make it anonymous if necessary. Do not violate a person’s confidence.
Note taking: capture exactly what the person said, not what you think they said. If you can (and you have permission) get a picture of what they were doing when they said it. Ask them to show you again if you missed it. I’ve found it more useful the keep their comments in one font color and my commentary in a separate one, usually green.
Try
Experience Prototype
If you want to test your ideas quickly and cheaply, this is the way to go. I use Keynote to get a rough idea of what could work. I then use Sketch and Invison. Be careful when using these, people will get confused and think it’s actual working software. You’re looking for sticking points, frustration, anything that pollutes the experience. Refine it until you get it right(ish) and then test it on more people.
Ask
Interviews
Sit with people of varying degrees of experience with your product. Ask them to describe their experience. Have them show you if possible. If you have their permission then video the experience.
Learn
Flow Analysis
There are two of these. The first is a systems level description of how data moves through the organization. The second is a flow of each of the different types of roles that use your product. For example, if people from sales use your product, and people from marketing use your product, draw two separate flow diagrams for each role and at what stage they use your product. Invariably there will be a point where both roles struggle and this flow diagram captures that.
Look
Fly On The Wall
Watch people without interfering with them. You need to get approval first but this method finds all sorts of problems. Watch how people work, don’t ask questions, just capture what they do. I always have more questions at the end of these sessions and I usually roll into one-on-one interviews. I never do group interviews, people always look at each other for validation and then it turns into a gripe session.
