Jedi Designer Tricks for Exploring Multiple Variations
Originally published on medium.com on December 16, 2015.
One trap I regularly see designers fall into is taking their first idea and fleshing it out in detail. That doesn’t sound bad. After all, if it’s a good idea, why not? You need to trust Admiral Ackbar: it’s a trap (which may be why so many fall into it so easily).
Often, our first idea isn’t our best idea, especially when we’re tackling a hard problem. We haven’t fully explored the boundaries of the problem. If we go down the first path too far, it may be too difficult to turn back.
This came up when I was talking to Chris Risdon about his upcoming UX Immersion: Interactions workshop on prototyping. He told me that he’s made it a rule for his teams to produce multiple variations of any design artifact before they start fleshing out any single idea.
Let’s say we’re working on a prototype of an app that helps parents locate nearby tutors for their kids (or even themselves). In this app, each user will need an account to connect with the tutor of their choice. If we want to prototype out what the on-boarding process might look like, our first variation would be create an account, then see the nearby tutors that are available.
We don’t want to stop there, so with another moment’s thought, we realize we could just reverse that order. In a second prototype, we’d first show a list of nearby tutors. The parent would create their account only when they’ve found the middle school math tutor they’d like to contact.
Now we have two prototypes to compare. Not bad. However… Stop there, a Jedi doesn’t.
Being Generative: Exploring Outside Our Comfort Zone
These two variations were obvious. The first idea, then the inverse of the first idea. Chris’s recommendation is you don’t stop there. Instead you study the problem a bit more and see where the journey takes you.
In both of these variations, searching tutors and putting in your account information are discrete, unconnected activities. What if we merged them, making them less discrete?
What if we built the parent’s profile by using the choices they make as they refine the tutors? We could glean their location, their child’s age, and the topics they desire help on, all by just seeing how they filter the list. That information could become smart defaults in their account profile.
Voilà! A third variation is now born!
Pushing beyond the obvious alternatives is what Chris calls “leaving the comfort zone.” Sometimes, by giving ourselves a little time and space, we can find additional variations that didn’t suggest themselves immediately, and these can have elements which are better than what we originally came up with.
We use these generative design techniques to explore possibilities. We haven’t spent a lot of time on each one, so we have more time to generate new variations. In turn, we learn more about the problem’s landscape.
Getting Feedback: Listening to the Voices Around Us
Multiple variations deliver a big advantage by helping us collect richer feedback than when we only have one version to show. We can get our peers and stakeholders to move beyond the “I like it” / “I don’t like it” twins, neither of which helps us learn what to do differently next time.
With multiple variations, we can ask our reviewers to compare the versions. We can hone in on our intention for each iteration. We can see if one intention does a better job of solving the problem than others. Most importantly, we can explore why the variations solve the problem (or don’t), using that new understanding for future iterations.
Still, there are more traps to avoid, such as the obvious question of Which version do you like best? We don’t care about whether someone likes a variation. We care about whether the variation does what it intends to do.
Our first variation of the tutor finder was about getting the profile built, so the user could start with better tailored search results. Given that was its intention, we can ask reviewers how well our variation achieves that goal.
What is it about Variation One that makes it better at getting users onboard than the other two variations? Why?
Where does Variation One fall short, compared to the other two variations, in getting users on board quickly? Why?
Each variation should have its own intentions, separate from the other variations to make it unique. As the team discusses the different intentions, a language emerges to describe the problem and its possible solutions. This deep exploration makes us all smarter about our designs.
The cool thing is using multiple variations doesn’t require a radical change to our process. It’s a way to keep us from falling into the trap of getting too involved with a single direction before we fully understand the problem.