John Saddington
As we build out our early-stage product (and find great folks to Alpha Test it) we’re naturally working on all of the things related to the back-end (e.g. data, modeling, etc.) as well as the front-end (e.g. design, UI/UX, etc.).
The exciting and yet challenging thing at this point is that we have a completely carte blanche environment and anything that we do initially isn’t inherently wrong or qualitatively bad.
Of course, on the flip-side, we can’t be sure that we’re doing anything right or well either. The only answer, of course, is the combination of rapid experimentation in conjunction with early customer interviews, which is what great startups will do naturally.
Some of the most poignant and powerful lessons-learned so far have also been some of the most obvious. Or, at the very least, “obvious” in hindsight.
You see, the biggest challenge that a product team has especially in the beginning is essentially getting out of your own head. In other words, as a consequence of proximity (i.e. being so close to the product) you develop natural blindness to design elements that you feel are obvious and intuitive but are, in fact, not.
A great example of this is how we show data to the end-user. Take for instance this one screen of contributions:
The first thing you’ll see for this particular user is, well, nothing. The “obvious” thing that I would do is immediately move toward the drop-down menu over on the right and change the time band:
The problem is that many of our Alpha Testers missed this drop-down completely! I would literally sit there and watch them get to this part of app and they would pause and then move on.
And it takes everything within me to just watch and observe instead of yell into the mic (or if it’s a in-person walk-through I’d want to tap them on the shoulder…) and tell them to hit the drop-down!
But the reality is that the placement of the drop-down wasn’t obvious, it wasn’t intuitive, and it was just visually being overlooked and missed.
Why? We’re still not entirely sure scientifically but we have our hypotheses and we certainly have enough empirical evidence that it’s being overlooked and missed.
Which, of course, is super-depressing because the user completely misses out on all the rich data that we’ve pulled about their current team and development environment and all of the actionable insights about their EngOps universe:
Obviously, this is what we’d like them to see but they just never get there.
So, rethinking the UI for a more natural UX was in order and designing the interface in such a way where it would be both impossible to miss became an obvious opportunity for improvement.
Quite literally, we had a real Dilbert-moment and “moving the button” creates a significantly-improved user experience that results in the end-user getting the data that they came for.
It seems obvious, now, but it wasn’t when we were building it and that’s the point: Product design blindness is real, even for the most experienced product teams.
I feel like I’m beating a dead horse at this point but it’s just worth stating, one more time: What seems obvious isn’t guaranteed to be obvious in the real world, with real customers, when it counts the most.
So do your live-fire tests with real folks and prepared to get served some humble pie. It doesn’t always taste sweet but it’s good for the soul (and the product).
Also shared on Medium.
This is just a small sample! Register to unlock our in-depth courses, hundreds of video courses, and a library of playbooks and articles to grow your startup fast. Let us Let us show you!
Submission confirms agreement to our Terms of Service and Privacy Policy.
Already a member? Login
No comments yet.
Already a member? Login