Defining what ‘easy’ really means to your users
Product people love the word easy, but it’s vague and not helpful. To achieve easy, we must become more nuanced. Here is how and why.
The overuse of the term ‘easy’ stems from overarching usability illiteracy in the product development industry. In other words, our colleagues are unable to articulate themselves enough to describe how they want to make the product better.
This article zooms into the usability category of a UX framework. See my other articles on how to build a UX framework and how to build a storytelling strategy.
Why is easy important?
In flow theory, a person will, like water, take the path of least resistance to complete the task at hand. In the Jobs to be done theory, people hire products to get their jobs done. They constantly analyse the range of solution alternatives available to them and choose the most suitable. If they find your solution too difficult, they will ‘fire’ your product and ‘hire’ your competitors.
If you want to reduce churn and increase new customers, make your product the easiest to use of all your customers’ alternatives.
The problem for product development organisations is in trying to understand in what exact ways their product can be made easier to use. Because they don’t have the vocabulary to express themselves in a nuanced way, they instead strive continuously towards a utopic vision of ‘easy’ by way of spray and pray.
What does easy mean for your users?
The term easy can mean different things to different users who are trying to get different things done. This is why you should talk to your unique users, who are trying to get their unique jobs done, in your unique product.
Ask your users what it is that they truly value in a product like yours? Where do they experience friction?
It is not enough for us to assume that your users are just like us. After all, we sit in the top 1% of technological competence. We are nothing like the other 99% of our users. For example, you might learn that your users have difficulty with the language used, that it just doesn’t make sense to them. At my last company, like with most growth-focused SAAS companies, management placed a high prioritisation in getting activations up. In other words, getting the people who signed up to actually start using the product. They formed a specific cross-functional team with the goal of increasing activations, which they conveniently named the activations team. This team then went and worked on the onboarding flow and put a large CTA button in with the text ‘Get activated.’ The term ‘activation,’ a business term, had become so prevalent internally, that people became blind to it. Of course, when the user came along to this page they had no idea what ‘Get activated’ meant or why they should click on it.
Easy = Ability
BJ Fogg’s Behavioural Change Model gives us an insight into what factors influence someone’s behaviours. He breaks it down into what motivates them vs their ability to actually do the behaviour. Depending on where they sit in this matrix, we can prompt them in different ways to do the desired behaviour. E.g. signing up for your product etc. This model is interesting for many different reasons, and I recommend you check it out, but for the purposes of this article, we will focus on ability.
Ability is how able a user is to get their job done. Hence why ability is interchangeable with ease. Our goal is to lower the threshold of the task’s difficulty to meet the user’s ability. So why are they unable to get the job done now? And what specifically do they get caught up on?
Fogg breaks ability down into the following:
- Time
- Money
- Physical effort
- Mental effort
- Routine
If we can understand how these factors affect our users then we are one step closer to coming up with targeted design interventions.
Tailoring your unique easiness attributes
You should write your own easiness attributes, from your user’s perspective. You can be as flexible as you like but keep in mind also that these need to be usable by your designers and other members of the product development organisation. I also recommend looking into Heuristic Analysis if you want a more generic lense.
An example:
Intuitive
Make it clear for me to understand what is happening and how I can get my work done at first glance.
Time-saving
Shorten the time it takes me to get my work done.
Collaborative
Help me get work done with others in my team.
Routine
Use the language and mental models that I am used to.
Holistic
Take into account my greater sales ecosystem and associated barriers of use.
Motivation
Show me the value of why I should do something.
Measuring current state
In order to make your product easier to use, you need to have the systems in place to understand how easy/hard it is to use today.
Given the metrics outlined above, we can set up a continuous measurement system that we record in a matrix. For example:
You can and should start with your own intuitive guess of where your product sits on this scale. However, you should follow this up with real customer research. As this is highly subjective, I recommend conducting moderated interviews where you can pivot and deep dive on certain insights.
The scale
This is a simple scale to help understand and prioritise between different areas of ability. I also use this in my JTBD mapping which I will write more about in another post.
First we ask a question:
On a scale of 1–5, how do you rate your experience of our product in the following areas…
Then we get them to answer:
0 — Can’t get done at all
1 — Difficult
2 — Somewhat difficult
3 — OK
4 — Easy
5 — Easier than expected
Defining your future state vision
Of course, you want your product to be a 5 in all areas, right? I would argue that depending on the area of your product, you will have different thresholds regarding what is acceptable to achieve business value. It might be very important to have your dashboard super easy, but your deep settings pages might not be as important.
The important thing here is to have an active and collaborative dialogue continuously around where the biggest gaps are and what you think is realistically possible to achieve both in the short and long term. Rome wasn’t built in a day, but every day something was being built; what is that something going to be today?
Summary
Product organisations need a wakeup call when it comes to UX. We all need to take more initiative to understanding the intricacies of what a user’s experience actually is, and with that we will come one step closer to making our products truly lovable.
