We’ve all seen it at some time.
I’ve even given it a retweet in the past, believing it to be a cute and simple way of explaining what I do for a living.
But seeing it again and again on social feeds, I began to question it:
Is this supposed to be a comparison between “UX” and more traditional “Design”?
Is it to show the way users interact with products against our perception?
Is it suggesting users only take the “UX” path and the “Design” path is completely wrong?
Is it showing user research, a single step in the process?
Regardless, once you get into it, it’s either wrong, confusing or both.
I wanted to break the image down and rebuild it, showing a true representation of an iterative design process.
Note. If you’re in the industry, this will hardly be ground breaking for you, but it’s a bit of fun. Maybe you have your own opinions on the image that you care to share? 🙂
For the purpose of this article, our product already exists.
Company Z wanted a product that allows users to walk from A to B, keeping users away from nearby traffic and providing users with a dirt free, even surface to walk on.
They built this path. It’s a nice path.
But company Z soon get feedback from their maintenance team that the upkeep of the grass is taking longer than expected as grass is wearing thin along certain areas.
In the light of recent feedback from the maintenance team, company Z decide to conduct some user research.
By observing the path over several days company Z see some users veering off the path to get from A to B in a slightly less timely manner.
Speaking with users of the path, company Z soon learn that this is a busy commuter route and that time, especially in the mornings and the evenings, is of the utmost importance.
Company Z form the following hypothesis:
By building a diagonal path, we can make the user journey more efficient and keep users off the grass. This will reduce both time and money restoring these areas.
Minimum viable product
To test their hypothesis company Z decide to add a temporary extension to the path.
This is a quick and inexpensive way to see if their hypothesis is correct before spending more money implementing it.
If the hypothesis is wrong, reverting the path back to it’s original state will be quick and easy.
With their minimum viable product in place, company Z carry out several days testing, observing users natural behaviours with the new modified product.
Whilst testing their minimum viable product company Z make the following observations:
- The majority of users will take the prototype pathway if it means a shorter journey for them.
- All users will take the original pathway when it is the shortest journey for them.
Following on from their observations, Company Z conclude:
- The minimum viable product was a success, and their hypothesis was correct.
- There is nothing fundamentally flawed with their original design, they just needed a new feature.
- An added bonus being that the gravel path can be used as the foundation for their new product, a truly valuable MVP.
So it came to be that company Z released a new feature to their product.
By observing users in a natural environment they have managed to decrease their own maintenance costs over a longer period of time whilst improving the users experience with their product.
My new analogy
Here is my updated version of the analogy.
I feel this offers a little more insight into User Experience than the previous version (albeit a little less snappy).
The problem with the original image is that User Experience is much more than what it depicts. User Experience is not a single thing, it’s not a single job, it’s a continuous, holistic process.
The original image has no outcome, nobody has identified a problem or intervened to make the product better for users, so it can’t be labelled as User Experience.
Maybe my new image can do the rounds on social media :-), or maybe a fellow User Experience professional can offer another solution. Feel free to comment.
The key takeaway from this is:
If users find a more efficient way to use your designs, they will, regardless of how you meant for them to use it.
Speak to users and observe interactions with your product. Identify their problems and solve them.