The other day we were meeting with a prospective client (who will remain nameless, but let’s give them a nickname shall we? Let’s call them Acme.) During our ‘getting to know you’ meeting, we were looking at some of the UIs on their current products. The execs at Acme are fully aware that their current UIs aren’t working so well.
How do they know? Well, first of all, it’s pretty clear if you just look at them. It’s almost impossible to figure out what they are, to say nothing of how on earth to use them. Also, their current customers keep coming back to them asking ‘why can’t I do X with your product?’ Hence, they called us (and when I say us, I’m talking about Fell Swoop, dontcha know).
So there we were, staring up at the projection screen, at a seriously sad and confusing UI. And the Acme exec asked “how would you help us avoid this?” I thought for a minute. I thought about all the fancy stuff I know about user experience and customer-centricity and testing and metrics and wireframes. And then I realized that the answer was much more basic:
“Well, first of all, we’d want to figure out what question this thing is supposed to answer.”
Guess what? That simple sentence became the foundation for the rest of the meeting. Back to basics indeed…but basic waters run deep. In order to figure out what question something is supposed to answer, you have to figure out:
- Who’s asking (personas)
- How they are phrasing the question (and whether that’s even the right question to ask)
- What answers they expect (how the personas think, vs how you think)
- How your company and products can answer that question in a truly fabulous and unique way (business goals, value propositions, and differentiators),
- What you want your customers to do in addition to getting the question answered (like buy more question-answering-devices)
- Then, and only then, how to translate all this into a UI that actually works.
I think the problem is that most people start talking at #6. And that’s not where the answer is. It’s not about moving text and boxes and buttons around.
Long story short, apparently, after our meeting, the Acme folks went around muttering ‘what question is it supposed to answer? What question is it supposed to answer?’ and there have already been some pretty great results. For example, they told us that they asked a customer what he thought a particular product was supposed to answer. Guess what. The customer thought the product was supposed to answer question X, and it was actually built to answer question Y. Horrifying, yet also magical, because now that Acme can see the problem, they can fix it.