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.