Intuitive software. Everyone wants it, but it’s an elusive goal. Too often in corporate IT, the definition of what is intuitive is left to business leaders applying the Potter Stewart test: “I’ll know it when I see it.” The predictable result of that is, of course, that we deliver software that is intuitive to our business leaders, not our users.

We need a better, more objective definition of intuitive. A good place to start is with a common definition for intuitive software. This definition says that intuitive software is software that meets the users expectations. This leads to more interesting questions. What does the user expect? What is shaping those users expectations?

For most problems in corporate IT, where software is being created for specific domains, user expectations are driven by two primary forces: the user’s understanding of the domain and other software the user uses.

Let’s consider digital banking as an example. Digital banking is designed to allow a financial institution’s customers to access products and services anywhere. How do we make digital banking meet the user’s expectations?

First, we look at the user’s understanding of the domain: banking. Unless you’re working for a financial institution that caters to them, the majority of your users will probably not be financial services professionals. So, digital banking will need to make financial services understandable to people who are not experts and may even have no understanding at all.

For digital banking, the development team is not the user. They’re technology experts. Most development teams understand this to a degree. Importantly, leadership and internal stakeholders are not the user either. They’re financial services experts.

A good place to being exploring the needs of digital banking users is exploring what financial services laypeople struggle to understand. Where do financial institution employees encounter understanding gaps on products and services? Where can software make interactions easier by helping to bridge those gaps?

Second, we look at the other software digital banking users are likely to use. When I suggest this, usually the conversations in meetings goes immediately to what other FIs are doing. But, it’s worth thinking about how much influence other digital banking solutions have on users.

A good friend of mine likes to say that “banking is a maintenance activity.” By this, he means that we do it when we need to and then we get on with our lives. Brett King’s Quora answer on this subject paints a similar picture:

The average American uses Internet banking 7-10 times per month; and mobile banking 20-30 times per month. The time spent on each task varies from a few moments to check your balance, thru to a series of bill payments most commonly. Meaning that it’s really only a collection of minutes each time.

Now, let’s consider social media. The average American spent over 2 hours each day on social media. Here are some key stats from TechJury:

An average user spends 2 hours and 24 minutes per day on social media in 2020.

50.1% of the time spent on mobile is done using social media apps in 2020.

Facebook is the most popular, costing people an average of 2 hours and 24 minutes each day.

Youtube takes an average of 40 minutes per day.

Users spend an average of 30 minutes per day on Snapchat in 2020.

Instagram users are spending an average of 28 minutes on the platform daily in 2020.

Pinterest users take it slow and scroll through ideas for only 14.2 minutes every day.

What is going to be more influential to digital banking users’ expectations? Minutes a month on competing digital banking solutions or hours a day social media?

Lastly, we test with users. The only way to verify that we’ve met users’ expectations is to check with them. The first two steps are designed to allow us to make more intelligent design decisions, but these can only be viewed as hypotheses until they are tested.

So, now that we’ve been through an example of how to meet user expectations, do you think it’s enough to creative intuitive software? Or is there an element missing from the definition?

I believe the definition does fall short. A piece of software can target its expression of the domain to the users’ level and make sure to use common interaction patterns and still not be intuitive.

Intuitive software is gracious. It not only provides users the ability to do tasks, it helps them do the tasks right the first time. If users mess up (and they will), gracious software helps them get back on track. In UX speak, gracious software is discoverable, invites exploration, provides affordances, and is forgiving.

Meeting the users’ level of knowledge about your domain, looking outside your domain for design ideas, and ensuring your software is gracious to your users will go a long way towards helping your teams design intuitive solutions. Pairing those steps with effective user research and testing is key to delivering intuitive solutions.

Further reading:

Intuitive Design: Eight Steps to an Intuitive UI by Everett McKay

Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability by Steve Krug