Lean UX: Solving problems instead of producing paperwork

23. February 2016 Agnieszka M. Walorska (@agaw)

Not too long ago, I was in charge of the User Experience Design for one of the most inefficient Re-launch-Projects imaginable. Since then I am dedicated to find an answer to this question: “What causes inefficiencies within User Experience Design processes and what can you actually do to prevent them?

Here, you will find my talk at the iico conference 2014:

Problems of the common approach in a Waterfall model

What does the common approach towards User Experience in a launch and re-launch process look like nowadays? Most companies tend to implement substantial changes to their online presence at least every few years. Usually this happens on a large-scale (new product from scratch) and is still being undertaken in some form of a Waterfall-Model.

The most brutal example of such process that I have ever experienced took place in a huge corporate structure. Start-ups actually have the chance to do it right – as they usually don’t have a huge organizational overhead. But still – a whole lot of them don’t. And the consequences for start-up are in this case far worse than for the “grown-up” companies – as startups generally have less money to waste.

I have also experienced this project set up in start-ups, which leads the User Experience Team to focus on producing deliverables. They create scribbles, wireframes, sitemaps, flow diagrams, mockups and above all: specifications. Of course you might ask, “What’s the problem with this?

But let me ask you this first: Of all those files and documents, what will the end user ever see? What user is ever going to download the wireframes of an e-commerce shop and say “Wow. Amazing wireframes! Starting today, I am only going to buy my jeans here, as they have produced such incredibly perfect wireframes.”

Let’s be honest: what happens to all those specifications after launch? They end up in the trash. If not literally, they end up buried in some project archive folder, which will most likely never be accessed again until the end of time.

Of course you could argue, that “Even though no end user will ever see this, without those specifications we cannot create an accurate cost estimation for the development and without the exact cost estimation we won’t be able to realize the project.”

This is only partly correct, as it only applies if your approach follows the waterfall-method and you have a very inflexible internal development team or service provider. A re-launch based on the waterfall-model looks more or less like this: definition of the requirements -> UX -> visual design (if you are lucky, UX and visual design might combine into one stage) -> development -> testing -> launch.

If you have a deep look into the UX/Design-stage, you’ll see something like this: First of all, the requirements have to be determined and validated. Afterwards they get passed on to the UX-team, which is assigned to analyze and validate them. Next step is then the definition of initial sitemaps and user-flows by the UX-team. Those of course have to be reviewed by the decision-makers. If approved, the production of the wireframes may begin, which often already have to contain all the possible states and screens of the future product.

The wireframes then are presented to the stakeholders during several meetings, are revised again and again, and eventually are forwarded in to the hands of the visual designers. These guys design every single screen of the application and then after some more back and forth, meetings and Iterations, the visuals get accepted (Once, my team has seriously been asked to adjust the wireframes to the visual design, after the actual visual design has been delivered and approved – luckily this has only happened to me once so far).

Then the specification is generated, which contains written information about every single pixel and interaction within the application. This leads to the production of hundreds or even thousands of pages of text documents. It’s not too uncommon, that only after or during this final process, the user tests are being run. Which means, that for the first time, after all the time and expenses, the potential user is being involved into the process.

The problem with that – the results of those tests are often unlikely to be taken into consideration, as there is not enough time and budget for further changes.

In a big organization a process like this is likely to take several months. In startups with flat hierarchies it takes a little less (but is still counted in months rather than days!). Add the time for the development and you have invested so much time in the launch or re-launch of your product, that you’re probably facing a completely different market situation and user needs compared to the circumstances during the start of the process. Just like that “the greatest thing since sliced bread” ends up as a complete bust.

And what are the consequences? The agency and/or the responsible product or project manager gets fired, a new briefing is being developed, a new team is hired and the whole process starts all over again.

Digital products are never finished

So why does this continue to happen? Seth Godin hit the nail right on the head by saying:
Great projects start out feeling like buildings. There are architects, materials, staff, rigid timelines, permits, engineers and a structure. But in fact, great projects are gardens. They are tended, they shift and they grow. They endure over time, gaining a personality and reflecting their environment.

That’s why you’re not done with a “launch” or a “re-launch” – and you cannot and shouldn’t expect your team or service provider to deliver a “ready product”. When I’m being asked about when a product would be “ready” or “finished”, the only honest answer I actually should give is something between “what do you mean by finished” “no idea” and “never”. But most customers, big surprise, don’t really seam to be happy with such an answer.

Flexibility and interdisciplinary teams are required

So what could be a suitable solution?

First of all, the implementation of some certain fundamentals is necessary. The organization needs to be able and willing to become a garden. The characteristics of digital products hardly go hand in hand with rigid hierarchically structured organizations (corporates) or organizations with very centralized decision-making structures (startups).

They require quick adjustments and close cooperation within an interdisciplinary team. This implies that the people who work with the product on a daily basis, need to be able to make quick decisions and can’t be asked to wait for the management level approval regarding even minor adjustments.

And this problem doesn’t only apply to big organizations. It’s the same with start-ups. The founders often expect to be involved in every minor product-related decision (which, of course, is somehow understandable). But unfortunately, they cannot make these decisions fast enough, as they are also involved in all minor issues in all other areas: sales, marketing, HR, PR, finance etc.

Or even worse (recent example) – there are three founders, trying to all be equally involved in the UX process, and failing to achieve unanimity regarding even minor design-related decisions.

If even minor decisions require so much effort, it becomes really difficult to achieve fast progress. Whilst management is often too busy with other things others find themselves exposed to long downtimes waiting for the green light.

Still, it could be worse. Sometimes there is no green light and the improvement proposals are rejected. The reason for this is quite simple: The decision makers are not engaged deeply enough in the creation process and can hardly understand the implications.

Define leeways in decision-making

This means, in order to make the process more efficient, it would be very helpful to grant the responsible interdisciplinary team a considerable amount of space, where they can play around and make decisions and adjustments by themself. This would help the organization to embrace a flexible and quick ability to react when facing challenges.

How much independency is needed? It depends on the organization, the project state and the desired outcome. Many regulations lead to more predictable results (which might or might not be desirable). Allowing a bigger leeway creates opportunities for innovation and more unexpected outcomes.

Start with the problems

Once we have this setup, the process may start. But where to begin? The core of every strategy has to be a precise answer to the question of: “Which problems do we want to address?” This diagnosis is fundamental to proceeding further.

Ironically enough: people who are not affiliated or involved with the organization in any way are generally the most capable when it comes to making this diagnosis. “Why?” you might ask? It’s because of their ingenuousness, they are not limited or biased by internal policies, hierarchies or routines in their way of thinking and approaching a problem. That’s why start-ups, coming from outside are often able to disrupt an industry. But after a while they also become insiders and often loose their naivety.

Regarding this phenomenon I can highly recommend to checkout the Website “50 Problems in 50 Days” by Peter Smart. Peter set himself the challenge to solve 50 problems, with 24 hours for each problem. These problems range from fighting homelessness in Turin to budget management. The most important part of his approach: deciding not to know anything and to ask “dumb questions”, which turn out to be “excellent questions”. This approach is exactly what I would recommend to anyone who is involved with UX, internally or externally – doesn’t matter. You see: The most important question a UX Designer should never get tired of asking is the question kids are never tired of asking – “Why?”

Understanding your customer

And I want to emphasize something: it’s about IDENTIFYING the problems and user needs and not about accepting the problems that your boss (or the client if you’re a service provider) THINKS are relevant.

This requires having a good understanding of the end customer of the product. You have to ask yourself, who will actually really use your product and what are their problems or needs. Frequently I hear things like “we want to address everybody with our product”. Sorry, I have to disappoint you. There is no “everybody”. If you try to address everybody, it’s highly probable that you’ll design the product to suit your own taste. The technique to get a better understanding of what your actual customer might look like is: creating Personas.

Creating Personas

So, what is a Persona exactly? This is Daniel. He’s 43, divorced and has two kids. When he has some free time he’s doing sports or spending time with his kids. It’s very important to him as they’re living with their mother. The time he has with his children shouldn’t be distracted by unnecessary actions. If he want’s to book a trip for himself and his kids – it should be as easy as possible. Preferably he’ll do this on his iPad while watching his kids playing on the playground.

But Daniel doesn’t exist – or at least I don’t know anything about his existence. We have created him to understand the product from the perspective of a potential customer. This also prevents finding yourself in the thinking process of what you’d personally like or dislike. From now on you will see through the eyes of Daniel and ask yourself: “Can I solve Daniels problems with that? Would he use it to reach his goals?

Measurable solution instead of featuritis

Which problem do I want to solve for which audience?” Having this question in mind at all times helps us to prevent “featuritis” or “feature creep”. Featuritis means for me a compulsion to ad more and more functionalities. This one would be quite cool to have, this one is totally innovative, and this one we need because the competitor has it too. By doing this you end up with a product, which has a shitload of functionalities of which the customer is going to only use one or two.

So, instead of making conclusions and decisions regarding your design and functionalities based on your own opinions, emotions and desires – I would recommend you to ask questions which are able to be easily testified by real-world customer and user behavior.

You can do this by asking questions like:

  • Will there be fewer abandoned shopping baskets if we add more payment methods?
  • Does one big form lead to more registrations than a form split into several steps?
  • Do product videos increase the Conversion Rate?
  • Can we accelerate the form fill-out process if we put the labels on the left instead of the top?

These are some typical examples of questions, which are also easily quantifiable. And remember: The more specific your question, the easier it will be to isolate and measure it afterwards. You can easily validate these questions with A/B-testing, user-tests, surveys and polls, web-analytics evaluation or a combination of all of the above.

It needs to be stated that the measurability and the connection to your business goals are the key elements here. For example a question like “will the users find our website more beautiful, if we make it all yellow?” will not really make it.

Define hypotheses you can put to a test

Ideally all of our functions are described in the form of a hypothesis:

We assume that we can solve a specific problem or address a specific need of a specific persona with a specific functionality. We know it is true if we were able to observe a specific market reaction.

Or to make it a little bit less abstract, let’s say:

We assume that we’ll meet Daniels need for a secure and quick online payment by the adding of PayPal as a payment method. We know that this is true if the the cancel rate during the checkout process decreases by 5 percent.

Prioritize actions

If we did our homework right, then this is the point where we have a long list of selected functionalities, which are phrased in the form of hypotheses. The next challenge: We will not be able to implement all those features at the same time. Why?
a) it would take a huge amount of time and
b) we’ll not be able to correctly assign the causes to the results.

That is why the following step is usually the most difficult one: we need to prioritize our functionalities and need to be able to focus on the most important topics. And trust me, this is not easy. Good ol’ Steve phrased this nicely:

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. Innovation is saying no to 1,000 things.”

So, how the hell can you identify the most promising features? Your goal should be, to achieve the biggest impact you can, by putting in the smallest effort possible.
For example: Instead of completely renewing the whole checkout-process, which can be a huge effort and a pain in the ass, we should consider if simply optimizing the Call-To-Action-button might already have a positive impact. It is better to quickly identify some low-hanging fruits, focus on them and improve and measure them, instead of tackling a large number of tasks at once, without even having the resources (financial or human) to do this properly.

Fail fast and fail forward

Why do I constantly emphasize the importance of being quick? Isn’t the quality more crucial than speed? I can answer this question with a little anecdote from the book “Art and Fear”: The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, would be graded solely on the quantity of work they produced. All those on the right solely on its quality. On the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pounds of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality” however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, it came to grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity.

How is this possible? It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes — the “quality” group had sat theorizing and arguing about perfection, and in the end had little more to show for their efforts than grand theories and a pile of dead clay.

Digital products behave in the same way. If you focus all your energy on trying finished, perfect product, you will waste a lot of your precious time. Time you need to produce testable prototypes and products, which you can test, improve and learn from. I know, I know. It is always hard to expose a non-perfect product to the market, but I really really recommend doing exactly this.

The Reaction of the target group is the only quantity that counts

Because: how shall we know, that we just invented the perfect product without getting feedback from the market? If we are going into the wrong direction with our product, it is always good to get an early wake-up call. Otherwise we are just wasting a huge amount of money and time in the development and get nothing out of it. It is a fact, that nearly no digital product, which has had mentionable success, went live in form of a finished product. They all grew to be successful based on market feedback and were fed with several iterations.

Conclusion: Recipe for successful and efficient User Experience

So if there is something like a recipe for an lean and efficient UX process – it would contain these few points:

  1. Ask “Why?” Over and over again.
  2. Iterate
  3. Make smart decisions based on market feedback instead of discussions in meeting rooms.
  4. Focus on being fast instead of being perfect.
  5. Fail early, to become successful faster.

Related posts