Lean UX - trivia for successful projects

Author: Anastasia Rezhepp, head of DataArt design studio.

In this article I will talk a little about the methodology of Lean UX-design and give a few techniques and exercises that show how to apply it.
')
Often we have the following problem: a client comes to us with a startup: he has some general idea, but he cannot say anything concrete, since he doesn’t know exactly what features he would like to add to the product, and which ones to remove. Our goal is to help him figure it out. And the Lean UX-design method can help us in this.

What does “lean” mean?

The word “lean” is translated into Russian as “lean”, “thin”, “lean”. If we translate this term in a more special way, then - “thrifty”, “economical”, “minimalist”. For example, there is already the term “lean production” - translation of English “lean production”. Lean manufacturing implies the permanent elimination of all types of losses - this is achieved, including a maximum customer focus. The same is true for the approach of a lean (lean) UX design.

Principles of Lean UX Design

When we follow the lean UX design method, there are a few things to look out for:

• We understand the target audience and its problems.
• We create MVP (Minimum Viable Product - minimum viable product).
• We work in short iterations.
• We constantly test innovations on users and, if something is wrong, quickly roll back.
• We work as a team: UX-designers, designers, developers and testers work together and constantly exchange views and tasks.

How to work with MVP

How do you work with a minimally viable product, with MVP? We take a skinny, but viable product (i.e., with the necessary functions that may interest someone) and gradually build on it meat, muscle, fat - new functions and properties. As a result, the product is growing more and more and more and more successful in the market (at least we are counting on it). This happens because we immediately focus on the end user and grow in the right direction.

If we work on a lean basis with a minimum viable product, we must:

• Formulate a product vision.
• Formulate a business problem.
• Formulate user roles, understand their tasks and goals.
• Build a prototype product.
• Test it.
• Start all over again.

Now so many already work.

Why do you need a "space pen"

To immediately move in the right direction, it is important to consider one important point. Often, having insufficiently thought out the problem itself, we very quickly skip right into the solution space and act there. This happens not only when developing applications, but also in life.

I will give an illustrative example from the field of urban legends - the example of the “space pen”. It is said that in 1965, NASA gave an order for the development of a pen, which astronauts could write under zero gravity. For the development of the handle took the company Fisher. As a result, the “space pen” was developed for a whole year (it can still be bought in stores, by the way), and considerable resources were spent on its development. "Space Pen" can really be used in space. At the same time, Soviet scientists proposed their own solution to this problem - a simple pencil. Such is the Russian "space pen", which is not even necessary to develop.

This is a city legend (based, however, on the facts - just a little distorted), but this is not important for us now. It is important that with the example of this story we can clearly see how some were in the area of ​​problem solving (this is NASA), and others (Soviet scientists) were in the area of ​​the problem itself. After all, the problem was not to develop a pen that writes in space, but that astronauts need a tool to document their observations. And the solution to this problem can be very simple - you just need to first consider the problem itself, and not immediately rush to solve it.

Not “how”, but “what”

In order not to jump directly into the solution space, you need to start from the right questions. It is important not to start immediately thinking about how we will do something: it’s worth thinking about what we are doing and why . Therefore, the correct sequence of questions is: why? -> what? -> how?

For example, it happens that a client comes in and says: “Few people download my application - probably, you need to make another landing page (landing) ... So I looked, people have beautiful landing pages, with animation and photos - do something similar.” And we don’t have time to look back, as we already have five designers drawing animations, looking for pictures, etc. But the problem may not be in the landing page at all - maybe you need to add something to the application so that it becomes a success. .

Find the admirer: Kano's model

And here I turn to the next exercise: how do we decide what to add and what not to add to our application - so that its development goes in the right direction. I called this exercise “Find the admirer”.

This exercise is based on the so-called Kano model - it was developed by the Japanese Noriaki Kano about 50 years ago. According to Kano's theory, any product has all its qualities and functions divided into 3 categories:

• Must-haves (basic, basic qualities).
• Performance benefits .
• Delighters (attractive qualities, or admirers ).

• The basic qualities are what should be necessary. Without them, the product will not exist on the market - without these qualities, it is simply not needed by anyone.
• Expected qualities are those that the user would like to see. They can and should be improved. After all, if you increase and improve them, the user satisfaction smoothly grows.
• Delimiters , or attractive qualities — that the user does not expect to see at all, but, if he receives them, he is very happy.

Now we illustrate the application of the Kano method using the example of a piggy bank:

• One of her basic qualities is that she must have a slot into which we throw money. If it does not exist, then even if we paint the pig in bright colors, decorate it with rhinestones, nobody will buy it anyway - at least no one will be interested in it as a piggy bank.
• Expected qualities : what can we do with this piggy bank to make it better? We can change its size: for example, if it is larger, more money will fit in it. We can change the size of the hole in which we drop money - to make it as convenient as possible. People will like it, and therefore they will buy such a piggy bank.
• Admirer : for example, when we drop money in a pig, it will grunt, and this will bring people incredible delight.

The Kano model, by the way, is very convenient to use for analyzing competitors. If we do the usual analysis, we usually select several similar applications and compare their functions:



The function that occurs most often is probably the most important and popular. But, if we divide all the functions into three categories, it will be even better.

Let's give an example. We have introduced production gymnastics since the summer in design studios. To do this, we installed mobile sports applications that help to warm up for 10 - 15 minutes. And I compared these applications using the Kano model:

• The main qualities of such applications were: video descriptions of exercises, the ability to combine them and make your own set, the presence of a timer. For example, without a timer, such an application is rather pointless - it is very inconvenient to use.
• Expected quality - the number of videos and interestingness of the proposed exercises.
• Delights : in the Lazy Monster application, for example, all the exercises are shown by an animated monstrik - and this makes us very happy. Nothing more interesting - this application is not - but, apparently, it is popular due to this monster. In the third application, “achivki” are an attractive quality - the ability to download additional exercises for free.

By the way, in the field of mobile applications admirers are often in the field of design and user interface - this is what often helps the application to "take off."

"Magic wand"

And then the question arises - how to come up with admirers? It is not always easy. To invent admirers, I prepared the exercise "Magic Wand".

We just sit down and start brainstorming - we present our product in a world where there are no restrictions. We do not hold back our imagination and generally do not think about developers or technical limitations - we just invent everything that comes to mind. Subsequently from all these fantasies we, with high probability, will be able to pull out any rational grain - any functions that can and should be realized.

For example, I again took physical education applications and thought what I could want from them. Physical application could:

• speak in the voice of Brad Pitt;
• suggest doing 10 sit-ups while I make coffee;
• Substitute music from your favorite movies;
• give the load in accordance with the pulse and well-being;
• etc.

In general, I would like the application to work with me more intellectually. From these fantasies, we can really draw out something real: for example, the application can be linked to the Kinopoisk website, so that it knows which films we are watching. If there are good investors, you can even negotiate with Brad Pitt to record the voice acting.

Smoke "testing" on the landing page

So, let's say we invented a set of cool functions. Now we can do a smoke test on the landing page. This is not real testing, because we are not seriously developing anything yet. For now we are:

• draw a landing page for our product;
• we list the functions we have invented;
• check conversion.

For this we need, besides the ideas, some sketches of the future application, which we will post on the landing page, and perhaps some kind of prototype of it that looks like a real one, which we will continue to develop if the idea succeeds. The main thing is for the user to understand what is being offered to him! And to check the conversion, for example, we can put on the page "subscribe to the news" or do several options for plans and subscriptions and see how many people came to the page and subscribed to the news about the project or requested a demo version. Then, if the conversion is high, we continue to develop the application, and if it is low, we turn off the idea.

For example, this is the approach we will soon use for our financial projects: we will launch a landing page that describes the concepts of financial applications for young people. Each application will have a “request a demo” button, and we will see how many people will want to see this demo.

But there is another important point: it is worth doing all this only if we have worked before with the users and the client. In other words, you don’t have to invent everything completely from your head - there must be some real basis, some general knowledge, in which direction the application should be developed.

So which topics have we covered?

We talked like:

• Exit solution space.
• Learn to ask first “what”, not “how”.
• Do the classification of functions.
• Work as a magic wand.
• Test what is not.

Thanks for the clever thoughts of Dan Olsen and leanproductplaybook.com, Kim Goodwin and Designing for the Digital Age.