"If the 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 managers of start-ups and technology companies how their teams create user interfaces.
What we learned from this conversation:
We have a joint development team of designers for all the projects we are involved in: from the parent company of an investment fund to key projects that generate cash flow. This allows you to efficiently use resources, always provide developers with interesting and new tasks, and designers to improve skills through the use of approaches from different industries. Most importantly, our approach allows us to attract the most talented people from the industry who at the same time have experience and are not constrained in their creative realization. We have great feel design specialists from Sberbank CIB and a number of European banks.
')
Since the main field 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 smiles are not about us.
What algorithm do we use to validate layouts?
After developing the layout and integration, we are refining it in a lively environment. I never had to change something drastically, since we have the right phased development strategy.
We also rely on experienced professionals who have been working in the industry for years and know exactly what will be useful for 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 potential competitors on 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 realize concepts with a design agency with conscious results.
At the entrance, the product concept was shaped by our strategic marketing based on the fact that the main competitive advantage is the ability to build complex multimodal routes. We needed to combine several existing behavioral patterns for the purchase of railway, air and bus tickets in one interface, as well as build search and sale for all types of transport in one basket.
When choosing and approving layouts, we were guided by two aspects: an assessment of technical capabilities for the implementation of all necessary functions and subsequent focus groups to identify the strengths and weaknesses of the layouts.
To do this, we ask the user to purchase a specific route and see exactly how he does it. We mark the steps in which he spends a lot of time or starts asking questions as points for analysis and refinement, and we attribute actions that he does quickly to convenient and understandable ones. 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 image of the service for finding routes and buying tickets, where users need to fill in two appropriate windows “where” and “from”. At the focus groups, users rated a brief and concise text message “I want to get ...” and identified this as a distinctive feature from other transport services.
There were different types of behavior on the ticket sale 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 the universal issuance of routes, first there, and then back. Now we plan to make it our advantage, because when a user gets used to buying a ticket for one type of transport, it will be just as easy for him to purchase a ticket for another type of transport.
The main thing is not to be afraid to experiment, from the very beginning to test the product for different groups of users and to improve the UI.
We do not consider the UI in isolation from the UX. The first always stands guard over the second. In the work on the UI, we are not very different from the majority of our colleagues: we are working on a graphical representation in the last place, when all issues have been resolved. If the task is simpler, then we create the solution immediately, if it is difficult, we decompose and make prototypes.
All the technical work on the interfaces we have 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. Source codes for developers are loaded into Zeppelin.
Our UI is associated with UX, and UX with intelligent algorithms for generating a tape of vacancies and candidates. We use machine learning to show candidates the most suitable vacancies, and recruiters - the most suitable candidates during the cold search in the database. We achieve this by four aspects:
Socio-demographic characteristics of candidates. We have accumulated a large history of views and job vacancies from candidates, and now we use it to make the product better, taking advantage of this data. For example, a girl of eighteen, most likely, will not be interested in the vacancy of a porter or driver, but may be interested in a man of forty. In addition, we will soon have the “Desired Professions”, and the candidate will be able to indicate who exactly he wants to work in the first place. This will further improve the ML-tape. Now we are generating a custom tape using 150 features.
Instant interest. If a man of forty years often looks at or adds to the vacancies of cashiers, our algorithms understand that he is interested in precisely the vacancies of cashiers, and not at all the loaders or drivers.
Fines If the recruiter does not process the responses within a certain time, we conclude that for this vacancy the need for candidates is satisfied, and lower it in the issue. So we encourage recruiters to respond to candidates faster.
Job groupings. There are really massive vacancies, like cashiers at KFC. In order for the candidate to see a more diverse tape, we group them into one vacancy, while showing the most suitable one in the tape.
In the visual component, we do not trust the taste, but we use a data-driven approach, so we launch different versions of interface solutions only through A / B testing. Together with the analytics department, we closely monitor the target indicators of each solution and after a while we leave the most effective.
It is difficult to understand in advance what will be convenient and what is not. In the process of working on interfaces, the experience of the designer is important, when he already knows which behaviors 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, to conduct "corridor testing." Most illogical or incomprehensible things appear immediately.
More complex and expensive: UX-tests on real users with recording all interactions with the interface on the camera and the subsequent mini-interview. In terms of a startup, this does not always have the time and resources, but for mature companies this can be the main option, especially if the service has a large audience.
The most common case for making changes is that the end user doesn’t really want to delve into the interface. Each new iteration of any ready-made functionality is often aimed at simplifying it, rather than increasing the possibilities, although this is also important.
With each new iteration, it is necessary to sift the interfaces and bring to the fore the most important elements, and subordinate to the background.
You should not try to hit 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 solutions within the team, and then directly in front of users. You listen to feedback, interact with the business, optimize solutions. You can always analyze live numbers right away. But in the design work all the more difficult. Here we have to make compromises - to convince the customer that the solution is optimal, that business problems are in the same priority as the user experience. And if with UX it is slightly easier to do this, then with UI it is more and more subjective. Even if you show the results of the A / B test, many customers will have unconstructive comments. It helps calm and systematic work with the customer - it must be brought to a constructive dialogue on important issues. It also helps to prepare and approve a guideline before work - this is a strong argument in future non-constructive disputes.
All cases, of course, must end successfully, and the criteria and parameters of success must also be determined. The main part of the problems will go away with experience, there will be an understanding of user behavior, their interaction patterns. All this will save a lot of time in the initial stages in the future.
Those times, when between versions could take more than a year, are long gone. Everything accelerated. In the current world, business goals, objectives and the environment change much faster than the product goes into release. So the product is not a monolith. This is a system that must change and adapt to the changing environment on the one hand, and business objectives 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 out, formulated and arranged. You can test the style on offline media and even on the printing industry. It will never be superfluous, but in the future you will get rid of the problems of product inconsistency and marketing, presentations, documentation, offline materials, landing pages and advertising.
Many for some reason miss this, but if all the work is started with the formation of a common visual language, this 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 efficient construction management using drones. Although it is a B2B product, we make it like 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 the surveyors give them up-to-date 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 for half an hour or less.
We have B2B sales, but in terms of product use, we have more B2C. We eschew the unpleasant, complicated for perception and use of multilayer interfaces that are common to many B2B products. We attentively listen to users, people, how they use the product, and adapt the interface so that it becomes even more convenient and easier for them to solve their problems. The process of developing a UI is not much different from that for B2C products: the person and his convenience at the forefront.
We have two feedback fronts - the 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 who help bring it to the working version. The final word remains for the designer, and it is important to understand that this is a product designer, solutions are always justified and weighed, and include the possibilities of implementation within a specified time frame with certain development resources.
To understand that our users seem convenient or inconvenient, you need to know them, and for this you need to communicate with them a lot. 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 to 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 clients and combining our goals and principles, we formulate hypotheses about what will be convenient or inconvenient, and then we test them.
We also have customer service managers who continuously communicate with customers and receive feedback. They are especially good at finding out what is not working the way we 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 time and resource limitations, and it is often impossible to calculate everything, mistakes are inevitable. For example, we do not conduct large-scale A / B testing of interfaces due to a user base that is not large enough for this. We develop the interface using detailed feedback from the most loyal customers. This is quick and convenient, but the conclusions made on the basis of communication with such a limited audience, risk not to please many other users of the product. We never had critical interface errors that would block the work, but we had to do hot fixes of the interface. Here again, fast and proactive communication from our clients helped a lot.
UI should help the user to solve their problems in the interface. To consider it out of this context is fraught with a shift of meaning from use to decoration. Therefore, for young products, the development vector in working with UI should be this: first, help and engage, then form habits and create a new unique experience.
Each industry has its own characteristics, its established behavior patterns and trends. But there are universal designs used everywhere. Tracking, interpreting and correctly using 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 some rules for effective work with UI, which I highlighted for myself:
Courses "Netology" for interface designers:
What we learned from this conversation:
- the main thing is the product, not the design;
- communication with users and user analytics allow you to make the most convenient to use interface (but this is not accurate);
- One of the most effective methods for evaluating user actions is a test task;
- you should not consider the UI in isolation from the UX - the first is always on guard of the second;
- subjective taste in interfaces is good, but the data-driven approach is still better;
- The easiest 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 any ready-made functionality are aimed at simplifying it, and not at increasing the possibilities: 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 get unconstructive comments - calm systematic work and constant dialogue on important issues help;
- UI should help the user to solve their tasks in the interface, and viewing it outside this context, there is a risk to shift the meaning from good to embellishment;
- 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 a joint development team of designers for all the projects we are involved in: from the parent company of an investment fund to key projects that generate cash flow. This allows you to efficiently use resources, always provide developers with interesting and new tasks, and designers to improve skills through the use of approaches from different industries. Most importantly, our approach allows us to attract the most talented people from the industry who at the same time have experience and are not constrained in their creative realization. We have great feel design specialists from Sberbank CIB and a number of European banks.')
Since the main field 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 smiles are not about us.
What algorithm do we use to validate layouts?
- Formulation of the problem.
- The study of references.
- Reviewing references with the aim of identifying key points for improvement.
- Design by designers of several primary layouts.
- The choice of direction from the presented layouts or the development of a new one.
- Refinement of the key idea of ​​the selected layout.
- Delivery on the layout.
After developing the layout and integration, we are refining it in a lively environment. I never had to change something drastically, 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 years and know exactly what will be useful for 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 make an ideal product right away, so don’t be afraid to develop a service together with users”
For Movista, a travel planning service, we first of all examined potential competitors on 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 realize concepts with a design agency with conscious results.
At the entrance, the product concept was shaped by our strategic marketing based on the fact that the main competitive advantage is the ability to build complex multimodal routes. We needed to combine several existing behavioral patterns for the purchase of railway, air and bus tickets in one interface, as well as build search and sale for all types of transport in one basket.
When choosing and approving layouts, we were guided by two aspects: an assessment of technical capabilities for the implementation of all necessary functions and subsequent focus groups to identify the strengths and weaknesses of the layouts.
We consider the test task to be the most effective method for evaluating user actions in a service.
To do this, we ask the user to purchase a specific route and see exactly how he does it. We mark the steps in which he spends a lot of time or starts asking questions as points for analysis and refinement, and we attribute actions that he does quickly to convenient and understandable ones. 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 image of the service for finding routes and buying tickets, where users need to fill in two appropriate windows “where” and “from”. At the focus groups, users rated a brief and concise text message “I want to get ...” and identified this as a distinctive feature from other transport services.
There were different types of behavior on the ticket sale 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 the universal issuance of routes, first there, and then back. Now we plan to make it our advantage, because when a user gets used to buying a ticket for one type of transport, it will be just as easy for him to purchase a ticket for another type of transport.
The main thing is not to be afraid to experiment, from the very beginning to test the product for different groups of users and to improve the UI.
It’s impossible to make an ideal product right away, so don’t be afraid to develop a service with users.
Ivan Ardintsev, CPD Worki :
“We don’t trust flavors in the visual component, but use a data-driven approach, therefore we launch different variants of interface solutions only through A / B testing”
We do not consider the UI in isolation from the UX. The first always stands guard over the second. In the work on the UI, we are not very different from the majority of our colleagues: we are working on a graphical representation in the last place, when all issues have been resolved. If the task is simpler, then we create the solution immediately, if it is difficult, we decompose and make prototypes.All the technical work on the interfaces we have 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. Source codes for developers are loaded into Zeppelin.
Our UI is associated with UX, and UX with intelligent algorithms for generating a tape of vacancies and candidates. We use machine learning to show candidates the most suitable vacancies, and recruiters - the most suitable candidates during the cold search in the database. We achieve this by four aspects:
Socio-demographic characteristics of candidates. We have accumulated a large history of views and job vacancies from candidates, and now we use it to make the product better, taking advantage of this data. For example, a girl of eighteen, most likely, will not be interested in the vacancy of a porter or driver, but may be interested in a man of forty. In addition, we will soon have the “Desired Professions”, and the candidate will be able to indicate who exactly he wants to work in the first place. This will further improve the ML-tape. Now we are generating a custom tape using 150 features.
Instant interest. If a man of forty years often looks at or adds to the vacancies of cashiers, our algorithms understand that he is interested in precisely the vacancies of cashiers, and not at all the loaders or drivers.
Fines If the recruiter does not process the responses within a certain time, we conclude that for this vacancy the need for candidates is satisfied, and lower it in the issue. So we encourage recruiters to respond to candidates faster.
Job groupings. There are really massive vacancies, like cashiers at KFC. In order for the candidate to see a more diverse tape, we group them into one vacancy, while showing the most suitable one in the tape.
In the visual component, we do not trust the taste, but we use a data-driven approach, so we launch different versions of interface solutions only through A / B testing. Together with the analytics department, we closely monitor the target indicators of each solution and after a while we leave the most effective.
It is difficult to understand in advance what will be convenient and what is not. In the process of working on interfaces, the experience of the designer is important, when he already knows which behaviors 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, to conduct "corridor testing." Most illogical or incomprehensible things appear immediately.
More complex and expensive: UX-tests on real users with recording all interactions with the interface on the camera and the subsequent mini-interview. In terms of a startup, this does not always have the time and resources, but for mature companies this can be the main option, especially if the service has a large audience.
The most common case for making changes is that the end user doesn’t really want to delve into the interface. Each new iteration of any ready-made functionality is often aimed at simplifying it, rather than increasing the possibilities, although this is also important.
With each new iteration, it is necessary to sift the interfaces and bring to the fore the most important elements, and subordinate to the background.
If you are not working on a highly specialized interface, the “simpler - better” rule should be in the first place.
You should not try to hit 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, product director Rubrain.com :
“If you start all the work with the formation of a common visual language, this will greatly facilitate the work in several directions at once and at the same time will cost almost nothing”
When you are responsible for a product, especially in a startup, you protect solutions within the team, and then directly in front of users. You listen to feedback, interact with the business, optimize solutions. You can always analyze live numbers right away. But in the design work all the more difficult. Here we have to make compromises - to convince the customer that the solution is optimal, that business problems are in the same priority as the user experience. And if with UX it is slightly easier to do this, then with UI it is more and more subjective. Even if you show the results of the A / B test, many customers will have unconstructive comments. It helps calm and systematic work with the customer - it must be brought to a constructive dialogue on important issues. It also helps to prepare and approve a guideline before work - this is a strong argument in future non-constructive disputes.To understand what is convenient for the user and what is not, at an early design stage, you need to go all 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, must end successfully, and the criteria and parameters of success must also be determined. The main part of the problems will go away with experience, there will be an understanding of user behavior, their interaction patterns. All this will save a lot of time in the initial stages in the future.
Those times, when between versions could take more than a year, are long gone. Everything accelerated. In the current world, business goals, objectives and the environment change much faster than the product goes into release. So the product is not a monolith. This is a system that must change and adapt to the changing environment on the one hand, and business objectives 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 out, formulated and arranged. You can test the style on offline media and even on the printing industry. It will never be superfluous, but in the future you will get rid of the problems of product inconsistency and marketing, presentations, documentation, offline materials, landing pages and advertising.
Many for some reason miss this, but if all the work is started with the formation of a common visual language, this 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:
“To understand that our users seem comfortable or uncomfortable, you need to know them, and for this you need to communicate with them a lot”
We make software for efficient construction management using drones. Although it is a B2B product, we make it like 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 the surveyors give them up-to-date 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 for half an hour or less. We have B2B sales, but in terms of product use, we have more B2C. We eschew the unpleasant, complicated for perception and use of multilayer interfaces that are common to many B2B products. We attentively listen to users, people, how they use the product, and adapt the interface so that it becomes even more convenient and easier for them to solve their problems. The process of developing a UI is not much different from that for B2C products: the person and his convenience at the forefront.We have two feedback fronts - the 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 who help bring it to the working version. The final word remains for the designer, and it is important to understand that this is a product designer, solutions are always justified and weighed, and include the possibilities of implementation within a specified time frame with certain development resources.
To understand that our users seem convenient or inconvenient, you need to know them, and for this you need to communicate with them a lot. 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 to 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 clients and combining our goals and principles, we formulate hypotheses about what will be convenient or inconvenient, and then we test them.
We also have customer service managers who continuously communicate with customers and receive feedback. They are especially good at finding out what is not working the way we 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 time and resource limitations, and it is often impossible to calculate everything, mistakes are inevitable. For example, we do not conduct large-scale A / B testing of interfaces due to a user base that is not large enough for this. We develop the interface using detailed feedback from the most loyal customers. This is quick and convenient, but the conclusions made on the basis of communication with such a limited audience, risk not to please many other users of the product. We never had critical interface errors that would block the work, but we had to do hot fixes of the interface. Here again, fast and proactive communication from our clients helped a lot.
Sergey Kireev, head of AIC design department:
“We love beautiful and well-developed interfaces, but if the product works poorly, the UI will not make people use it”
UI should help the user to solve their problems in the interface. To consider it out of this context is fraught with a shift of meaning from use to decoration. Therefore, for young products, the development vector in working with UI should be this: first, help and engage, then form habits and create a new unique experience.Each industry has its own characteristics, its established behavior patterns and trends. But there are universal designs used everywhere. Tracking, interpreting and correctly using 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 some rules for effective work with UI, which I highlighted for myself:
- Test the product constantly. It is important to conduct quantitative and qualitative testing. Quantitative will help optimize the scenarios and understand where the problem lies, and qualitative ones - to get to the bottom of the problem and learn deep insights.
- Design is a constant bug fix. It is important to quickly respond, correct and extract experience from every slip, fixing it in order to avoid 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. It is necessary to identify key metrics, find a loyal audience and start with it. Collect feedback, understand where the errors are, correct and update. Act in short iterations.
- Formulate 10 principles that define what good design is for the product you are working on. Let them become a guide and test solutions for the design team. These principles may concern various aspects that you consider important for your product or company, but should not be interpreted in two ways or abstractly. Examples of such principles can be found at designprinciplesftw.com .
- Get the design team to document their decisions , review the layouts, compile libraries of elements and patterns. This is necessary for those situations where there is a risk to get interface elements that look different, although they perform the same function, or vice versa.
From the Editor
Courses "Netology" for interface designers:
- profession " grocery designer "
- profession " UI-designer "
- profession " UX-designer "
Source: https://habr.com/ru/post/442558/
All Articles