Design to Learn. Beware the Completionist Approach.
Has your Product team created a “pixel perfect” design before even talking to users?
Does the initial design have more than 10 screens?
If so, the designs are overbuilt and too big to learn from.
Avoid a Completionist Approach
This “completionist” approach focuses on creating everything up front.
For example, teams often make both mobile and desktop versions before user testing.
Test in one format first. Don’t scale a design to other formats unless you know it has value.
This way, you don’t risk time and energy on concepts that users might not want.
Teams create these complete designs since their first audiences are often design managers, internal stakeholders, steering committees...that demand this completeness.
Instead, the first audience should be the customer.
If you’re in a design review, the first question to the Product team should be about what they have learned from users, not to express your personal requests for clarifications or features.
Without reinforcement from colleagues, Product teams often drift away from working with users.
Look for these symptoms of a “completionist” approach:
Skipping user testing. Teams get attached to concepts the more time they invest in them (“We’ve worked so hard on this, it must be right”) or they run out of time.
No experimentation. Large scope allows designers to create only one option instead of multiple alternatives; you end up committing without experimenting and validating multiple options.
Missing insights. With wide scope, it’s hard to focus on the screens where most value will be delivered.
For example, in an ecommerce flow, a “completionist” user test might extend from finding a product to completing the purchase. A Design to Learn approach would zero in on the Add to Cart component of the experience and explore whether the user would buy now or go to a competitor.
Getting discouraged about Discovery. The complexity and duration of Discovery grows exponentially with scope. With so much to test, teams will reflect on their efforts as too long and involved and be much less likely to try again.
Choose the Design to Learn Approach
When you Design to Learn, you create smaller designs that are “realistic enough”, not “pixel perfect”.
They are quicker to make and they still get high quality feedback from users.
Here’s how to adopt a Design to Learn approach:
Design one component of the flow first. Start where it matters…every experience has one or more “moments of value” where the user benefits from your offering. Design and validate these screens first.
Create multiple variations to spur innovation. Don’t argue over one specific flow. Before you do A/B testing, you should be testing multiple variations in the design phase (it's cheaper). You’ll get more actionable feedback with a variety of solutions that can be compared and contrasted by the user.
Don’t overbuild. For example, don’t build login screens when testing early designs. Stay focused, don’t build out details that are not part of your user test.
Agree to create “realistic enough” designs. “Realistic enough” is faster and puts your team in front of users sooner.
What Good Looks Like
For example, instead of testing an entire ecommerce experience, just test the Add to Cart functionality.
Start with a simple page to ease the user into the page where they will Add to Cart.
Then, make multiple different Add to Cart experiences and test all of them.
Be sure to include the current experience (if there is one) to understand how new ideas compare to the existing solution.
In the end, you’ll have several short solutions that test one specific hypothesis rather than one long solution that includes everything.
Using this method:
You talk to users sooner
You stimulate innovation by testing a variety of solutions (take risk!)
You have shorter interviews (less intimidating, easier to analyze, more likely to do customer testing again)
Your analysis is quicker since you’re only evaluating one Primary Hypotheses at a time
There Will Be a Next Time
Remember that it’s okay to build a less functional prototype.
It’s okay to remove interactions and use cases that you are not testing.
Ideas that get cut can be brought back for the next round of user testing.
As you discover, validate and launch smaller components, you can assemble a world-changing user experience one success at a time.
* Significant editing made by Noam Livnat.
Jim knows how to build and scale successful products.
He co-founded PowerReviews which grew to 1,200+ clients and sold for $168 million. He product-managed and architected one of the first ecommerce engines at online retailer Fogdog.com which had a $450 million IPO.
These days, he coaches Product teams and leaders at startups and corporations to use Product Discovery to validate and test their ideas before building them. He’s created a custom curriculum and training program that pulls from his 25 years of experience and the best minds in Product Management. He graduated from Stanford University with a BS in Computer Science.
Jim is based in San Francisco and helps clients engage their customers to test and validate ideas in ecommerce, machine learning, reporting/analysis, API development, computer vision, online payments, digital health, marketplaces, and more.
