I just completed my second annual New York road trip where I presented Effective Prototyping to the Tech Valley .Net Users Group in Albany on August 8th and the Central New York .Net Developer Group in Syracuse on August 10th. These presentations had a great turnout, with excellent audience participation and supportive feedback. I’ve very pleased by how they went. Many thanks to Andy Beaulieu and Chris Miller for making this happen.
Here is the blurb:
Software prototyping is an important UX design skill that many people “just do” but effective prototyping requires crucial knowledge and practices that aren’t obvious. As a result, many prototyping efforts aren’t productive and fail to achieve their goals.
In this talk, Everett will explain prototyping and its goals, compare prototyping to sketching, and explore the different types of prototyping. He will then give the eight rules for effective prototyping and show why those rules are so important.
Everett will review several commonly available prototyping tools (including SketchFlow), give nine criteria for evaluating prototyping tools, and evaluate the tools based on the criteria. He will conclude by showing some examples effective and ineffective prototyping in practice.
If you or your team is prototyping now or considering prototyping in the future, this talk is for you!
And here’s the deck: Effective Prototyping (1.2 MB).
I’m interested in presenting Effective Prototyping to other groups, especially to those within driving distance (New England, New York, Pennsylvania, Montreal, Ottawa) as well as places that I often travel to (Chicago, San Diego/So Cal, Washington DC, Seattle, Florida). If you’re interested, please contact me.
Joe works at a Fortune 500 company. On occasion, he needs to access Snarfbladt info for his customers. He discovered that the BladtBlaster 2000 allows him to request access to Snarfbladts from the BladtBlaster website. Joe is thrilled.
What’s wrong with this scenario? In short, everything. It’s not really a design scenario but a thinly veiled feature advertisement. Its only purpose is for the feature owner to say “somewhere out there is a customer who needs Snarfbladt info, so please don’t cut my feature.” Beyond that, it accomplishes nothing.
Unfortunately, most scenarios I’ve seen in practice follow this basic template.
New! To learn more, join our first virtual UX design class on scenarios on September 10, 2015. For more information and to register, check Effective Scenarios.
To better understand the problems with this scenario, let’s quickly review the history of scenario-based design. In the early days of the software business, there was very little software with very little capability, so there was a feature arms race. Feature-based design boils down to creating products with long feature lists and the product with the longest list wins.
The problem with this approach is that user don’t do features, they do tasks. So while having a long list of features might initially appear impressive, having many complex, poorly coordinated features doesn’t help users get their work done. As an alternative, task-based design is all about helping users get their work done, with efficient, well designed end-to-end tasks.
Task-based design sounds pretty good, so what’s the problem? The problem is that great user experiences are designed for their target users and task-based design doesn’t consider target users at all. Add the tendency for people to design for themselves, and task-based design often leads to designs that developers love but customers hate.
Great design requires designing for a clear target. Enter scenario-based design. What’s a scenario?
A scenario describes a specific target user trying to achieve a specific goal or task in a specific context or environment.
Or more concisely:
Scenario = user + task + environment
So, the difference between scenario- and task-based design is the focus on users and their environment. Good designs are useful, but great designs are usable and desirable by providing what users need. Design scenarios are about excellence, not acceptability. You can get to acceptable through good task design.
Best of all, a solid set of scenarios creates a decision making framework. Brainstorming? Review your scenarios to give you inspiration. Choosing between two alternatives? Use the scenarios to help you decide. If you aren’t constantly referring to your scenarios throughout the design process, you’re doing it wrong.
What’s wrong with the original scenario? Let’s analyze each sentence:
Joe works at a Fortune 500 company. A meaningless attempt at providing a description of the user and environment. This tells you nothing about Joe—he could be anybody doing anything anywhere. Not a clear target.
On occasion, he needs to access Snarfbladt info for his customers. At least we have a goal/task.
He discovered that the BladtBlaster 2000 allows him to request access to Snarfbladts from the BladtBlaster website. Here’s the advertisement that suggests why Joe wants the feature. But there’s a first degree scenario-writing crime here: the scenario provides the solution. Who says Joe wants to request access from the BladtBlaster website? Aren’t there other possible solutions? By putting the solution in the scenario, no other solution is possible. (Unless, of course, you ignore the scenario.)
Joe is thrilled. Another first degree scenario-writing crime. See why below.
It might seem like a small detail, but ending a scenario with a thrilled user completely undermines the scenario. Why? Consider Everett’s Rule of Scenario-Based Design:
If success is shipping a feature, you aren’t doing scenario-based design! Rather, you’re doing feature-based design.
Instead of using scenario-based design to figure out how to thrill Joe, we have guaranteed “success” by simply shipping the feature.
But who says Joe is really thrilled? What specifically about the design is going to thrill him? That information should be in the scenario, but it’s not. By adding those three little words, we’ve devolved all the way back to feature-based design. We’re now doing scenario-based design in name only.
Joe works in the shipping department of a large company, where he is responsible for the pickup and delivery of about 200 packages a day across 10 buildings. To maintain his aggressive schedule, he is always on the move, either with a cart or carrying a few packages underarm.
Between deliveries, Joe occasionally needs to access Snarfbladt info for his customers. The BladtBlaster 2000 allows him to access the Snarfbladts info instantly. Best of all, he can do it while walking, using a single hand with only three thumb strokes or less.
While the new scenario doesn’t have a specific solution or tell us that Joe is thrilled, we now have a pretty clear picture to help us visualize what might thrill him (as well as what might frustrate him.) It’s now up to us to design a solution that nails this scenario for Joe.
If you do only one thing:
Write scenarios that can be used as a decision-making framework. Provide details about users, goals, tasks, and environment. Don’t provide a solution because figuring out the best solution is the entire point of the scenario. And don’t declare that the user is thrilled because a feature exists. Provide the details for what it would take to thrill the user instead.
Congratulations! By reading this post, you have mastered about one hundredth of what you would learn by taking User Experience Design Essentials. What to learn more? Sign up now!