User Testing as a way to get feedback from people about a product is still going strong. In this episode Susan quizzes Guthrie about the what and how of user testing, and talks about some of her fun and more memorable moments of the hundreds of tests she’s conducted.
HumanTech is a podcast at the intersection of humans, brain science, and technology. Your hosts Guthrie and Dr. Susan Weinschenk explore how behavioral and brain science affects our technologies and how technologies affect our brains.
You can subscribe to the HumanTech podcast through iTunes, Stitcher, or where ever you listen to podcasts.
With Lean UX all the rage (deservedly in my opinion — see my recent slideshare on Lean UX), user testing (an important part of the Lean UX process) is getting even more popular. If you need to convince someone(s) in your organization that user testing is important — well, not just important but CRITICAL — try this video below. It’s an introduction video to my User Testing course. And if you are interested in the course I’ll be teaching it in San Francisco on July 31, 2014. Bring the whole team! If you are already convinced about how important usability testing is, then stay tuned for an upcoming blog post on Bad Usability Testing Habits To Avoid.
There is something about September that makes us all want to sharpen our pencils and learn something new. And so we are very excited to announce the launch of 4 brand new in-person classes that we are offering in Chicago, San Francisco, St. Louis, Edgar WI, and Washington DC. I’m teaching some of them, but we also have some of the BEST and most experienced instructors teaching some as well.
Don’t Guess: Test! The Why, What, and How of User Testing (Chicago, St. Louis, San Francisco, Washington DC)
How to Design Intuitive and Usable Products Through User Research (St. Louis, San Francisco, Washington DC)
The Science of Persuasive and Engaging Design (Chicago and San Francisco) (
To celebrate the course launch I’m writing a series of blog posts to highlight each course.
So here are 3 reasons why I’m excited about the Don’t Guess: Test! The Why, What, and How of User Testing course:
1) We’re partnering with UserTesting.com and they are going to provide us with FREE tests to use in the class, as well as giving every participant 3 FREE User Test Coupons to use after the class when you go back to your office to apply what you’ve learned.
2) With the free in-class test, you will conduct an actual user test during the course. You will decide what to test, who to test, write the test scenario and tasks, conduct the test, and watch the video.
3) Always wondered what to test? In this course you will learn how to write a usability specification and use that to guide you in deciding who to test, what to test, and what the success criteria should be. And you can use these usability specifications not only in user testing, but also in design.
The “Don’t Guess: Test!” course is intensive, hands-on interactive, and fun.
Text me at 847-909-5946 or send me an email at email@example.com by September 30, 2013, and I will give you a code to use during registration that will get you 25% off the course fee.
In the next post I’ll talk about the How to Design Intuitive and Usable Products Through User Research course.
I’m going to be somewhat honest here: I’m no “spring chicken”. I don’t know if I’m prepared to tell you exactly how old I am, but here’s a story that will give you some hints: When I was in graduate school I had to file a formal appeal with the dean of the graduate school in order to get approval to create and submit my dissertation on a computer rather than typing on a typewriter. That hadn’t been done before and they weren’t sure it would be allowed (they did allow it).
Suffice it to say that I’ve had a long career in my “field”. But even after all this time I, and many others, are still struggling with what the field is, what it is called, and how to describe what we do. You’d think we’d have had it figured out by now, but we apparently haven’t.
So what is it that I do anyway? I use psychology and brain science to predict and direct behavior. A lot of my history has to do with designing the interactions between people and technology. Because I’ve been in the field so long I pre-date the term “user experience”. In fact, I pre-date many terms, including: usability, user friendly, user-centered design. The term I, and many others, tend to use most often is “user experience” but many object to the term “user”. And ask 10 “user experience professionals” what they do and they will tell you 10 different things.
Jim Jacoby has a post at the admci website with a great video of Peter Merholz speaking at a conference about what user experience really is, and what the work really is. I don’t agree with everything Peter says, but it is a thought-provoking video, and it got me thinking not only what user experience people do, but about the term “user experience”.
I’d like to use a different term to describe what I do, but I’m not sure what that would be.
Customer experience doesn’t work because a lot of the experiences I am designing aren’t for customers. They might be for employees, or visitors. Is a museum visitor really a “customer”? I know the employees at Wal-Mart aren’t “customers”. And people going to their government website to do self-service are not really customers either. I’ve designed for all of these audiences, so “customer” doesn’t really work.
Then I thought perhaps I’d just describe it as “Experience Design” or “Behavioral Design”. But that brings us into the thorny area of what “design” means. Is it visual design? Interaction design? And sometimes I’m not even designing. I’m evaluating, or strategizing what the experience should or should not be. But the terms “Experience Strategy” or “Behavorial Strategy” seem just as bad as “User Experience”.
A rose by any other name is still a rose?
What do you think? How do you describe and name it?
I attended and spoke at the Virtual conference from Rosenfeld Media today “31 Awesomely Practical UX Tips”. Each speaker presented their favorite user experience tips. I took one tip from each of the speakers as my favorite. Here they are:
Steve Krug — Test your competition/comparables. Before you choose a design path or design idea, find someone else who is doing it and run a user test of their site/app/product. That way you can see what works and what doesn’t before you even start your design.
Whitney Quesenbery — Many of the best designs we all use started out as products designed for accessibility, for example, rolling mail carts for postal delivery people (started off being used by women since it wasn’t believed they could carry a heavy load) and Good Grips tools from OXO (started as special tools for people with arthritis, but now they are just known as well-designed tools).
Jeffrey Eisenberg — Instead of designing to fit your selling process and selling cycle, design instead to fit the customer’s BUYING process and buying cycle. These are not the same thing.
Aaron Walter — Stop designing in Photoshop. Use something like Bootstrap where you can see what things really look like and you can concentrate on the “system” not the “page”.
Luke Wroblewski — 75% of people using smartphone apps are using one thumb — Have you designed for one thumb use?
It was a GREAT day of learning. It was hard to just pick one from each!
A task analysis is the one document that really spells out what the users’ experience is going to be before you design anything at all.
I think the process of task analysis ,and the document that comes out of the process, are some of the most interesting and useful things one does as a UX Designer or a usability specialist.
I also think that task analyses are underappreciated. It does takes time, energy and creative thought to come up with a useful task analysis and people are usually “chomping at the bit” to start design. They often don’t want to create a task analysis first.
Quickly & efficiently document how the users are going to get their task done — Before you start storyboarding, designing screens, or creating user requirements documents, try creating a task analysis first. When you do a task analysis before design you are deciding on the most important and critical tasks and detailing in a simple diagram how the user is going to accomplish each one. All the work you do after this will be much more efficient because you will have hashed through lots of alternatives early on.
Use the task analysis document to communicate critical design decisions BEFORE design — Not only will the task analysis help you in your design, it will help you communicate with others — stakeholders, programmers, visual designers.
Get design agreement on the user experience early & upfront — By working on a task analysis you are making design decisions before design. So your whole team is coming to agreement on what the design will be like early and before design begins.
Save time & re-work — Because you have worked through a lot of design decisions in order to create the task analysis you can save a lot of time and rework later. Instead of starting on design and then having to change all your storyboards or prototypes, you can work through the issues and decisions about the user experience before design and save yourself a lot of rework.
Ensure that the design is accepted by the team AND matches the way your users want to do a task — When you work together with your team on the task analysis you are making a series of decisions that everyone buys into as the task analysis document gets created. Not only that, because a task analysis is describing how the users are going to complete a task, you are ensuring that the users’ point of view and desired process is incorporated into the task analysis. So when you design from the task analysis you will be designing a user experience the way the users want to do it.
Task analysis — the unsung hero of a user centered design process!
What do you think? Do you develop task analyses documents before you design?
I find myself these days working on two streams: on the one hand I’m working on my next new project (which is another book called “How To Get People To Do Stuff”) and on the other hand I’m recording a series of online training videos that cover the basics of doing usable design. Sometimes I think we get all caught up in new stuff and new ideas (Pinterest! apps!) and forget about the great stuff we’ve all worked hard to figure out… like personas and scenarios!
Developing and documenting personas and scenarios as part of a design process is not new. It’s been around for at least 30 years, and maybe more. But I was recently reminded of how powerful they both are in ensuring you do great design.
So in case you have forgotten WHY using personas and scenarios on your project results in great design, or in case you never knew, or in case you know but sometimes have a hard time explaining it to others, you can use this blog post, and the short video that goes with it, to remind yourself and/or explain to others.
4 Ways Personas & Scenarios Result in Great Design
1. Bring assumptions into the open — When you do design there is always a moment (actually dozens or hundreds of moments) when you are deciding something. For example, should I put the button here? What should I call this? Should I separate this into 2 pages? Whether you are aware of it or not, at that moment you are making that decision, you have many assumptions operating about your audience, who they are, what they are trying to accomplish, etc. Some of those assumptions are based on your knowledge and facts, other assumptions are probably biased, as in, “I think this would be best” (implying your audience will think so too, but that might not be the case, since you are likely not your audience). When you take some time to develop personas and scenarios before design then you are bringing all these assumptions out in the open. You can see if your assumptions are the same as your other team members. You can see if your assumptions can be validated.
2. Ensure you are designing what your audience needs & wants — How can you design what your audience needs and wants if you don’t know what they need and want?! When you go through the process of creating personas and scenarios you are collecting data on what people really need and want, not just what you think they need and want.
3. Design for what is critical & important, not the exception — The process of creating personas and scenarios is the process of deciding “if we can’t design for everyone doing everything then let’s concentrate on the most important users doing the most important things.” You have to identify what’s important, what’s frequent, what’s critical, and what’s an exception. Then when you design you can be sure you are designing for what 80% of the people need/want to do 80% of the time, instead of being distracted too much by exceptions — things that rarely occur or aren’t that important.
4. Communicate clearly — How many times have you left a meeting sure that everyone is all in agreement about the audience and the scenarios for the product you are designing. But if you don’t document those decisions they are easily forgotten, or they change over time. When you create personas and scenarios you have documents that you can use throughout the project to communicate clearly to other team members, as well as stakeholders, what the decisions and design parameters are.
What do you think? How do you think personas and scenarios help create great design? Are they used in your organization?
For more on personas & scenarios, you can watch the first couple of lessons of the new course for free.
I met Caroline Jarrett in 2010 in Lisbon Portugal, where we were both speaking at a conference. Caroline is a usability consultant in the UK, and she specializes in designing forms. She has a great book, Forms That Work. In this podcast Caroline and I have a fun conversation about designing usable forms.