I happened to create from scratch a design department in Alfa-Bank and work as a design director. It took five years. As a result, we have a design system (in code) and an approach to the design of digital products. Actually, I will tell about this approach here. More precisely, it is the text of the lecture, which I read in early 2018 in Moscow, Perm, Novosibirsk and St. Petersburg. In May, I made a decision to leave the bank; now I’ve got my hands on publishing the text of the lecture.

At Alpha Lab, we built product development processes just over the screen, where each team is an independent unit, capable of making deliveries as quickly as they can (ideally, weekly or two-week sprints).

Important note: the whole text talks about the work of the designer in the Scrum Team. This is a very important caveat to keep in mind. In lectures, I mentioned this in passing as a matter of course, so someone could lose the meaning of the story. For kanban and traditional approaches (contract-design-layout-assembly-act), this method is likely to even harm. Therefore, if the concept of “scrum” is new to you, study the approach - maybe this will help someone to better organize their work. In the course of the text, I poured links to articles and books.
')
At the end of 2017, there were about 30 teams in the Laboratory (maybe more), and almost every one needed its own designer. Even on such a relatively large scale, it is more important to work at the level of strategy, top-level concepts and approaches, because to “control” the work of 30 designers who work on different products and in different teams and at different speeds will not work technically qualitatively. Tactics is determined by each team on their own, that's the beauty.

1. Purpose: A working product that people use

Such a simple goal. Let us analyze each word, because it is not just so formulated by these words.

Pay attention to the lack of word-processes, such as "creation", "design" and so on. Processes are not a goal at all. The goal can only be the result, not the process. But designers from all over the world fall into the mental trap of processes, so the results of their work are process artifacts, not working products.

I have a sad statistic. Of the ten designers who come to “make a product and influence it”, one focuses on the result, the rest - on processes. Reaches a long time, and well, if it comes at all.

Before indignation will flow, I will clarify: I don’t belittle the importance of processes and understand them. Framework, research, design, methodology, specifications, guidelines, design systems, professional software and so on. As soon as the product falls into the user's hands, it all loses its meaning: the product is either working or not.

Anyway, back to the wording.

1. A working product is one that can be used, solved problems. It's about the technical ability to solve the problem using the product.
2. A product is a kind of complete essence, whole, in the sum of ingredients and having a greater value than all of them taken separately.
3. Enjoy - speaks of demand and convenience.
4. People are a broader concept than “customers”, “users”, “employees”, etc. Working for people, we take into account ergonomics and some standards.

Suppose the product does not work. Everything is clear: they will not be used (at least according to their intended purpose).

Or it is not a product: a set of separate components that are not related to each other on any basis (this also happens).

Or there is a product, but it is not used (at all). It’s also a failure, maybe someone’s wish: lack of marketing, inconvenient, slows down.

If not people use ... then, I admit, there will be completely different design principles.

This idea is discussed from various sides when they talk about Agile, and about frequent deliveries, and about Scrum and about working in teams, but even with such practices, for some reason, designers sometimes slip into a cozy rut of “processes”. I admit the following reasons:

• do not understand technologies and their influence on them,
• cannot influence the result (fear “will not listen”, lack of motivation, made-up subordination “I was not told to do that”)
• don't understand their role
• Scrum is exploited without an understanding of the purpose, like a framework (see also “ Cult of Cargo ”) - then it is definitely not better than a waterfall (or worse)
• they arrange small waterfalls inside the scraps :-) - “First, design, then front-end”, instead of working at least together / in pairs. This, for some reason, is particularly difficult for both designers and developers (but when and if it does, then they no longer want to return to the mini-waterball model, because it is flawed in all senses).

PS Links to descriptions of the listed methodologies, Wikipedia:

• Agile (Agile) - Flexible development methodology
• Scrum (Scrum) - flexible software development framework (team work)
• Kanban (Kanban) - a system of organization of production and supply, allowing to implement the principle of "just in time"

2. The role of the designer in the Scrum Team

Often the role of the designer in the product team is exaggerated, because they think in terms of the processes and the sequence of actions (waterfall) instead of the result.

(To think correctly of the result, in categories of purpose.)

A developer, simply by doing everything according to standards and specifications, will most likely solve the problem better than if he goes through the designer’s layouts. Probably even product metrics will be better. In the absence of a designer.

“We are waiting for mockups” - if this sounds, then the processes in the team are organized incorrectly.

(Alas, many developers and designers are not aware of the standards - at least W3C for the web, and there are a lot of fundamental principles that help build the best experience. By analogy, there are descriptions / standards for leading mobile and desktop platforms; iOS , Material .)

Pay attention to startups - Facebook, Vkontakte, Odnoklassniki and the same Apple with Microsoft: they are based on engineering solutions (Wozniak, Gates), which were later joined by designers. They created products according to the Goal.

First - a working product.

(Beautiful, fairness for the sake of, did the ideological guys in the laboratory Xerox, but the scale of the consequences is quite different.)

•••

What then is the role of the designer?

In adding value .

You can add to something existing , pay attention.

Value in the eyes of customers, users.

•••

Often the sequence is turned upside down and "waiting for the design." This, of course, speaks of the immaturity of the team and the inadequate management of this very team.

•••

“Layouts” is an anachronism, a legacy of a static web that previously followed aesthetics and the processes of preparing magazine and newspaper graphics. In product design, this has ceased to be relevant, but the approach - in the absence of another - has remained, both in processes and in consciousness.

Start with code instead of layouts.

Application - dynamics, movement, interaction. Therefore, layouts in the work of a product designer are often inappropriate and contradict the goal.

That is why advanced designers migrate to prototypes with real data. Is it good? I think this is redundant - why program a prototype when it is possible (and logical) to program a product right away?

It is better to move immediately from design to design. It is to start with the prototype code that performs the client’s task in a minimal form. The prototype, which can go into the work delivery (recall later about Customer Development).

(The openness and maturity of developers is important here - their willingness to experiment and improve the program, perhaps even rewriting the code anew several times. I am sure that there are many ready-made solutions for this for a long time.)

Takeaway

Realize the user's task.

Start by developing. Work in tandem with the developer (as an art director and copywriter).

Improve the working product instead of layouts.

Think in terms of goals, results instead of processes.

The product designer creates the product, not the layouts.

3. Method

This method together with the library of components became the basis of the banking design system .

I propose to work in the following sequence:

1. Understand the task of the client (user) and record in the form of User Story.
2. Define metrics. How do we understand that the user's task is solved? To fix.
3. Formulate hypotheses. To fix.
4. Customer Journey Map.
5. Working prototype. MVP. Customer Development.
6. Layouts. (With a well-coordinated work of the team and the existing design system, you can do without layouts).

Customer task

It seems that everything is clear here, but often it is not. The interface hypotheses are confused with the client's tasks, they are given out by the Wishlist managers and generally used for not the most beautiful manipulations of the team.

The client’s task is identified either on the basis of complaints (“the client’s pain”) or needs research.

(We note in passing that a complaint and a task are different things, and it is important to keep a cold head and not rush to “solve a problem” on the basis of a complaint — the task may be different, and the complaint is caused by unrelated circumstances. Comes with experience. Use the five why method sometimes it helps to get to the bottom of the reason on which an objective task can be formulated.)

When the task is realized, it is recorded in the form of User Story. Many articles and books have been written about this, so I will not repeat here - study on your own.

I strongly recommend the book User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton and Peter Economy) for immersion in question.

Two types of metrics (it is important to fix both!)

1. Formulated answer to the question "How do we understand that the user's task is solved." What we want to get in the form of a solution.
2. Digital: relative and absolute values. More often about quantitative indicators (financial, speed, customers, time). How do we understand that the solution is successful. There is a trick: often in presentations, they hide, exaggerate or lose the objective scope of the decision for relative magnitudes. For example, "audience growth was 3%" - is it a lot or a little? If this is 150,000 people (a small town, with schools and kindergartens, shops and its administration), this is already an impressive number, although it seems like little things. On the other hand, “300% profit growth,” if it’s 300 rubles per month, is already a dubious figure. And again, if 150,000 people are a statistical error in the size of the audience for the entire product (say, visiting the main page of a search engine per year), then these dimensions can most likely be neglected, although we are talking about the population of that very urban-type settlement.

It often turns out that the metrics are thought out after the product or feature has already been done. For reporting and beautiful presentation. This is sad and does not show mastery, but, on the contrary, spoils the picture and creates a false sense of calm (retribution always comes). The situation is very well illustrated by a joke about the world's best archer.

Hypothesis - the answer to the question about the fastest way to solve a user's problem.

There are always several solutions to the problem. In the development (design) can not be limited to one! No one knows in advance what works best.

Do mental work and come up with at least three different solutions.

Keep in mind that the “development” of one idea in the form of a progressively changing layout is one decision, not three (or how many different layouts you have done).

For simplicity, try three approaches:

1. Interface solution. They can also be several.
2. Automatic (for example, a task is executed on the server upon the occurrence of an event) - without user intervention.
3. Processes - what can be changed in processes so that the user does not encounter a task at all, but gets a solution at the right moment.

The best solution is found exclusively in an empirical way (see “Scientific Method”). Any even the wildest at first glance decision / idea needs to be checked. Hypotheses need to be checked. The ideal case is testing all three hypotheses, made in the form of MVP. For this you will make a prototype.

Customer Journey Map plunges context

If you have a small product with a single function, then CJM allows you to see the whole process of solving a problem by a user and identify pain points, realize the real completion of the task.

If a task is a study of a feature in an existing application, then CJM immerses itself in context and provides a seamless, seamless solution to the problem. Often, ignoring the context, designers and product managers make a “new section”, replicating entities, complicating navigation and causing confusion in the interface.

Quite a lot has been written about CJM, you need to study it yourself and apply it in your work.

You can start with Jeff Patton's User Stories .

Working prototype. MVP. Customer Development.

Agree with the developer and make a working prototype to test each hypothesis. This is not necessarily a technically and aesthetically perfect solution — it’s important to make a minimally viable product ( MVP ) that you can use to test new and existing customers (Customer Development).

Read more about all this in the book by Eric Rees “Business from scratch. The Lean Startup method for quickly testing ideas and choosing a business model . ” Retelling the book does not make sense.

If you are not familiar with the term MVP, start with an article on Wikipedia . However, the book is much more useful.

We will do without layouts, because there is a finished product

During the development of MVP and prototype testing, you will most likely be refining a lot of small things in each delivery and after each feedback session from users. The maximum that will have to be done is to align the screens of the finished solution in style and re-test. A fresh look at the product can prompt new solutions, simplify something more and rethink, make the result even more convenient and attractive to the user - this is where added value appears.

Takeaway

User story
How we define success
Hypotheses (solutions)
CJM
Prototype, MVP, Customer Development
Layouts ( if required)

For information

The biggest thing you can do

Recently, it is increasingly necessary to repeat that a product / company is only as good as its worst component can work. At lectures he repeated, and I say to new employees.

We'll have to explain.

For example, designers have made a super cool concept that solves all the user's tasks. Beautiful, with adequate animations, taking into account all borderline cases. Super Heroes But the product was rolled out to the client with huge discrepancies in trifles: even if the guys did backing cool, but someone on the front made compromises, the defective product reached the client. And the assessment by the user and bystanders goes by what product is put into battle, not by how cool the concept was made and what beautiful pictures the designer made.

Well, or with the theme of the sites: even if there is a team of talented developers, but in a team of hellish designer, their talented potential will not be revealed. And will remain a potential. Unrealized opportunity, because the maximum that could be given in the form of a product will reach the customer.

Or when backing is so frankly poorly made that designers are engaged exclusively in the creation of crutches. They spend time on inventing literally bad interfaces (for salary), because they are not thinking about how to improve the user experience, but about how to adjust it to the processes. This is not fiction, it is a reality (when you are told about the limitations in the capabilities of the system, this very nonsense turns out, not “restrictions”; offer such limiters to customers to explain this nonsense from the street - you will get some more entertainment).

Analogy from the physical world: if bad wheels are mounted on a race car, then it will not go cool. Will go exactly as far as they can pull those same wheels. Even if everything else is super cool: a powerful engine, solid carbon everywhere and so on - you can't go fast on rims. Although the engineer was most likely super cool, once the car was created. The same with banks, applications, studios, publishing houses, agencies and so on. The greater the tolerance for mediocrity and error (this is called “compromise”), the worse the product / company will be. The product / company is as good as the worst employee or process: the store can have phenomenally cool / rare products, but if the seller is rude, then sales will limp.

I think the idea has long been clear.

It turns out that many do not understand.

Why write about this?

Then, so that novice / continuing professionals do not have a sense of their own individual coolness (false), and to focus not on how and what cool models they can ship, but on what result they can give to the user. What is important in the work is just what and as a result customers receive. Of course, if it is important to make a product, and not to ship pictures.

The principle applies everywhere, not just to products.

In half

Looking at the layout: How to solve the problem with half the interface elements?

Remove half the text? Formulate two times shorter?

How to solve the problem in half the allotted time?

To meet in 30 minutes instead of an hour? Generally cancel it?

Remove graphics? Do not do it at all, initially?

Do I need icons?

What happens if you remove half the items in the navigation?

Acceptance - to fix the goal and cut off all unnecessary that does not fit the problem to be solved. There can be only one goal per time.

If there are additional ideas, you can put them in backlog. Baclog cannot be an obligatory set - life is richer than plans, you need to react flexibly to reality: accept and analyze feedback, track food metrics. Much of the contrived will be useless at the testing stage.

Delhi by two.

In a broader sense, I recommend to get acquainted with the principle of " Occam's Razor ", if you still do not know what it is.

Scientific method

I like simple understandable approaches adopted in the scientific world. For example, evidence-based medicine. And the scientific method in a broader sense. Of course, such convenient things are somehow rethought and adapted for their work. So it turned out one of my principles of grocery design.

In my interpretation, the idea of ​​the principle is simple: only reconnaissance by force is valid.

Have you come up with a solution? Roll out on customers. Insist on a different background? To battle.

All applications must be verified and verified experimentally. In a civilized environment, they are called hypotheses, in amateur groups - “opinion” :-)

Experimental conditions should be transparent and, if necessary, be reproduced by other people.

To check there are a bunch of tools and methods. All results can be digitized: funnels, speed, sums of subjective evaluations, and so on.

At the same time, all reasoning, visions, and so on are just shaking the air, nothing more. Only the observation of the behavior of users in real conditions will give answers to questions (and not their opinions and stories).

Moreover: only in battle, all the real pros and cons of solutions are revealed, unrecorded situations are discovered and real feedback from customers is collected. At the same time, at different stages of product development, this feedback will entail various consequences: from changing critical indicators on a mature product to a complete reversal / concept change on a young product.

Based on this principle, I come to these considerations:

1. Any team member can hypothesize and test it, regardless of the formal role: designer, product-gunner, developer of anything (front / back / middle and what else happens). . ( ).
2. , , — . , : , «, » ( ), , «», . — .
3. , . , — . — /, . — , , , , . - . , — . « ».

1. — .
2. — .
3. «» .
4. , « » «» ( / ) — .

— , , . .

ePub