Why does a good design start earlier than the first pictures?
We are used to the fact that design is an appearance, an interface, a style. This is something that you can see or touch. And when the product is ugly or uncomfortable, it is customary to blame the designers. They are asked to redo everything, conduct AB tests, play with fonts and conversion, but the service does not get better, and profits do not grow.
Much depends on the quality of designers' work, but design is only part of the product. In this article I want to share my opinion on what problems can lead to a bad design besides the design itself, as well as why a good design starts much earlier than drawing buttons and pictures.
In software development, the same situation is often found: people align pixels, redraw illustrations, change user scenarios, and interface. But at the same time they have problems in the work of key functions, inconsistency of departments, a name that is incomprehensible to customers, strange advertising and a lot of other problems.
')
Below are typical problems that I have observed in my (and not only) practice, leading to poor design, as well as advice on what to do with them.
How much will the product cost? What payment methods are planned? What set of options will each tariff include? What data can I do without at the stage of purchase or registration? Do I have to attach a bank card to activate the trial period? Usually these issues are resolved at the very top, consistent with the fin. workers and designers come as a given. No matter how ideal the bank card binding interface is, but if this is done during registration, the service will lose a lot of customers.
What to do?
Questions of tariff policy and finance should be resolved as early as possible, in conjunction with ux-designers and tested with the prototype service. The selection stage and the purchase of a product should not be perceived separately from its use. Problems in this part may also affect the interface.
Who are our customers? What they are not satisfied with the status quo? What are the most important product features? What are people willing to pay for? What features to include in the first version?
Anyone often seeks answers to these questions, but not the one who should. Designers and programmers are told: “We now have a lean approach, here's an idea for the product and a book for the evening. Tomorrow you will go to do customer development, then draw a design and make a prototype. ” As a result, it may turn out that the functions of the product will be convenient to use, but not those that are needed. And those that are needed are hidden far inland and are made according to the residual principle.
What to do?
It is the product manager and marketer who must find the answers to these questions as early as possible. Not without the help of colleagues, of course, but one should not let the process take its course. Without this information, designers will be guided by their own opinion, or they will conduct research on their own, but designers do not benefit from this, since they will be engaged not in the business, business, since he risks not getting what he expects. Methods of market research and market niche can be taught, but this is a separate science and a couple of start-up master classes can not do here.
Time is always not enough and you need to quickly cut the product. The design will go to work without usability testing. The analyst, looking at the layouts, will write business requirements, and the developers, without waiting for the requirements, will start programming. As a result, the product will turn out far from what was expected, with a bunch of functions, but with a much larger bunch of bugs.
What to do?
No need to rush to write the code as soon as the first version of the design appeared, and even more so when there is no design yet. This is most critical in new products and niches, when there are neither decent counterparts, nor their own data on user behavior. Everyone knows that the cost of making changes to a project is minimal at the beginning and maximum at the end, but for some reason they forget about it when it comes to business.
Even the simplest products can have several channels of interaction, different stages and stages at which the client is located. At each stage, the client interacts with different departments, people and technologies. When the processes of the units are confused, and the interaction is not established, the interface will also be complex and confusing.
What to do?
Before you automate and “digitize” business processes, they need to be simplified. So, the principle of a single window in state structures first demanded reorganization of processes within departments and only then was implemented as a simple interface - in fact, a single window.
The designer can draw as many beautiful and user-friendly interface, but it will not be implemented due to technical limitations.
What to do?
Technologies must timely adapt to the requirements of the product, otherwise the product will have to adapt to the capabilities of the technology. Very often, the success of an interface redesign depends on the architectural and technological redesign. The project team should be ready for this.
The product interface for the client is the product itself. But for a development company, the interface is just the tip of the iceberg, behind which the technologies, processes, structure and other kitchen features are hidden. The user does not want and should not delve into them. But we must not forget that every process and every decision can improve or worsen the product interface, and therefore the product itself.
Much depends on the quality of designers' work, but design is only part of the product. In this article I want to share my opinion on what problems can lead to a bad design besides the design itself, as well as why a good design starts much earlier than drawing buttons and pictures.
In software development, the same situation is often found: people align pixels, redraw illustrations, change user scenarios, and interface. But at the same time they have problems in the work of key functions, inconsistency of departments, a name that is incomprehensible to customers, strange advertising and a lot of other problems.
')
Below are typical problems that I have observed in my (and not only) practice, leading to poor design, as well as advice on what to do with them.
Problems with the commercial part
How much will the product cost? What payment methods are planned? What set of options will each tariff include? What data can I do without at the stage of purchase or registration? Do I have to attach a bank card to activate the trial period? Usually these issues are resolved at the very top, consistent with the fin. workers and designers come as a given. No matter how ideal the bank card binding interface is, but if this is done during registration, the service will lose a lot of customers.
What to do?
Questions of tariff policy and finance should be resolved as early as possible, in conjunction with ux-designers and tested with the prototype service. The selection stage and the purchase of a product should not be perceived separately from its use. Problems in this part may also affect the interface.
Marketing problems
Who are our customers? What they are not satisfied with the status quo? What are the most important product features? What are people willing to pay for? What features to include in the first version?
Anyone often seeks answers to these questions, but not the one who should. Designers and programmers are told: “We now have a lean approach, here's an idea for the product and a book for the evening. Tomorrow you will go to do customer development, then draw a design and make a prototype. ” As a result, it may turn out that the functions of the product will be convenient to use, but not those that are needed. And those that are needed are hidden far inland and are made according to the residual principle.
What to do?
It is the product manager and marketer who must find the answers to these questions as early as possible. Not without the help of colleagues, of course, but one should not let the process take its course. Without this information, designers will be guided by their own opinion, or they will conduct research on their own, but designers do not benefit from this, since they will be engaged not in the business, business, since he risks not getting what he expects. Methods of market research and market niche can be taught, but this is a separate science and a couple of start-up master classes can not do here.
Project Management Issues
Time is always not enough and you need to quickly cut the product. The design will go to work without usability testing. The analyst, looking at the layouts, will write business requirements, and the developers, without waiting for the requirements, will start programming. As a result, the product will turn out far from what was expected, with a bunch of functions, but with a much larger bunch of bugs.
What to do?
No need to rush to write the code as soon as the first version of the design appeared, and even more so when there is no design yet. This is most critical in new products and niches, when there are neither decent counterparts, nor their own data on user behavior. Everyone knows that the cost of making changes to a project is minimal at the beginning and maximum at the end, but for some reason they forget about it when it comes to business.
Problems in the org. structure and business processes
Even the simplest products can have several channels of interaction, different stages and stages at which the client is located. At each stage, the client interacts with different departments, people and technologies. When the processes of the units are confused, and the interaction is not established, the interface will also be complex and confusing.
What to do?
Before you automate and “digitize” business processes, they need to be simplified. So, the principle of a single window in state structures first demanded reorganization of processes within departments and only then was implemented as a simple interface - in fact, a single window.
Problems with the feasibility of functions
The designer can draw as many beautiful and user-friendly interface, but it will not be implemented due to technical limitations.
What to do?
Technologies must timely adapt to the requirements of the product, otherwise the product will have to adapt to the capabilities of the technology. Very often, the success of an interface redesign depends on the architectural and technological redesign. The project team should be ready for this.
The product interface for the client is the product itself. But for a development company, the interface is just the tip of the iceberg, behind which the technologies, processes, structure and other kitchen features are hidden. The user does not want and should not delve into them. But we must not forget that every process and every decision can improve or worsen the product interface, and therefore the product itself.
Source: https://habr.com/ru/post/316116/
All Articles