Design of digital products. Purpose, role, method
I happened to create from scratch a design unit in Alfa-Bank and work as a design director. It took five years. As a result, we have got a design system (in code) and an approach to the diain of digital products. Actually, I will tell about this approach here. More precisely, this is the text of the lecture, which I read in early 2018 in Moscow, Perm, Novosibirsk and St. Petersburg. In May, I decided to leave the bank, now I have the hands to publish the text of the lecture.
At Alfa-Lab, we built product development processes on the basis of skrom, where each team is an independent unit capable of making deliveries as quickly as they can (ideally - a week or two-week sprints).
An important caveat: the whole text tells about the designer's work in the team. This is a very important reservation, which must be kept 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 hurt. Therefore, if you are new to the concept of "scram", study the approach - maybe someone will help it better organize the work at home. In the course of the text, I poured references to articles and books.
At the end of 201? the Laboratory had about 30 teams (maybe more), and almost everyone needed their own designer. Even on such a relatively large scale, it is more important to work at the level of strategy, upper-level concepts and approaches, because 30 designers who work on different products and in different teams and at different speeds technically qualitatively do not "control" the work. Tactics are determined by each team independently, this is all the charm.
1 [/sup] : instead of developing, we create emulators that give from the strength of 10-30% of the experience that will be in the product. And designing. And research. And mock-ups. And wyraframes DO layouts (some distinguish this stage from design and put different meanings in the same terms). Then a description of the guides. And more "author's supervision" (very vulgar name of spying on the work of developers and grumbling - there is then revealed a billion unaccounted for in all these "studies" and "prototypes" of nuances). So, instead of striving for the result in the form of a product, designers or managers create a lot of high-cost fuss. Some professions such as "designer", "interface designer", "UX /UI-designer", "researcher" and so on are growing. At conferences, the legitimacy of gluing together UX and UI seriously starts to discuss, they say, different people should be engaged in this, different tools and tasks. Instead of focusing on a working product, focus is on the processes, and each add-on only detaches from the real goal.
We must understand that here we are talking only about the processes most closely related to the work of people, whom we call designers (whatever someone in this collective notion has invested). On the established processes within a long-established company, called "business processes", and which often most strongly affect the product and user experience, there is no question here.
Anyway, back to the formulation.
A working product is one that can be used and solved tasks. It's about technical ability to solve the problem using the product.
The product is a certain finished entity, one-piece, in the sum of ingredients possessing greater value than all taken separately.
They use it - it speaks about the relevance and convenience.
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 use it (at least as intended).
Or it is not a product: a set of disparate components that are not related to each other by any sign (this also happens).
Or the product is, but they do not use it (at all). Also a failure, maybe anyone's: lack of marketing, uncomfortable, slows down.
If people are not used then, I admit, there will be completely different design principles.
This idea is discussed from different sides and when talking about Agile, and about frequent supplies, and about Scrum and about work in teams, but even with such practices, designers sometimes for some reason roll down into the cozy track of "processes". I admit such reasons:
do not understand the technologies and their influence on them,
they can not influence the result (fear "will not listen", lack of motivation, fictitious subordination "I was not told to do so")
do not understand their role
Scrum is operated without understanding the purpose, like the framework (see also " Cargo Cult ") - then it is definitely not better than the waterfall (or even worse)
arrange small water-bottles inside the scram :-) - "First design, then the front-end," instead of working as a minimum together /pair. This, for some reason, is especially difficult for designers and developers alike (but when and if so, they no longer want to return to the mini-water-way model because it is detrimental in every sense).
P.S. References to the description of the listed methodologies, Wikipedia:
Agile (Agile) - Flexible development methodology
Scrum (Scrum) - a framework for flexible software development (team work)
Kanban (Kanban) - the system of production and supply organization, which allows to implement the principle "just in time"
2. The role of the designer in the team
Often the role of the designer in the product team is exaggerated, because they think by categories of processes and sequence of actions (waterfall) instead of the result.
(It's right to think from the result, the categories of the goal.)
The developer, simply by making everything according to standards and specifications, will most likely solve the problem better than if it is done by the designer's layout. Probably even grocery metrics will be better. In the absence of a designer.
"We are waiting for mock-ups" - if this sounds, then the processes in the team are organized incorrectly.
(Alas, many developers and designers do not know about the standards - at least W3C for the web, and there are a lot of fundamental principles that help build the best experience .Accordingly, there are descriptions /standards for leading mobile and desktop platforms; iOS , Material )
Pay attention to startups - Facebook, Vkontakte, Classmates and the same Apple with Microsoft: they are based on engineering solutions (Wozniak, Gates), which were later joined by designers. They created products in accordance with the Purpose.
First - a working product.
(Handsome, for the sake of justice, did the ideological guys in the Xerox lab, but the scale of the consequences is quite different.)
What is the role of the designer then?
add value of
You can add to an existing
Value in the eyes of customers, users.
Often the sequence is turned upside down and "waiting for a design". This, of course, speaks of the immaturity of the team and the inadequate management of this team.
"Layouts" is an anachronism, an inheritance of a static web that used to follow the aesthetics and processes of preparing journal and newspaper graphics. In product design, this has ceased to be relevant, but the approach - for lack of another - has remained, both in processes and in consciousness.
Start with the code instead of the layouts.
Application - dynamics, movement, interaction. Therefore, the breadboard models in the work of the product designer are often inappropriate and contradict the goal.
That's why advanced designers migrate to prototypes with real data. Is it good? I think this is redundant - why program a prototype, when can (and logically) immediately program the product?
It is better to move immediately from design to design. Start with the code - the prototype, which performs the task of the client in a minimal form. A prototype that can go into a working supply (remember later about Customer Development).
(The openness and maturity of developers is important here - their willingness to experiment and improve the program, maybe even rewriting the code anew several times. I'm sure there are many ready-made solutions for this for a long time.)
Lyrical digression: an example from the physical world [/b]
Comparison with a paper, physical thing is very attractive, because so far it is clear more than others. So I'll give in to temptation and bring an analogy from the life of a graphic designer.
Imagine that a working product is the content of the publication (books, magazine, newspaper). It is important to properly pack it and present it to the reader. Without content, there is no sense in the design. An empty book does not satisfy the reader. The developer's role compares the role of the author. And without a good design, the content of the book still has value.
And the content can be further distributed as you like. By the way, now the content is distributed between a mass of carriers - from paper to electronic. The same books in electronic form live in different formats and readings, confirming the priority of the content over the design.
(By the way, about design systems: these are style solutions for fast content design.) The development tool, not the design.)
Realize the task of the user.
Start with the development. Work together with the developer (like art director and copywriter).
Perfect the working product instead of the layouts.
Think of the categories of goal, result instead of processes.
The product designer creates a product, not mock-ups.
This method, together with the component library, became the base bank design system .
I propose to work in this sequence:
Understand the client's (user's) task and fix it in the User Story view.
Determine the metrics. How do we understand that the user's task is solved? Commit.
Formulate hypotheses. Commit.
Customer Journey Map.
Working prototype. MVP. Customer Development.
The client's task is
It seems that everything is clear here, but often it is not. With the client's tasks, interface hypotheses are confused, they are given out by managers' wives and generally used for not the most beautiful manipulations of the team.
The client's task is identified either on the basis of complaints ("client's pain") or research needs.
(In passing, we note that the complaint and the task are different things, and it is important to keep the cold head and not rush to "solve the 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 you can formulate an objective problem.)
When the task is realized, it is written in the form of User Story. About this written a lot of articles and books, so I will not repeat here - learn by yourself.
For immersion in a question I strongly recommend the book User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton and Peter Economy) .
Two types of metrics (it is important to fix both!)
The formulated answer to the question "How do we understand that the user's task is solved".
What do we want to get in the form of a solution.
Digital: relative and absolute values. More often about the quantitative indicators (financial, speed, customers, time). As we understand that the decision is successful.
There is a trick here: often in presentations for relative values, they hide, exaggerate or lose the objective scale of the solution. For example, "audience growth was 3%" - is it a lot or a little? If this is ??? people (an urban-type settlement, with schools and gardens, shops and its administration) - then it's an impressive number, although it seems that little things. On the other hand, the "profit growth of 300%", if it is 300 rubles per month - is already a dubious indicator. Again, if 15?000 people - a statistical error in the size of the audience of the entire product (say, visiting the search engine home page per year), then these dimensions are likely to be neglected, although it is about the population of the same urban-type settlement.
It often turns out that metrics come up after the product or feature is already done. For reporting and a beautiful presentation. It's sad and does not show skill, but on the contrary, it spoils the picture and creates a false sense of calmness (the reckoning always comes). Very well, the situation is illustrated by an anecdote about the best archer in the world.
An anecdote about the archer [/b]
The best archer in the world
Once upon a time there was the best archer in the world. Suppose the case was in Japan - for the sharpness of the plot. He could hit the target best from the longest distance, and even as Robin Hood get into his own arrow. The archer traveled the country and surprised with his skills of others, shared his experience.
In one village, he discovered many targets, and they were in the most unexpected and difficult places. The archer realized that there lives a Master, whose skill level he can never reach.
The archer realized that his mission was fulfilled and there is no sense to continue living. He was preparing to make a ritual suicide - sepukku - when the peasant passed by him.
"What's wrong, Archer?" - the peasant was surprised.
- I found that in your settlement there is a Great Master who greatly exceeds me in ability, therefore my mission is fulfilled and I can leave this world.
- You're probably talking about struck targets in the most bizarre places? The peasant suddenly guessed.
"Oh, yes, you're right," the Archer said with regret.
"O Archer!" Know: these are the tricks of the local fool. He shoots arrows at random, and traces the targets later. We all regret it. You're wrong.
Hypothesis is the answer to the question of the fastest way to solve the user problem
There are always several solutions to the problem. In the design (design), you can not be limited to one! Nobody knows in advance which will work best.
Do the 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 solution, not three (or how many have you managed to make different layouts).
For simplicity, try three approaches:
Interface solution. There may also be several.
Automatic (for example, the server performs a task on the occurrence of an event) - without user intervention.
Processes - what can be changed in the processes so that the user with the task does not encounter at all, but gets the solution at the right time.
The best solution is
empirically (see "The Scientific Method"). Any even the wildest at first sight decision /idea should be checked. Hypotheses need to be checked. The ideal case is the verification of all three hypotheses performed in the form of MVP. To do this, you will make a prototype.
Customer Journey Map immerses in context
If you have a small product with a single function, then Custom Stories "Jeff Patton.
Working prototype. MVP. Customer Development.
Agree with the developer and make a working prototype to test each hypothesis. This will not necessarily be an ideal solution in the technical and aesthetic sense - it is important to make a minimally viable product ( Eric Rees's book "Business from scratch. Lean Startup method for quick testing of ideas and choice of business model » . There is no point in retelling a book.
If you are not familiar with the term MVP, start with an article on Wikipedia . However, the book is much more useful.
We can do without layouts, because there is a ready-made product
During the development of MVP and testing of prototypes, you will probably refine a lot of trivialities in each delivery and after each session of feedback from users. The maximum that will have to be done is to align the screens of the finished solution in style and to test it again. A fresh look at the product can prompt new solutions, simplify something even more and rethink, make the result even more convenient and nice to the user - this is where the added value appears.
How to determine the success of
Prototype, MVP, Customer Development
The biggest thing you can do is
Recently, more and more often it is necessary to repeat that the product /company is as good as its worst part can work out. I repeated the lectures and told the new employees.
It is necessary to explain.
For example, designers have made a super-cool concept that solves all the tasks of the user. Beautiful, with adequate animations, taking into account all borderline cases. Super heroes. But the product was rolled out to the customer with huge differences in the details: even if the back guys made a cool, but someone at the front made compromises, then the flawed product reached the client. And the evaluation by the user and third-party observers goes by what product is put into battle, and not by how cool the concept was made and what beautiful pictures the designer made.
Well, or with the sites theme: even if there is a team of talented developers, but in the team a shitty designer, their talented potential will not be revealed. Also remains potential. An unrealized opportunity, because the customer will reach the maximum that they were able to give out in the form of a product.
Or when the backing is so frankly poorly made that designers are solely engaged in creating crutches. They spend time on coming up with literally bad interfaces (for a salary), because they are not thinking how to improve the user experience, but how to adjust it to the processes. This is not a fantasy, it's a reality (when you are told about the limitations in the system's capabilities, this is nonsense, not "limitations", suggest that such delinquents explain this nonsense to customers from the street - you will get more entertainment).
Analogy from the physical world: if a bad car is installed on a racing car, then it will not go cool. Will go exactly as much as they can pull those wheels. Even if everything else is super-cool: a powerful engine, solid carbon everywhere and everything - on the rim quickly you will not go. Although the engineer was probably super-cool, once the car created. It's the same with banks, applications, studios, publishers, agencies and so on. The more tolerance for mediocrity and mistakes (this is called "compromise"), the worse the product /company will be. The product /company is as good as the worst employee or process is: the store can have phenomenally cool /rare goods, but if the seller is rude, then sales will be limp.
I think the idea has long been understood.
It turns out that many people do not understand this.
Why write about this?
Then, so that beginner /continuing specialists do not have a sense of their own individual coolness (false), and that they are not guided by how and what cool models they can ship, but on what result they can give to the user. It is important in the work just that and as a result receive customers. Of course, if it's important to make a product, not images to ship.
The principle is applied everywhere, not only to products.
Looking at the layout: How to solve the task of half the interface elements?
Remove half the text? To formulate twice as short?
How to solve the problem in half the allotted time?
Conduct a meeting in 30 minutes instead of an hour? Generally cancel it?
Remove the graphics? Do not do it at all, initially?
Do I need icons?
What happens if you remove half the items in the navigation?
Reception - to fix the goal and cut off any excess that does not fit the problem being solved. There can be only one goal per time unit.
If there are additional ideas, you can put them in the backlog. Backlog can not be a mandatory set - life is richer than plans, you need to respond flexibly to reality: take and analyze feedback, track product metrics. Much of the contrived will be useless already at the testing stage.
Delhi on two.
In a broader sense, I recommend that you familiarize yourself with the principle " Occam's Razor ", If you do not already know what it is.
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 product design.
Quote from Wikipedia, so that you do not get up [/b] twice.
" Scientific method - a system of categories, values, regulatory principles, methods of justification, samples, etc., which guide the scientific community in their activities.
The method includes methods of investigating phenomena, systematizing, correcting new and previously acquired knowledge. Inferences and conclusions are made with the help of rules and principles of reasoning on the basis of empirical (observable and measurable) data about the object. The basis for obtaining data are observations and experiments. To explain the observed facts, hypotheses are put forward and theories are constructed, on the basis of which the model of the object under study is constructed in turn.
An important aspect of the scientific method, its integral part for any science, is the requirement of objectivity, which excludes subjective interpretation of the results. Any statements should not be accepted on faith, even if they come from authoritative scientists. To ensure independent verification, documentation of observations is made, accessibility to all scientists of all initial data, techniques and research results is ensured. This allows not only to obtain additional confirmation by reproducing the experiments, but also to critically assess the degree of adequacy (validity) of the experiments and results with respect to the theory being tested. "
In my interpretation, the idea of the principle is simple: only reconnaissance is fair.
Have you come up with a solution? Roll out to customers. Insist on a different background? To battle.
All applications must be verified and confirmed by an exin a rudimentary way. In a civilized environment, they are called hypotheses, in amateur groups - "opinion" :-)
The experimental conditions should be transparent and, if necessary, be reproduced by other people.
There are a lot of tools and methods for testing. All results can be digitized: funnels, speed, sums of subjective estimates and so on.
At the same time, all reasoning, visions and so on are just a shaking of the air, no more. Only monitoring the behavior of users in real conditions will answer the questions (and not their opinions and stories).
Moreover: only on a battle all real pluses and minuses of decisions are revealed, unaccounted situations are found out and real feedback from clients is collected. At the same time at different stages of product development, this feedback will have different consequences: from changing critical indicators on a mature product to a complete reversal /change in the concept on a young product.
Proceeding from this principle, I come to such considerations:
Any team member can put forward a hypothesis and test it, regardless of the formal role: designer, product-designer, developer of anything (front /back /middle and what else happens). Everyone can contribute to the achievement of the result. Teams should think through a transparent and simple mechanism for recording and ordering the launch of such ideas (if there are many of them).
The designer does not have an indulgence, the right to be right simply because he is a designer. In some teams, I observe this bias, and in both directions: developers and products manipulate the fact that they "wait until the designer makes a design" (they refuse to think for themselves), while designers often use the fact that they have a " designer ", and for some, the title of the post is an argument in disputes. A product is a set of efforts of all specialists.
It happens that the most wild and illogical at first glance solutions work best. We surround ourselves with prejudices and can not get out of them, look on the other side - it's really very difficult. There will always be resistance to change - both within the team /organization and by clients. The only honest solution is to act decisively, to be able to take risks, test the fight, collect feedback, observe the results and react to them. In another way, nothing interesting appears. It is noticed and proven that everything unusual the day before yesterday becomes the norm today and the routine tomorrow - see " Window of Everton ".
Test the fight - go to at least a part of the audience and check all the hypotheses.
All digitize - the results should be transparent.
The "wildest" hypotheses must also be able to verify.
Everything that is supported only by "expert opinion" and "experience" (in specific interface /product solutions) is boldly sent to the garbage dump - it is necessary to focus only on monitoring the behavior of real users.
And another bonus
I made a thematic collection - mostly about design, and since I left the bank, there was also an inevitable reflection on the design theme in the corporation. A look at work without rose-colored glasses
Look at the contents of the collection [/b]
Designer 202? based on a lecture in Sochi.
Thoughts on the development of the designer's profession in the next five years. The lecture was prepared for students and schoolchildren, and for Russia, so it touches on demographic issues, a retrospective (like it was 20 and 10 years ago) and fantasies on the medium-term perspective.
Design of digital products - the promised text of the lecture from three parts:
The purpose of the designer of digital products is
The role of the designer in the product team
The method is how to work on the product. This method was described for designers in Alfa, to convey to the recruits the essence of work and expectations.
It is necessary to understand that speech there goes for the most part about the work in the skram-teams, and this is historically my favorite format of cooperation.
Three principles: how often I am guided in the work on the product:
• Scientific method
• In half
• The biggest thing you can do is
Instructions or "Secret secret of successful success in success" - why you do not work with what works for others and how we have learned to deceive ourselves.
The trap of the corporation is
Surprisingly for me, a resonating post; even unfamiliar people wrote and discussed, they even asked me to translate into English to give my colleagues in other countries.
Recruitment as a product or "Vanya, find us designers!" -
detailed description of the product development case from the ground up, inside the corporation. I love this story, it inspired many acquaintances and former colleagues, and even she was told (already without me) by the Alpha aychars on a couple of mitapes and conferences.
The post I seasoned with links to all the artifacts of the process - our posts, the publication of Molinos, an article in Kommersant and so on. I myself was interested in comparing the way I thought a year ago with what I wrote a year after the project was launched. This phenomenon is described in one of the scientific publications of Umberto Eco, but here I looked at how it works by example. Interestingly.
My first product is
the story of how we and my classmate made a real product, from which the company turned out. History as much from 199? but very revealing, tells how my principles and approaches that I apply in my work and about which I sometimes write here are formed.
And about sport
I believe that outside the professional themes, the themes of physical culture are forgotten and left in vain. Who remembers me even if only three years ago - will understand what I mean: vanity and work brought me to exhaustion and it looked terrible. I hope this text will help someone else to think hard about their health in advance, without waiting for the sad results that I had.
It may be interesting
I am overwhelmed by your post with such a nice topic. Usually I visit your blogs and get updated through the information you include but today’s blog would be the most appreciable. Well done!
Took me time to understand all of the comments, but I seriously enjoyed the write-up. It proved being really helpful to me and Im positive to all of the commenters right here! Its constantly nice when you can not only be informed, but also entertained! I am certain you had enjoyable writing this write-up.