You Fight Like a Designer
Randy Fisher • Apr 13, 2016
Our product needs a great UX!
While the previous statement is well-intentioned (and I am certainly glad the value of design is now accepted mainstream for the most part), it’s starting to become cliche. It’s getting watered down. We used to have to fight for it, and I think it was the fight that made us work harder to prove to clients, execs, investors and ourselves...that we are doing the right thing.
As designers, we leverage research and other tools like personas to build empathy in order to understand and design experiences. We follow how others in our craft do it and leverage the patterns that emerge. However, I still find that for launching a new digital product, the most fundamental tool at our design disposal is often neglected. Many of the designers I talk to across the globe are still reluctant to do real user research early in the process. Mostly they say they believe in the benefits fully, but their actions (or lack thereof) don't match their words.
Testing early concepts with real users can provide confidence or expose grave weakness in your design approach, but how realistic should your prototype be and how early is too early in the process to talk to people?
What we found might just change the way you approach design today…
“Testing early concepts with real users can provide confidence or expose grave weakness…”
- RANDY FISHER, DEVELOPERTOWN DESIGN PARTNER
A little background
I have been thinking about this a lot lately, and I recently read "The Fidelity Curve: How to weigh the costs and benefits of creating UI mockups” on the Signal vs. Noise blog. In the article, the author is basically trying to convey the understanding that trade-offs can help you make more rational, economic decisions. He included the following visual to help make the point.
Although I didn’t feel comfortable with the ambiguity of “confidence gained” [real user research was never mentioned], the article was interesting and really got me thinking about what and when we first unveil to our potential customers.
How we believe it should be done
Here at DeveloperTown, we believe there are two fundamental questions we need to answer as quickly as possible and with the highest degree of confidence when launching a new digital product:
- Are we building the right thing?
- Are we building the right thing right?
The goal of the first question is to determine product-market fit or if someone would actually “buy” our product. Our crack marketing team wrote an insightful post on this very topic in case you missed it: The Number 1 Reason Why New Products Fail
The second question, however, is aimed directly at validating our design approach once we are relatively confident we have product-market fit. It’s an attempt to make sure the big assumptions we have made based on our research are in fact on-target. So the question is: when should I show my designs to potential customers to start collecting feedback? Our answer is always the same: as soon as you have enough information to take a shot at detailing the most important user experience in a realistic way.
To help understand how early we should begin testing, we conducted user research of our own using our eye tracking software.
What we did
We gathered up 25 participants to test two different scenarios on a fictitious shopping website. To track their results, we used an eye tracking software that produced heatmaps of where our users stared. We tested two different versions of this site, and the participants were given one version at random. Version 1 was the actual website: real code with color, images, and full design detail. Version 2 was a sketch-like wireframe we created in 2 hours using Balsamiq. This version had the same layout, but was in grayscale, used basic icons, and some text.
What we found
Based on our findings (and over 130 projects under our belt) it’s our belief that you can *and should* test early versions of your new designs to make sure they pass the sniff test or miss the mark completely. Both are wins at this early stage.
However, we found that testing sketches and lo-fi wireframes is ineffective. In fact, even though the scan paths and fixation points were almost exactly the same between the real code and the Balsamiq mockup, the users fixated for a longer time on the Balsamiq version (3-5 seconds on average). They also took longer to complete the tasks (7-12 seconds on average), and asked more clarifying questions on the Balsamiq mockup.
TASK 1 — GIFT CARD BALANCE CHECK
TASK 2 — LAMP SALE INFO
OUR TAKEAWAY IS THAT YOUR PROTOTYPE NEEDS TO BE AS REALISTIC AS POSSIBLE TO AVOID THE MENTAL WEIGHT OF THE USER TRYING TO INTREPRET WHAT THEY ARE LOOKING AT INSTEAD OF FOCUSING ON THEIR EXPERIENCE WHILE COMPLETING THE TASK.
What it means
With the tools and resources available today, it's not difficult to get to a realistic prototype quickly.
Among other things, we are using our version of the Google Material Design Template for SketchApp, content plugins like Craft, and the InVisionApp Prototyping Tool to help us get to a realistic prototype quickly.
With that lineup, our path to testability looks more like this:
Free (unsolicited) advice
UX Newsflash: the “U” stands for “user” and talking to them can yield insightful information and prevent major design misses. The question is not "if", but "when", and always with a realistic prototype.
Fail fast and you can go back to the drawing board and try again armed with invaluable insight. It’s a low cost design insurance policy that can prevent catastrophic waste and rework down the road. I’m not talking about full-blown usability lab testing here, just get out of your building and ask five customers for their opinion. Then see if they get it.