March 4, 2019 at 18:39“If a product is not needed, no matter how you pack it, there will be no sense”: how technology companies work on interfaces
Alexey Skorik from Vinci Agency specifically for the Netology blog asked startups and technology companies executives about how their teams create user interfaces.
What we learned from this conversation:
We have an integrated team of development designers for all the projects that we are engaged in: from the parent company of the investment fund to key projects that generate cash flow. This allows you to effectively use resources, always provide developers with interesting and new tasks, and designers to improve their skills through the application of approaches from different industries. Most importantly, our approach allows us to attract the most talented people from the industry who simultaneously have experience and are not constrained in their creative implementation. Designers from Sberbank CIB and a number of European banks are doing very well here.
Since the main area of activity is related to investments and the corporate market, we create interfaces and styles that are most in demand in the business environment, so emoji and selfie emoticons are not about us.
What algorithm do we use to approve layouts?
After developing the layout and integration, we are finalizing it in a living environment. It was never necessary to change something radically, since we have the right phased development strategy.
We also rely on experienced professionals who have been working in the industry for several years and know for sure what will be useful to the user.
In the end, I want to say that many years ago I learned the rule: “if the product is not needed, then no matter how you pack it, there will be no sense”. The main thing is the product, not the design.
For Movista, a travel planning service, we first of all examined the potential competitors existing in the market: direct and indirect, domestic and foreign.
Then they compiled the first version of the user behavior map in the service and assembled the first prototype visualized in Figma. It so happened to evaluate the functionality of the service, test hypotheses and prepare for experiments with focus groups in order to implement concepts with a design agency with conscious results.
At the input, the product concept was formed by our strategic marketing on the basis that the main competitive advantage is the ability to build complex multimodal routes. We needed to combine several existing behavioral patterns for buying railway, air and bus tickets in one interface, as well as integrate search and sale for all types of transport in one basket.
When choosing and approving layouts, we were guided by two aspects: assessing the technical capabilities to implement all the necessary functions and subsequent focus groups to identify the strengths and weaknesses of layouts.
To do this, we ask the user to purchase a specific route and see how exactly he does it. We mark the steps at which he spends a lot of time or begins to ask questions as moments for analysis and refinement, and the actions that he performs quickly are considered convenient and understandable. We carry out such iterations after the introduction of changes and on different groups of users, which allows us to make the service more universal and understandable.
We managed to get away from the stereotypical idea of the service for finding routes and buying tickets, where users need to fill out two corresponding windows “where” and “where”. At focus groups, users rated the short and concise text message “I want to get ...” and singled it out as a distinguishing feature from other transport services.
There are various types of behaviors in the ticket sales market: air tickets are often bought back and forth, and users want to see the entire route at once, while in the railway sector it is typical to buy a ticket first one way and then the other. We did not immediately identify these behavioral features and implemented a universal issuance of routes first there and then back. Now we plan to make this our advantage, because when a user gets used to buying a ticket for one mode of transport, it will be just as easy for him to purchase a ticket for another mode of transport.
The main thing is not to be afraid to experiment, from the very beginning to test the product on different user groups and improve the UI.
We do not consider UI in isolation from UX. The first always guards the second. In the work on UI, we are not very different from most colleagues: we work on the graphical presentation last, when all issues have already been resolved. If the task is simpler, then we create a solution immediately, if it is difficult, we decompose and make prototypes.
All the technical work on the interfaces is done in Sketch with the Abstract version control system. When the layouts are ready, we connect them through Overflow, which generates a convenient map of functionality. Download source codes for developers in Zeppelin.
Our UI is connected with UX, and UX - with smart algorithms for forming a tape of vacancies and candidates. We use machine learning to show candidates the most suitable vacancies, and to recruiters - the most suitable candidates when performing a cold search in the database. We achieve this through four aspects: The
socio-demographic characteristics of the candidates.We have accumulated a large history of views and responses of vacancies from candidates, and now we use it to make the product better, taking advantage of this data. For example, a girl of eighteen years old, most likely, will not be interested in the vacancies of a loader or driver, but they may be of interest to a man of forty years old. In addition, we will soon have “Desired Professions”, and the candidate will be able to indicate exactly who he wants to work in the first place. This will further improve ML tape. Now we generate a personalized feed using 150 features.
Instant interest. If a forty-year-old man often looks at or adds to the cashier’s vacancies, our algorithms understand that he is interested in the cashier’s vacancies, and not at all loaders or drivers.
Fines.If the recruiter does not process the responses within a certain time, we conclude that the need for candidates for this vacancy is satisfied, and lower it in the issuance. So we encourage recruiters to respond more quickly to candidates.
Job groupings. There are really massive vacancies, like cashiers at KFC. In order for the candidate to see a more diverse stream, we group them into one vacancy, while showing in the tape the most suitable for him.
In the visual component, we do not trust the taste of taste, but use the data-driven approach, so we only run different versions of interface solutions through A / B testing. Together with the analytics department, we carefully monitor the target indicators of each solution and after some time we leave it as effective as possible.
It is difficult to understand in advance what will be convenient and what is not. In the process of working on interfaces, the designer’s experience is important when he already knows which patterns of behavior work and are familiar to the user, and which ones will definitely cause difficulties. This does not exclude the possibility of experimentation, but it is better not to use hard-avant-garde solutions for a mass audience.
The easiest and cheapest way to test yourself is to show your colleagues and conduct “corridor testing”. Most illogical or obscure things appear immediately.
More complex and expensive: UX tests on real users with a record of all interactions with the interface on the camera and a subsequent mini-interview. In a startup, this does not always have the time and resources, but for mature companies this may be the main option, especially if the service has a large audience.
The most common case for making changes is that the end user does not really want to delve into the interface. Each new iteration of a ready-made functionality is often aimed at simplifying it, and not at increasing the capabilities, although this is also important.
With each new iteration, you need to sift through the interfaces and bring to the forefront the most important elements, and secondary ones to push to the background.
You should not try to impress the user with a wealth of opportunities, loading each functional screen to the maximum: at best, most of the presented will simply not be used.
When you are responsible for a product, especially in a startup, you protect decisions within the team, and then immediately in front of users. You listen to feedback, interact with business, optimize solutions. You can always immediately analyze live numbers. But in the design work, everything is more complicated. Here you have to make compromises - to convince the customer that the solution is optimal, that business tasks are in the same priority as the user experience. And if with UX it is a little easier to do, then with UI everything is more subjective. Even if you show the results of an A / B test, many customers will have non-constructive comments. Here a calm and systematic work with the customer helps - he must be brought to a constructive dialogue on important issues. It also helps to draw up and approve a guideline before work - this is a strong argument in future unconstructive disputes.
All cases, of course, should end successfully, and the criteria and parameters of success themselves must also be determined. Most of the problems will go away with experience, an understanding of user behavior, their interaction patterns will appear. All this will save a lot of time in the initial stages in the future.
Those days when more than a year could have passed between versions have long passed. Everything accelerated. In the current world, business goals, tasks and the environment are changing much faster than the product is released. So the product is not a monolith. This is a system that should change and adapt to a changing environment on the one hand and business tasks on the other.
Also important is a simple, understandable and at the same time emotional and expressive visual language, if possible even before starting work on the screens. Style, rhymes, tricks, restrictions. All this needs to be described, thought over, formulated and formalized. You can test the style on offline media and even on printing. This will never be superfluous, but in the future you will get rid of the problems of product and marketing inconsistencies, presentations, documentation, offline materials, landing pages and advertising.
Many people miss this for some reason, but if you start all the work with the formation of a common visual language, it will greatly facilitate the work in several directions at once in the future and at the same time will cost almost nothing. Even if now it seems to you absolutely superfluous.
Nikita Ushakov, co-founder and marketing director of TraceAir and Alexander Smetanka, designer of TraceAir:
We make software for effective construction management using drones. Although this is a B2B product, we make it like a B2C. Unlike many companies that make similar software for construction, our task is to make it useful for field staff, and not just for engineers who are technically more savvy and already work in various complex engineering programs. As a result, we eliminate the lack of information for builders who do not have time to wait until surveyors give them the latest information about the site or get the necessary information in complex engineering software. Therefore, we make our software extremely simple. Almost everyone can learn to use our product in half an hour or less.
We have B2B sales, but in terms of using the product, we have more B2C. We shun unpleasant, difficult to understand and use multi-layer interfaces that are common to many B2B products. We carefully listen to users, people, how they use the product, and adapt the interface so that it becomes even more convenient and easier to solve their problems. The process of developing a UI is not much different from that for B2C products: people and their convenience are at the forefront.
We have two fronts of feedback collection - an internal team and customers. The whole team affects the design, everyone can make their own changes. Next, we test prototypes on the most loyal customers, which help bring it to the working version. The final word remains with the designer, and it is important to understand that this is a product designer, decisions are always justified and balanced, and include the possibility of implementation on time with specified development resources.
To understand what seems convenient or inconvenient for our users, you need to know them, and for this you need to communicate a lot with them. Continuous communication and immersion in the essence of their professions provides an initial understanding of what is convenient for them. But innovation is not done only through communication with users. It also comes from the team, the strategic goals that you set for yourself, and the principles that you follow towards this goal. Our goal is building automation. One of the principles is to make the product as simple as possible, which everyone can use. Actively communicating with customers and combining our goals and principles, we formulate hypotheses about what will be convenient or inconvenient, and then test them.
We also have customer service managers who continuously communicate with customers and receive feedback. They are especially good at finding out what does not work as they would like - they are very eagerly told about this. Users are passionate about our product and their development is not indifferent to them.
While we are still a startup, therefore, there are restrictions on time and resources, and often it is not possible to calculate everything, errors are inevitable. For example, we do not conduct large-scale A / B testing of interfaces because of the insufficient user base for this. We are developing an interface using detailed feedback from the most loyal customers. This is quick and convenient, but the conclusions drawn from communicating with such a limited audience run the risk of not being liked by many other users of the product. We never had critical interface errors that would block the work, but we had to do hot fixes for the interface. Here again, a quick and proactive communication from our customers helped a lot.
UI should help the user to solve their tasks in the interface. Examining it outside this context is fraught with a shift in meaning from benefit to embellishment. Therefore, for young products, the development vector in working with UI should be like this: first help and engage, then form habits and create a new unique experience.
Each industry has its own characteristics, its own established patterns of behavior and trends. But there are universal designs used everywhere. Tracking, interpreting and correctly applying them is the task of a professional designer, and awareness is the main criterion in working with UI. Always ask yourself: why are we doing this? Does this solve our problem? What benefits will it bring?
Here are a few rules for working effectively with UI that I have identified for myself:
Netology courses for interface designers:
What we learned from this conversation:
- the main thing is the product, not the design;
- communication with users and user analytics make it possible to make the interface as user-friendly as possible (but this is not accurate);
- one of the most effective methods for evaluating user actions is a test task;
- do not consider the UI in isolation from the UX - the first is always on guard of the second;
- a subjective taste in interfaces is good, but a data-driven approach is still better;
- the simplest and cheapest way to test a product is “corridor testing”, which in any case is much better than the absence of any user testing at all;
- most often, new iterations of some ready-made functionality are aimed at simplifying it, and not at increasing capabilities: and all because the end user does not really want to delve into the interface;
- even if you show the results of the A / B test to the customer, he may still have non-constructive comments - it helps to calm systematic work and constant dialogue on important issues;
- UI should help the user to solve their tasks in the interface, and considering it outside this context, there is a risk of shifting the meaning from the benefit to the decoration;
- always ask yourself: why are we doing this? Does this solve our problem? what benefits will it bring?
Alexander Peterman, founder of Notify.Network :
“To make the UI as convenient as possible, we use our own analytics and direct communication with users”
We have an integrated team of development designers for all the projects that we are engaged in: from the parent company of the investment fund to key projects that generate cash flow. This allows you to effectively use resources, always provide developers with interesting and new tasks, and designers to improve their skills through the application of approaches from different industries. Most importantly, our approach allows us to attract the most talented people from the industry who simultaneously have experience and are not constrained in their creative implementation. Designers from Sberbank CIB and a number of European banks are doing very well here.Since the main area of activity is related to investments and the corporate market, we create interfaces and styles that are most in demand in the business environment, so emoji and selfie emoticons are not about us.
What algorithm do we use to approve layouts?
- Formulation of the problem.
- The study of references.
- Analysis of references in order to identify key points for improvement.
- Designers developing several primary layouts.
- Choosing a direction from the presented layouts or developing a new one.
- Refinement of the key idea of the selected layout.
- Submission for layout.
After developing the layout and integration, we are finalizing it in a living environment. It was never necessary to change something radically, since we have the right phased development strategy.
To make the UI as convenient as possible, we use our own analytics and direct communication with users.
We also rely on experienced professionals who have been working in the industry for several years and know for sure what will be useful to the user.
In the end, I want to say that many years ago I learned the rule: “if the product is not needed, then no matter how you pack it, there will be no sense”. The main thing is the product, not the design.
Sergey Podshivalin, CPO Movista :
“It’s impossible to immediately make the perfect product, so don’t be afraid to develop the service with users”
For Movista, a travel planning service, we first of all examined the potential competitors existing in the market: direct and indirect, domestic and foreign. Then they compiled the first version of the user behavior map in the service and assembled the first prototype visualized in Figma. It so happened to evaluate the functionality of the service, test hypotheses and prepare for experiments with focus groups in order to implement concepts with a design agency with conscious results.
At the input, the product concept was formed by our strategic marketing on the basis that the main competitive advantage is the ability to build complex multimodal routes. We needed to combine several existing behavioral patterns for buying railway, air and bus tickets in one interface, as well as integrate search and sale for all types of transport in one basket.
When choosing and approving layouts, we were guided by two aspects: assessing the technical capabilities to implement all the necessary functions and subsequent focus groups to identify the strengths and weaknesses of layouts.
The most effective method for evaluating user actions in the service we consider a test task.
To do this, we ask the user to purchase a specific route and see how exactly he does it. We mark the steps at which he spends a lot of time or begins to ask questions as moments for analysis and refinement, and the actions that he performs quickly are considered convenient and understandable. We carry out such iterations after the introduction of changes and on different groups of users, which allows us to make the service more universal and understandable.
We managed to get away from the stereotypical idea of the service for finding routes and buying tickets, where users need to fill out two corresponding windows “where” and “where”. At focus groups, users rated the short and concise text message “I want to get ...” and singled it out as a distinguishing feature from other transport services.
There are various types of behaviors in the ticket sales market: air tickets are often bought back and forth, and users want to see the entire route at once, while in the railway sector it is typical to buy a ticket first one way and then the other. We did not immediately identify these behavioral features and implemented a universal issuance of routes first there and then back. Now we plan to make this our advantage, because when a user gets used to buying a ticket for one mode of transport, it will be just as easy for him to purchase a ticket for another mode of transport.
The main thing is not to be afraid to experiment, from the very beginning to test the product on different user groups and improve the UI.
It is impossible to immediately make the perfect product, so do not be afraid to develop the service with users.
Ivan Ardintsev, CPD Worki :
“In the visual component, we do not trust the taste of taste, but use the data-driven approach, so we only run different versions of interface solutions through A / B testing”
We do not consider UI in isolation from UX. The first always guards the second. In the work on UI, we are not very different from most colleagues: we work on the graphical presentation last, when all issues have already been resolved. If the task is simpler, then we create a solution immediately, if it is difficult, we decompose and make prototypes. All the technical work on the interfaces is done in Sketch with the Abstract version control system. When the layouts are ready, we connect them through Overflow, which generates a convenient map of functionality. Download source codes for developers in Zeppelin.
Our UI is connected with UX, and UX - with smart algorithms for forming a tape of vacancies and candidates. We use machine learning to show candidates the most suitable vacancies, and to recruiters - the most suitable candidates when performing a cold search in the database. We achieve this through four aspects: The
socio-demographic characteristics of the candidates.We have accumulated a large history of views and responses of vacancies from candidates, and now we use it to make the product better, taking advantage of this data. For example, a girl of eighteen years old, most likely, will not be interested in the vacancies of a loader or driver, but they may be of interest to a man of forty years old. In addition, we will soon have “Desired Professions”, and the candidate will be able to indicate exactly who he wants to work in the first place. This will further improve ML tape. Now we generate a personalized feed using 150 features.
Instant interest. If a forty-year-old man often looks at or adds to the cashier’s vacancies, our algorithms understand that he is interested in the cashier’s vacancies, and not at all loaders or drivers.
Fines.If the recruiter does not process the responses within a certain time, we conclude that the need for candidates for this vacancy is satisfied, and lower it in the issuance. So we encourage recruiters to respond more quickly to candidates.
Job groupings. There are really massive vacancies, like cashiers at KFC. In order for the candidate to see a more diverse stream, we group them into one vacancy, while showing in the tape the most suitable for him.
In the visual component, we do not trust the taste of taste, but use the data-driven approach, so we only run different versions of interface solutions through A / B testing. Together with the analytics department, we carefully monitor the target indicators of each solution and after some time we leave it as effective as possible.
It is difficult to understand in advance what will be convenient and what is not. In the process of working on interfaces, the designer’s experience is important when he already knows which patterns of behavior work and are familiar to the user, and which ones will definitely cause difficulties. This does not exclude the possibility of experimentation, but it is better not to use hard-avant-garde solutions for a mass audience.
The easiest and cheapest way to test yourself is to show your colleagues and conduct “corridor testing”. Most illogical or obscure things appear immediately.
More complex and expensive: UX tests on real users with a record of all interactions with the interface on the camera and a subsequent mini-interview. In a startup, this does not always have the time and resources, but for mature companies this may be the main option, especially if the service has a large audience.
The most common case for making changes is that the end user does not really want to delve into the interface. Each new iteration of a ready-made functionality is often aimed at simplifying it, and not at increasing the capabilities, although this is also important.
With each new iteration, you need to sift through the interfaces and bring to the forefront the most important elements, and secondary ones to push to the background.
If you are not working on a highly specialized interface, the “easier is better” rule should come first.
You should not try to impress the user with a wealth of opportunities, loading each functional screen to the maximum: at best, most of the presented will simply not be used.
Alexander Zhulin, Rubrain.com Product Director :
“If you start all the work with the formation of a common visual language, it will greatly facilitate the work in several directions at once in the future and at the same time will cost almost nothing”
When you are responsible for a product, especially in a startup, you protect decisions within the team, and then immediately in front of users. You listen to feedback, interact with business, optimize solutions. You can always immediately analyze live numbers. But in the design work, everything is more complicated. Here you have to make compromises - to convince the customer that the solution is optimal, that business tasks are in the same priority as the user experience. And if with UX it is a little easier to do, then with UI everything is more subjective. Even if you show the results of an A / B test, many customers will have non-constructive comments. Here a calm and systematic work with the customer helps - he must be brought to a constructive dialogue on important issues. It also helps to draw up and approve a guideline before work - this is a strong argument in future unconstructive disputes.To understand what is convenient for the user and what is not, at the early stage of designing you need to go the way yourself, test everything in the services at the prototype stage, determine the main user profiles and register cases for them.
All cases, of course, should end successfully, and the criteria and parameters of success themselves must also be determined. Most of the problems will go away with experience, an understanding of user behavior, their interaction patterns will appear. All this will save a lot of time in the initial stages in the future.
Those days when more than a year could have passed between versions have long passed. Everything accelerated. In the current world, business goals, tasks and the environment are changing much faster than the product is released. So the product is not a monolith. This is a system that should change and adapt to a changing environment on the one hand and business tasks on the other.
Also important is a simple, understandable and at the same time emotional and expressive visual language, if possible even before starting work on the screens. Style, rhymes, tricks, restrictions. All this needs to be described, thought over, formulated and formalized. You can test the style on offline media and even on printing. This will never be superfluous, but in the future you will get rid of the problems of product and marketing inconsistencies, presentations, documentation, offline materials, landing pages and advertising.
Many people miss this for some reason, but if you start all the work with the formation of a common visual language, it will greatly facilitate the work in several directions at once in the future and at the same time will cost almost nothing. Even if now it seems to you absolutely superfluous.
Nikita Ushakov, co-founder and marketing director of TraceAir and Alexander Smetanka, designer of TraceAir:
“In order to understand what our users think is convenient or inconvenient, you need to know them, and for this you need to talk a lot with them”
We make software for effective construction management using drones. Although this is a B2B product, we make it like a B2C. Unlike many companies that make similar software for construction, our task is to make it useful for field staff, and not just for engineers who are technically more savvy and already work in various complex engineering programs. As a result, we eliminate the lack of information for builders who do not have time to wait until surveyors give them the latest information about the site or get the necessary information in complex engineering software. Therefore, we make our software extremely simple. Almost everyone can learn to use our product in half an hour or less.We have B2B sales, but in terms of using the product, we have more B2C. We shun unpleasant, difficult to understand and use multi-layer interfaces that are common to many B2B products. We carefully listen to users, people, how they use the product, and adapt the interface so that it becomes even more convenient and easier to solve their problems. The process of developing a UI is not much different from that for B2C products: people and their convenience are at the forefront.We have two fronts of feedback collection - an internal team and customers. The whole team affects the design, everyone can make their own changes. Next, we test prototypes on the most loyal customers, which help bring it to the working version. The final word remains with the designer, and it is important to understand that this is a product designer, decisions are always justified and balanced, and include the possibility of implementation on time with specified development resources.
To understand what seems convenient or inconvenient for our users, you need to know them, and for this you need to communicate a lot with them. Continuous communication and immersion in the essence of their professions provides an initial understanding of what is convenient for them. But innovation is not done only through communication with users. It also comes from the team, the strategic goals that you set for yourself, and the principles that you follow towards this goal. Our goal is building automation. One of the principles is to make the product as simple as possible, which everyone can use. Actively communicating with customers and combining our goals and principles, we formulate hypotheses about what will be convenient or inconvenient, and then test them.
We also have customer service managers who continuously communicate with customers and receive feedback. They are especially good at finding out what does not work as they would like - they are very eagerly told about this. Users are passionate about our product and their development is not indifferent to them.
While we are still a startup, therefore, there are restrictions on time and resources, and often it is not possible to calculate everything, errors are inevitable. For example, we do not conduct large-scale A / B testing of interfaces because of the insufficient user base for this. We are developing an interface using detailed feedback from the most loyal customers. This is quick and convenient, but the conclusions drawn from communicating with such a limited audience run the risk of not being liked by many other users of the product. We never had critical interface errors that would block the work, but we had to do hot fixes for the interface. Here again, a quick and proactive communication from our customers helped a lot.
Sergey Kireev, head of design department AIC :
“We love beautiful and well-developed interfaces, but if the product does not work well, the UI will not force people to use it”
UI should help the user to solve their tasks in the interface. Examining it outside this context is fraught with a shift in meaning from benefit to embellishment. Therefore, for young products, the development vector in working with UI should be like this: first help and engage, then form habits and create a new unique experience. Each industry has its own characteristics, its own established patterns of behavior and trends. But there are universal designs used everywhere. Tracking, interpreting and correctly applying them is the task of a professional designer, and awareness is the main criterion in working with UI. Always ask yourself: why are we doing this? Does this solve our problem? What benefits will it bring?
Here are a few rules for working effectively with UI that I have identified for myself:
- Test the product constantly. It is important to conduct quantitative and qualitative testing. Quantitative ones will help optimize scenarios and understand where the problem lies, while qualitative ones will help to get to the bottom of the problem and learn deep insights.
- Design is the constant work on bugs. It is important to respond quickly, correct and take experience from each miss, fixing it so as to prevent similar mistakes in the future.
- Act carefully. Do not roll out a new design at once for all users - people are afraid of everything new and unknown. We need to identify key metrics, find a loyal audience and start with it. Collect feedback, understand where the errors are, fix and update. Act in short iterations.
- Formulate 10 principles that define what a good design is for the product you are working on. Let them become a guide and test decisions of the design team. These principles can cover a variety of aspects that you consider important for your product or company, but should not have a double or abstract interpretation. Examples of such principles can be found at designprinciplesftw.com .
- Make the design team document their decisions , review layouts, create libraries of elements and patterns. This is necessary for those situations where there is a risk of getting interface elements that look different, although they perform the same function, or vice versa.
From the editors
Netology courses for interface designers:
- profession " Product Designer "
- profession " UI-designer "
- profession " UX-designer "