Get best of the week

The designer is not the one who paints beautifully, this is the one who helps the business understand the user

image

In the last post I told in numbers that good design pays off, that metrics can and should be implemented in the design and development process, feedback needs to be collected more often and the designer should not be considered the person who draws the pictures.

Practice shows that if you need to discuss something substantively in IT (and in other areas too), then we are talking about classic design approaches with User Flow and CJM. That is, very many development processes are accelerated by building the process from the end user to the product, and not vice versa.

Over the years of building such processes, we at McKinsey started using a framework based on the design thinking, Zero-based design and Service design paradigms. Now we recommend using it when rebuilding the company towards human-centric.

The first postulate is to forget about the existing developments and evaluate once again what exactly the user needs and how he solves his tasks at the current moment. It is often given most painfully, because it is often easier to develop an existing product, and not think about the prospect for one or two years.


The difference in revenue and return on investment for the top quartile of companies with well-established design processes on average in consumer goods, medicine and retail banking. As you can see, in medicine, design is unexpectedly critical.

The main implementation steps for the steps of the framework


We analyze the situation "as is", we understand the needs of customers, business and so on.

The client team needs to have an idea of ​​the target client path, i.e., how the product will look in the long term, as well as the prototype MVP (minimum viable product), in other words, the piece of the client path that the team will release in the first place. What we do to come to this:

  • We prepare and conduct research; as a rule, these are in-depth interviews in which the product owner and key team members meet with their users face-to-face, learn about their problems and needs.
  • We understand how the existing processes and services work, for example, we meet with employees of a bank’s branch and find out how the loan to customers actually looks, what works and what doesn’t.
  • , , , .
  • , , .
  • ; , , , , , . — .
  • , , . , , : , , .

At each stage, we transfer to the client the skills of the right approach to creating the product. Our task is to set the motion vector, show the tools, and then make sure that the team does everything on its own: so that interviews with users are carried out by participants, client path maps are collected by the product owner, prototypes and tests are done by the designer.

For example, we went through such a process in one bank, which decided to introduce brokerage accounts for individuals. Now this feature is in almost every major mobile application, when you can do in a few clicks what was previously done in two or three trips to the department and filling out a bunch of forms.

The simplest process that a bank would do according to a traditional framework is to transfer a regular physical operation online. Nevertheless, the postulates of our study say that it is not so important how the operation is performed in another place, if you can simplify it for the user in this channel or on this medium. This is a direct consequence of the zero-based approach: nothing is inherited. As Torsten Dirks (Telefonica CEO) said: “When you digitize a shitty process, you have a shitty digital process . ” The process must be disassembled to zero, rethought and reassembled in a simplified form. Designers call it from the position of the client.

The first thing we collect is a list of requirements, restrictions and needs of clients according to how they see the process in an ideal world.

Next, we come up with a target vision of how we want to see a product or service in the future. That is, we cross restrictions, standards, technical capabilities and so on with what the ideal process looks like. In the case of a brokerage account, for example, processes like “need a passport - and we have it since the moment of opening an account”, “we need three consents - let's collect them all in one tick”, “you need to get such and such data - you can offer enter them manually or take them from social networks ”and so on.

Then we take the goal and build a sequence of actions that lead to it. It’s like about a problem with a teapot, when “we turn off the stove and the solution comes down to solving the previous problem”: we should not try to use the existing achievements, but decide how we will go to the goal and whether something can be used. Reuse is secondary compared to the importance of solving a problem.

At this stage, specific tasks are already written. Only we do not prepare TK for six months, but do the branches “hypothesis - experiment”, that is, we assume that something will go wrong. And think over the reaction to it.

The first step is always MVP.

The basic postulate says that the sooner prototypes appear, the more chances there are to make a product quickly for the client, and not for himself. Therefore, we are constantly working with a prototype of varying degrees of development - from Wireframe in the first step to release at the product release step (we continue to support the release).

Example


We help establish the processes in the bank, I do business design (this is when designers help make business decisions). More precisely, I help the business to make more informed decisions (due to more information about the needs of users, tools for analyzing the current situation and designing the target situation, tools for communication, and so on).

The new structure of the company has autonomous product teams. In fact, before they didn’t exist at all: the business wrote down the requirements for the product, let them go to the designers, the designers drew the design and handed it over to the developers, and they developed the product and released it.

Now there are autonomous teams where there is design, and development, and an understanding of IT architecture and business. After several iterations of questions: “Why are we doing just that?” - it turns out that the software, developers and other team members have completely different ideas about what customers need. By “different views” I mean factual data, not intuitive. Intuitively, everyone has their own opinion about the best: for software it is often the speed of release of the product, for the developer - clean code, for the designer - likes in the portfolio.

Typical picture: the product is 10 years old, “we already know everything.” We conduct interviews with clients, and there, in general, everything is different.

Our task is to show that money lies where customer needs are satisfied. And the better we understand the customer, the higher the likelihood of a company earning more. Therefore, it is necessary to gradually reorient to the constant receipt of feedback and a scientific approach to development. In our banking case, conduct in-depth interviews, synthesize insights and test different solutions. Having understood the needs of the client, we help the team look into the future - estimate the long-term vision of the product, or, as we call it, build the target client path.

Then we help to rise in a vision from three to four months to one or two years. This is very important, because the picture at least in the perspective of the year makes it possible to make strategic decisions. If you constantly live in the context of three to four months, then you can only quickly respond to changes, but never be the first. And if you anticipate the situation and start selling and promoting now what will become important by the time the information reaches the client, then you can become a leader.

Before the rebuilding of processes, it worked like this: the owner of the product understood that something in the surrounding world had changed, and it would be necessary to change the product in this direction. It took three months to go from the requester to the design layout, because the designer was sitting somewhere in the distant design department, and he already had a turn of tasks from technical tasks from strangers from all over the bank.

Own product teams have reduced the prototyping time for new solutions to two business days. That is, we helped create a model of a small working autonomous business around the product.

Quickly obtained prototypes began to be used as the basis for meetings. Previously, business made decisions on a speculative level, but now, looking at CJM and ready-made screens, it has become possible to understand what exactly is supposed to be done.

Discussion has become easier. Decisions began to be made substantive: “Here, let's give three tariffs, not two”, “There is a lot of text here, but what we want is unclear”, “Here, too much consent is being collected, it is not necessary.” Right from the meeting, you can now call lawyers to find out if this unnecessary consent can be removed. The gap between iterations was reduced at times, because the design was as close as possible to the business both physically and in the sense of organizational structure.

By the standards of large organizations, existing for more than a dozen years, this sounds like science fiction.

Why have design processes become the basis for product decision making? Because there were meetings without a designer, where complex product solutions are discussed in words. This takes many hours, is repeated every few days, and the team cannot eventually agree.

The designer comes, draws a prototype at the meeting, the discussion becomes more substantive, the team quickly negotiates and moves on. That is, it was in this situation that rapid prototyping by visual means (at least by hand on paper) helped to agree more quickly.

The product owner at the bank is used to working in the Waterfall structure when the designer sits in a separate team to which the application for creating layouts is sent. It takes several months to complete, and the result can only be changed at the level of “let's change the image on the banner”, and not at the level of “let's think about the logic of the screens and the number of fields to fill.” The designer appeared on the team, iterative work began, translating the needs of customers into the product owner and the team as a whole. The designer highlights and reasonably explains the problem areas of the current version of the design, the software and the team more quickly look for solutions to improve it.

Result: simplified formulations, the bank speaks the client’s language, a shorter and more understandable client path, fewer fields to fill in, clear tariffs.

Basic principles


The designer is not the one who paints beautifully, it is the one who helps the business understand the client (user) , look at the end-to-end product being created, create a single (shared) collective vision of the product using design tools (cards, prototypes) . That is, a designer is a designer who can visualize the process of creating a product. A full-fledged team member, user advocate and facilitator of all ongoing discussions.

The designer tells:
— , « ». . , , 2. . , . , . User Story Map. , CJM. ? . ? . ? ? , , , , . — . 20 — , .

So the first aid to design is to accelerate product discussions. And then there’s already a change of thinking to “the user needs”, and not “here we have it.”

We solve the problem, starting from an understanding of the needs of the user.

Design is judged by customer satisfaction and conversions. In most cases, it is about the effectiveness of solving the problem. The faster and with less effort the user solves his tasks with the help of the product, the more convenient he considers it. This often means that the "good old" already familiar products are subjectively better, and simpler products with minimal functionality are considered by the user as more flexible in comparison with rich (but unknown to him) functionality.

Therefore, any product is not only created taking into account previously identified insights, but is also constantly monitored.

In our example, the designer in the bank appears in the team and then is responsible in it for regular testing with users at least once a sprint. The team and management see the reaction of customers and understand that the project is moving in the right direction. There are still not quantitative, but already qualitative studies. It is clear what the money goes into designing.

A new approach to work changes the culture of the company, developing human-centeredness and making customer experience a responsibility of everyone.Without a designer, a bank communicates with customers only through marketing agencies, receiving information about research through reports. This information does not give rise to empathy. The designer arranges regular in-depth interviews with clients, teaches software to conduct these interviews, shows highlights (cuts of interesting finds) on a demo. Empathy with the client gradually develops in the bank, in discussions people begin to appeal to what they have heard / seen in the interview, using these observations as an additional texture for making decisions.

We are looking for the right problems to solve or problems that should be solved in the first place (again, through understanding the needs of the user).

It is necessary to decide what most affects satisfaction. Somewhere, this is one skewed pixel against a feature with a two-month implementation, somewhere - on the contrary. And somewhere, like in a joke, it’s useless to move the beds, and you need to change the product.

We come up with solutions in a cross-disciplinary team (design + business + technology).

Splitting into such teams (for development, ideally at least for discussion) is also the basis of the framework. Each of those who influence the project must see what is happening inside in order to immediately speak out about this. The designer usually says: “I would like it like that,” and the rest explain why this is not possible or why this is possible. The dialogue between the designer and the developer sometimes resembles this XKCD comic :



Moreover, this works both ways: something very complicated for a designer can actually turn out to be something very simple, because the technologies have changed a bit over the year.

The closer the designer is to business, the more efficient the process of creating the product and the final result: this is our new design report. The principles are the same at all levels .

We prototype and visualize the invented solutions in order to align the team and start receiving feedback.

This is important both in software development and in device development. If you make a vacuum cleaner, then a prototype made on time can save you from the indignation of users due to an incorrect center of gravity or maintenance issues that arise too late.

The closer the designer is to business, the easier it is for him to transmit knowledge about the needs of the client and accelerate decision-making in relation to these needs. Good practice is in the transparency of the process . The designer at the bank involves the entire team and leaders in the process from the very beginning. All CJM cards and working options are in plain sight (they hang on the walls, are available online, are presented on demo days). Everyone, including leaders, understands which way the product is developing, can give comments and ask questions at any time. When the process is transparent, everyone is calmer.

The better the designer is integrated into the team, the higher the involvement and sense of ownership for the product design of all team members (everyone participates in the design, everyone feels ownership). Here the question arises, “Why can’t it be redder?”, And the designer’s task will not answer him “because I said so,” but justifying it. If it doesn’t work out, it’s already necessary to work out a compromise. From some point, discussions about “redder” disappear altogether, as the focus shifts to solving user problems. Does it work for the user or not? The user does not care, redder or greener. The question is whether it is noticeable or inconspicuous, understandable or incomprehensible, whether there is value or not.

Prototypes (pictures) make communication with lawyers, compliance and security easier and more efficient. Much better than communicating with letters. As a rule, incredible demands come from them that break customer experience very much. When this is simply stated in the letters - it is not obvious to everyone when it is drawn on the prototype - it becomes clear that one cannot live like that. The leader sees this, and the search for a compromise begins.

References


More articles:


All Articles