I regularly come across product specification documents, strategy statements, even user stories that have the phrase “intuitive UI” written. The team working on this product believes they will be successful in the market with a “great user experience” and want to make sure that time is alotted for that work to take place.
This is admirable. It’s also a waste of time.
You’d be hard-pressed to find any organization, service provider or company that deliberately sets out to ship unintuitive user interfaces. In the same way that no author deliberately sets out to write an “unreadable book” or no chef sets out to cook an “inedible meal” , no organization ever wrote a product requirement that stated, “make it difficult for our users to understand how to complete this task or process.”
When I tweeted about this last week, many of you were quick to reply with questions like, “Have you ever used a government website?” or “What about Salesforce?” I have. They can be awful (sorry Salesforce designers). However, do you think that the product teams at these organizations explicitly decided to make it difficult to apply for a residency card, figure out when the next bank holiday is or create a compelling communication to a prospective client? I guarantee you that they did not.
Do bad user experiences exist? They do. Many of the teams who shipped those products (and continue to do so today) had some version of “compelling user experience” or “easy to use interface” written in their user stories. But by stopping there — at the infinitely vague superlatives of “compelling” , “easy” or “intuitive” — those teams didn’t do the work of figuring out what would make the use of their products actually intuitive.
Without the specificity of how that UI is going to be intuitive or easy to use or compelling the teams have actually said nothing at all. They’ve abdicated their responsibility and their opportunity to positively impact the end user.
Context, target audience, and desired outcomes are just a few considerations of the design and success of your UI. The feature hypotheses that meet those considerations are the items that end up in your user stories. Will it have 1-click shopping? Will it repurpose information we already have about the client to reduce the time to complete a new mortgage application? Will we serve upcoming local municipal deadlines based on their IP address?
When “intuitive UI” becomes something specific and tangible we can plan actual work. We can prioritize that work. We can measure that work to determine if indeed our implementation of it was found to be intuitive by our users.
The next time you see these phrases in your team’s planning documents, recognize it for what it is: incomplete. Push the team to do the rest of the work, to identify a target audience, their needs and how exactly we’re going to make this the best user experience we can for them. Anything short of that is ensuring that as long as some UI gets shipped (and rest assured, it will) we’ve met our requirements.
It’s my experience that these phrases appear because they’re shorthand for “intuitive to me” and reflect an unwillingness to invest the time and money in doing the research that would validate such hypotheses. So yes I agree that we need to drive teams past these throwaway phrases, and also recognize that doing this may require additional investment.
I’ve worked on projects where “intuitive” or “easy to use” has certainly been part of the vision, but we always setout to qualify our products ease of use by undertaking usability testing at key phases of the project – in the form of card sorting for IA, prototyping for high-level design, then actual UX testing of the almost-complete product.
For that penultimate step, we would identify the end states or goals for a given product or feature and turn those into user scenarios to be observed during testing with our actual target audience.
These results would then provide us with measurable feedback on the success/failure of our product’s “ease of use”. Always a valuable experience.