WIP: Product Design
I want to talk about the cycle of work on the design of the finished product, based on my own experience at beepcar.ru . This is a service that helps one get from point A to point B, the other - save on gasoline, and sometimes - even make money. In short, it drives drivers
and passengers. We have a web version and two applications - for Android and iOS.
The cycle itself is divided into three modules: Before Design, Design and After Design. Below I will talk about each in detail.
Before design
Before embarking on a design, we need to know what we are doing and why . The whole team needs to understand the reasons for the tasks and their goals - the product manager is responsible for this. But in reality, the product manager is full of other tasks, meetings, research and various worries. Because of this, he is not always able to convey the reasons and goals of the tasks. Therefore, we take the initiative and figure out for ourselves where the tasks come from.
Since the project has been launched, we already have an audience - large or still small. These are people who have chosen our product to solve their problems ( JTBD work ). These people we need to be able to hear and understand their needs. Our metrics, with which we evaluate the success of the product, depend on satisfied needs. How to identify needs:
Reviews
They need to be read regularly and by the whole team. There are three easy ways. First, people leave them on the Google Play and App Store. Secondly, you need to foresee the possibility of sending reviews directly from the application or site. Thirdly, you need to look for them in our groups in social networks.
Friends / acquaintances and personal experience
Most likely, the people around us will use our product, do not be shy to ask again if they like everything or not. We put open questions, try to talk to a person. Often during such interviews interesting cases pop up. Well, do not forget to stand up for the people who use our service ourselves.
Experiments on the "living"
In the team, we call “live” the current versions of the product: people are using them right now. In order to conduct experiments, special preparation is required - during the initial development, it is necessary to spend time setting up counters for different events. Thanks to this, we will be able to measure funnels, put forward hypotheses, and then test them. Below is a simple funnel example:
Why, out of 100% of the people who hit the booking screen, click on the "Book" button only 21%? The most obvious conclusion will be: people do not find the button. Then our hypothesis will be this: if you put the button in a more prominent place, you can increase the amount of armor.
UX testing
Mail.Ru, like many large companies, has a UX lab. This is a special department that invites third-party people, shows our products, conducts interviews, records the reaction, and then, based on the results of these studies, prepare a report on the product. Smaller companies, without access to laboratories, can independently conduct UX tests and interviews with friends. And you can do this through online services — for example, through Fabuza .
Competitors
And of course, peeping at our neighbors. We should be interested in both direct competitors and indirect ones. With direct everything is clear, but indirect ones can be completely different companies. For example, our indirect competitor is Russian Post, because in our service people can send packages with drivers. And when one of the competitors releases a feature, you need to study it and decide how much it is needed in our product. Nothing personal, it's just business.
After identifying the needs, they need to be turned into features.
In half the cases, everything will be stupid enough, for example: passengers want to pay with a card - let's make payment online, ingeniously! With the rest of the needs, it’s worth digging deeper. One of the last: people want to leave comments on the trip. Here it was possible not to think, but simply to stick comments on them (spoiler, in the end we did just that). But! First, we went the other way and reasoned on the topic: what exactly do they want to ask? Can you prevent these issues? And why exactly the comments on the trip? Maybe this should be a general chat? Or private messages? Etc. Why complicate your life with these questions? Because it’s right, it’s interesting, and it often brings interesting observations and thoughts.
Next, we have a list of features that we want to do. And at first everything will be fine, it will be small and neat, but then the number of Wishlist will grow like a snowball. Here you need to set priorities, so that in the end we get an even backlog with tasks. In general, you can prioritize tasks based on two things:
“Ahh, burn!” Model - very often we have tasks that need to be solved yesterday. For example, the metric, important for us, slipped after rolling out the latest version. Or competitors have released a very important feature that we do not have yet. They can also pass a new law,
For example, the “Law on an agreement on the processing of personal data”, in order to fulfill it, it also takes time to design and develop. Here you can add marketing activities to the holidays and various events. All these tasks in most cases come first.
Kano model - when the fire is extinguished, we can move on. To do this, take our backlog and run it through the Kano model. This method helps to understand what percentage of people will like the new feature, which one will not care, and which one will be upset at all. In conjunction with the evaluation of the development, this allows us to see the ratio of our labor costs for the feature and the benefits of it. After that, our backlog will take the form of a list with priorities. About the model itself can be found here .
Design
Now we begin to draw. Unlike the first module for which the product manager was responsible, here we are the main role - product designers. Since the responsibility lies entirely with us, we must not disappear. Therefore, we periodically coordinate intermediate decisions with the manager. The design process is divided into three parts:
- We draw
Before the first approach it is useful to meet in a narrow circle of managers / designers and discuss the main points. We start drawing already at this meeting, so at the exit we will have outline mockups and a clearer understanding of what everyone expects. Next, we work through all the ideas, transfer to Sketch and think through everything again in more detail. We must have an answer to every potential question. - We check
To check simple features it is enough to show the design on the device, for more complex ones, clickable prototypes are needed. We demonstrate to our team and other colleagues, remember the reaction, draw conclusions. At this stage, we try to ask more questions, the answers to them will be very useful to us. Why do you think so? How would you do? What is embarrassing? Figured out right away? Etc. - Three questions
What is good? Our solutions will almost always have pluses (we thought well of them, right?), The main thing is to be able to notice and fix them: yeah, everyone liked the cat on the screen, like it.
What is wrong? But there will be minuses, we also notice them and remember: the cat, of course, is cool, but what is loading is generally unclear.
What ideas? On this question, you need to figure out how to save and increase the pros, as well as how to remove the cons: try to add animation, let the cat roll the ball, it will be clear that the application did not hang.
Now we have ideas for further work, so we complete the first cycle and start drawing again. Yes Yes.
As a result, we get a vicious circle, we can get out of it as soon as the result is fully satisfied.
Decision Protection
In fact, this is a huge part of the designer’s work and can be discussed for a very long time. But I will try to convey the main idea.
At the design stage, discussions always arise, and this is normal - it is bad when there is no dispute. But many disputes can be resolved quite simply, the main thing is to "talk" in numbers. Unfortunately, not all even experienced designers can do this.
Any small "taste" is solved by testing Side By Side. This is the younger brother of A / B tests, when a person is shown two static pictures, and he must choose the one that he likes more. I emphasize that serious things cannot be verified in this way. You can test this method for free by regular mailing, for this you only need the base of addresses and time. It is possible and faster, but then for money, there are special services for this: Amazon Turkor Yandex.Toloka . We in the team use Toloka, because there is a Russian-speaking audience for which we are making our product.
We solve large issues with full-fledged A / B tests on the “live” one. I talked about this briefly above - we put forward a hypothesis, measure funnels, and get a figure for conversation.
Well, no one canceled the corridor testing. We pick up a prototype and go to show our colleagues, acquaintances, if upbringing allows you to even go out and pester passers-by. We are asking the same questions to everyone, as a result of such testing we will have statistics of answers, which will become our argument in protecting the design.
I use this approach to work, we will always have a figure by which we can "talk":
- 67% of people answered that this icon is more understandable
- 7 out of 10 people took the right action right away
- 41% of people fell off on this option of delivering results
Design principles
At the same time, an uncontrolled method of working with numbers can turn our product into a vinaigrette. It is worth taking care of the design principles in our team in advance, registering them and approving the whole team. You can even print and hang in a conspicuous place. A classic example is the principles of Dieter Rams that he promoted in Braun. There is still such a selection of principles of younger companies , you can study and be inspired. The bonus of the approach will be the resolution of disputes - when we do not have the opportunity to check different solutions, then we should accept the one that follows our design principles more. We remove unnecessary disputes, thereby saving working time.
Of course, these tips for protecting solutions will not help us in all situations, but following them it will be easier to approve the design.
After design
After the approval of the design, development begins. A product designer is closely associated with developers. In our Beepcar team, designers sit together with developers, this speeds up the resolution of small issues and increases mutual understanding between us.
The entire last module is extremely important for the designer. Who needs our beautiful layouts, if at the exit people see a frankly trashy product. Then most of our efforts will go to waste. Therefore, we monitor the correct implementation of our design - they will ask us if something looks or works not according to the approved design.
Training
Before giving the layouts, you need to make sure that we have calculated all the states for all screens. In order not to forget anything, it’s good to make yourself a checklist of states, for each project it will be individual, but you can start with standard things:
- How the screen will look if there is no content;
- What will happen if the Internet disappears or is slow;
- What it looks like for an unauthorized user;
- The maximum and minimum length of text fields;
- How long names are shortened;
- The names on the buttons fit in all the languages that we support;
- Where errors can occur and how they should look;
- What items may be inactive.
In addition, we must be sure that our design will be displayed equally well on all available platform screens. It happens that it’s hard to please everyone, then you can take a look at the analytics and sacrifice the quality of the display at unpopular resolutions. And vice versa, those permissions that we have in the first places should be worked out to the smallest detail.
How to transfer layouts
To transfer layouts we use the well-known Zeplin and the less well-known Sympli . If a team has a lot of people who should have access to layouts, you should pay attention to the second one, it will come out cheaper, due to an unlimited number of seats for a fixed price.
If there is an animation, show it on a GIF or video and make a description with changes to each parameter:
animation: easy in-out
time: 0.2
opacity: 100% → 90%
During development , we always stay in touch, any design question slows down development. We try to immediately respond to mail and other communication channels.
The final stage is testing and Design Review. At Beepcar, these processes are structured as follows:
- If we are talking about mobile applications, then the developer rolls out the feature to the test assembly through HockeyApp . If about the Web, then the feature is sent to our test server.
- Testers look at all devices, and compare the layouts of the designer with what happened. They immediately comment on the candid jambs into the task and send it back to the developers for revision. In controversial moments, a designer is involved in the discussion.
- After the testers are completely satisfied with the quality of the feature, the task returns to the designer. He must conduct a Design Review. Now we are in the hands of almost the final version of the feature. For the most part, the designer is required to check all indentation, skittles, colors, icons, etc., so that everything looks smooth and clean. It all depends on the developer, if he is attentive to details, then there is no need to especially check anything. As soon as the designer finally confirmed that everything suits him, the feature goes to the final assembly.
Epilogue
Of course, following the cycle clearly does not always work. There are deviations: rethinking tasks, rollbacks and all that is inherent in our work. But over the year of use inside Beepcar, this principle of work has paid off - in terms of time the design has become more predictable, and the designers themselves are more immersed in the product.
Thanks for attention.
