Bertus Kock

Copyright Politicsmeanspolitics.com

Understanding to Solve

Surgeons can cut everything except cause ~ Herbert M. Sheldon

Put your hand up if this sounds familiar. You share a problem with your boyfriend/husband and the first thing he wants to do is solve it (functional), when the only thing you wanted was to be heard (emotional). To be fair, and thinking about stereotypical gender roles¹, men are often raised and/or wired to do just that; fix and solve problems². It therefore doesn’t come as a surprise that Tech, which remains a very much “male” dominated industry³, has a mindset of “building to solve” instead of “understanding to solve”. Thank goodness the world is changing.

It is very rare that a company doesn’t already have a “solution” in mind when they approach a problem. Sure, they don’t have all the functional parts or UI worked out yet, but where would you see a company’s “About Us” section saying: “Well we started this company. We had no idea what we were going to build or solve, but we did it anyway.” It is part of the business perspective to identify a “problem worth solving”, followed by agile-research, and build-and-test. Everything happens from the perspective of the “solution”. This is “building to solve”.

In contrast to “building to solve”, “understanding to solve” takes a different perspective on product development and user experience by exploring the thinking and emotions behind a need⁴. 

  • Why do people have certain goals? 
  • What do they hope to achieve when reaching these goals? 
  • What challenges do they have? How do they think about their problems? 

At first, you might think: “but this is too much information”, “how long will this take?”, but you aren’t collecting “everything”. You or your company are bound to have an interest in a certain field or context, and you will be exploring that context for richer understanding.

From a business perspective, you will get a much clearer understanding of how much your product actually resonates with users; not just on a functional level, but also match them on a social and emotional level. When you take an “understanding to solve” perspective, your user research will continuously build richer insights and not just be an archive of “What we have done, but never looked at again”. If you plan to build bespoke experiences, this is the way.

Notes

  1. Gender Roles and Young People
  2. “While many studies suggest that women are more empathetic than men, Dr. Brizendine stresses this is not entirely true. The empathy system of the male brain does respond when someone is stressed or expressing a problem. But the “fix-it” region quickly takes over”
  3. Navigating male dominated teams
  4. “Needs” are frequently applied as problems framed from a user’s perspective, instead of delving deeper into the user’s mental models
Photo by Andrea Piacquadio from Pexels

Cost of Simplicity

You probably have a friend, we all do, or it might even be yourself who installed an app, tried to use it but just couldn’t “get” it. It required a lot of effort to find the value. It just wasn’t simple.

If you want to become a rocket scientist, there is a certain amount of knowledge you will need to acquire in order to understand the field. This takes time and effort. The same goes with an app you are trying to use, although hopefully less tricky than rocket science. You also need to gain an understanding of the data and information being communicated to you. When a company wants to create a particular experience (their intention) for you, it is “communicated” through the apps’s use of UI, colours, text, symbols and information architecture.

Cost of Understanding

In “Figure it out“, the authors Stephen P. Anderson and Karl Fast talk about how information needs to be understood in relation to people and their needs (“…designer Richard Saul Wurman in the late 1980’s… information that failed to inform was merely data…”) and this process of making something understandable has a cost. This cost could be time and effort or learning new skills and developing better skills on the side of the sender or receiver. This cost of effort, from an UX perspective, should ideally be on the sender’s side.Cost of Simplicity

This “cost of understanding” I found very useful as an analogy when it comes to simplicity, as “understanding” very much relates to “simplicity”. The simpler something is for the user (receiver), the easier it is to understand. But, if understanding has a cost, where does it go if you need to make it easier for a user?

The “cost of understanding” is the total cost of the “knowledge” transfer moving from one person or app to another person. What you have to figure out is, who is “paying” for it. Simplicity is the science and sometimes art of shifting the balance of that effort towards the communicator, business or app.

Shifting the Cost of Simplicity

If you don’t make the effort to “simplify” it, the cost of the understanding sits with the user. They have to make the effort in understanding what you are trying to communicate. If you put in the additional effort of creating for example: automating tasks, providing predictable options, auto-completing forms you already have information on, you take some of that cost away from the user. If your business takes on the cost of simplicity, you will not only have taken on the challenge of building for humans, but also give your product to test its viability as soon as possible. There is nothing worse than having to give up on a good valuable idea, because people didn’t “get” it.   

And that is what simplicity is in UX; going the extra mile, so that users don’t have to.

Photo by Ketut Subiyanto from Pexels

Going from persona to person

Over the past year or two, I have found myself wondering about a better life with personas. Are personas giving us enough or can we do more? Real people’s needs, attitudes and behaviours shift or change over time and sure, there will always be new people that fit a persona, but should we be okay with letting people go? That might be okay for an entertainment app, but it probably is not okay if you want to provide long term customer value. 

Read More
Image copyright by Atlassian

The End of Feature Requests

Have you ever been on the end of a long string of feature requests, either from users or management? These feature requests are usually very specific in how you are supposed to implement it. So much so that you, as a UX Designer or Product Owner, you sometimes feel like a tool. Well, there is a very simple way to change that. All it is going to take is for you to ask one simple question, and that question is: “What are you trying to achieve?”

“What makes this question so special?”, you may ask. Let me explain. This question does three things.

Read More
By RyAwesome / Ryan Clare from Vancouver, Canada. [CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

eCommerce Registration and the Path of Least Resistance

The best interface, is no interface.” These were the pearls of wisdom offered by Alan Cooper back in 2012. Fast-forward six years, and here we are with ecommerce: forced registrations, whimsical delivery times, late/cancelled deliveries, basket analogies, wishlists, broken mobile-web journeys & impersonal recommendations.

If “Customer is King” and we follow User-Centered Design (or any of the other variants of UX), why is it that businesses, marketing and even sometimes UX put obstacles in the way of users reaching their goals?

Read More

“Be the change you want to see in the world” ~ Not Gandhi

Deep Diving into “Why?”

After “What are you trying to achieve?“, my second-favourite and most used question, is “Why?”

Anyone who has ever engaged the inquisitive mind of a four-year old has had the experience of answering the dreaded follow-up question of ‘but why?’. While this line of questioning has lead to many frustrated adults, this line of thinking has inspired the problem-solving approach employed by some of the top companies and leaders in the world.

Read More