Don’t let your UX blinders fool you

What users don’t know they want lies in their beautiful dissatisfaction

Insight is the key component of creativity. And if creativity is the process of coming up with new ideas, insight is the most important step in that process. A crucial part in the initiation phase of a project, each new insight has the potential to transform our work. But, if we rely on the user-centred approach of standard UX methodology, we can only go so far. And for us, that’s not far enough.

This argument is even more compelling for us at Hello because we are using the agile process. Now an industry standard for building digital products and experiences, agile helps prototype fast, and get products to market fast. And unlike the waterfall method, you can fix mistakes before it’s too late, or too costly.

The agile UX process requires a great deal of prioritisation, co-creation with the client, testing, and iterations. It takes a tightly knit team who have the discipline to complete the sprints from one time box to the next.

But before you even get to the initiation phase, you need to ensure that this agile baby of yours comes into the world under the best possible conditions, and with a strong sense of purpose.

Why are you building what you’re building?

And that’s where there’s something inherently problematic with the project initiation capabilities of the UX methodology. Before we hit the gas pedal of agile prototyping, we need to understand the purpose of what we’re building. And that purpose must provide a very strong foundation for what we’re building, and why we’re building it.

To find the purpose means putting the user-centred approach to rest during the initiation phase, because user research will probably only tell you what you already know, and verify your stereotypes about your users. But if we expand our reach to a wider spectrum of interpreters, we can uncover new insights, and new perspectives.

From building features, to building a meaningful experience

When you leave the comfort zone of existing users, and expand your reach to a wider spectrum of interpreters, you step out of the past (and present). You see beyond packaged solutions, or incremental development, and enable brand new perspectives and insights to surface.

And if we look at our projects in the wider context of culture, technology, and persistent human tensions, something very important happens: we don’t just see features, but see meaning in what we do.

This is the moment of perfect initiation.

Purpose is what matters, the rest is a technicality

A meaningful purpose not only attracts new users, it brings new meaning to existing users. But most importantly, it can solve human problems that have not yet been verbalised.

When we designed WeShare together with Mobile Pay, we didn’t see it as an expense sharing app. We looked at how money can create a silent friction among friends, especially when a group of people must share expenses when they share an experience. Our purpose was to solve the age-old money conflict that is a threat to any kind of relationship.

If we could remove this friction of having to ask for money, and create a platform where friends can chat and share their excitement about their plans, WeShare would elegantly solve a silent problem. And it could become an appealing tool for planning and building up the anticipation of experiences that are shared with others.

The Stacks bot kindly reminds everyone to pay their share

The ERP system we built for Mikro Yazilim in Turkey for small business owners, spring boarded from a very human purpose; ‘to help small business owners succeed, so that they don’t have to go back to the job market again’.

Due to bad liquidity management, bankruptcy takes down half of the new starts up each year in Turkey. When you focus on the real goal — the desire to be a successful small business owner — and make that the purpose of the product, great ideas crystallise in front of you; like helping them to get paid faster, warning them about upcoming cash bottlenecks, and helping them to plan for it.

We took the purpose and translated it into ideas to help small business owners — get paid faster, alerts about impending cash bottlenecks, and help to plan for them

But how do you uncover what’s not easily seen, and then find the insights that will help you see what you’re building with fresh eyes?

Think like Sherlock

In Maria Konnikova’s brilliant book, ‘Mastermind, How to think like Sherlock Holmes’, she reveals how Holmes’ mental strategies can help sharpen our perception, solve different problems, and enhance our creative powers.

The most keen-eyed fictional detective, Holmes uses ever-present mindfulness, reflects imaginatively, sees beyond the obvious, and connects seemingly disconnected pieces to solve crimes. Holmes sees connections where Watson (his sidekick) focuses on the obvious clues. Watson’s ability to focus helps Holmes, but Watson’s lack of insight falls short of solving the actual crime.

So, if user-focused UX thinking is the hyper-focused Watson, we want to be the insightful, perceptive Sherlock.

And as with Sherlocks’ deductive process, when you’ve gathered insights and found your purpose, you need to test them. It’s now time to wake UX from its slumber, and focus once more on users in an agile way. Testing the purpose and the insights, and their implications for the product that we’re building, is essential for success.

Keeping track of your purpose

By maintaining a constant focus on why you’re building, it’s so much easier to evaluate design, functionality, and interface decisions along the way, as everything can be tracked back to your purpose.

To adapt to this way of working obviously requires a methodology and new tools, but most importantly, it requires a major mind shift:

1. Avoid relying on what you think you know, as that might lead to hasty conclusions.

2. Challenge basic clichés and stereotypes from the outset.

3. Screen out pre-packaged, obvious solutions, and functional rigidity. (If If Gestalt psychology recognised this as a psychological phenomena, we could rest assured that even the best of us suffer from it)

4. Challenge the brief with scepticism and an inquisitive mind-set, but be humble.

5. Accept this as a fact: User testing is retrospective. If you want your work to leapfrog, choose your interpreters wisely.

6. Look for outliers who live on the edges of your user base. Collect insights from people that you’ve never talked to before.

7. Search for omnipresent tensions that your product can solve.

8. Think of the minimum viable experience rather than the minimum viable product.

9. Embrace failure as part of the journey. Without failure, there’s no eureka moment.

10. Continually ask your team what is the real purpose of this product? What valuable meaning do we want it to embody?

11. Never leave the shores of common sense.

Making your work leapfrog

At Hello, we’re not interested in building products that resemble and perform like lookalikes in the market, which perhaps are incrementally better, but are almost always a result of the retrospective knowledge gleaned from user research.

The customers who will use any product or service we build are always inherently, beautifully discontent. They want and need something better, even if they don’t know how to verbalise it. This wonderful human discontent is our driving force, and helps us imagine things future users would love to have.

We want to empower and delight users beyond the retrospective limitations of past experiences. We want to apply Sherlock’s powers of thought and observation to make our work truly leapfrog. It’s only by focusing on purpose, rather than technology or interface, that design companies can remain relevant.

And at a time when technology is accelerating faster than at any other time in human history, it’s comforting to know that products based on human realities could become omnipresent.

When you add creative energy into the sprints, and focus on what people will get out of what you’re building, it will breed the creative adrenalin that we’re all looking for — and thrive on.