How to work with UX contractors? Experience messenger "Answer"
In March, we finished designing the interfaces for the Answer messenger. They sat down to write a case, began to recall and found that it was almost a reference example of how to work with an external contractor for UX-design. That is with us. And a very honest example like this, without pink ponies. It would be a crime to hide from the public those thoughts that we finally put into words. So the case will wait, but for now let's talk about working together.
Who should develop a new product interface, a full-time specialist in a team or an external contractor?
')
Our opinion is obvious. We are sure that the product turns out faster and better when external contractors work on it. No, not because the designer at the agency is cooler, in general, the degree of steepness of the specialists is about the same. And not even because it is cheaper, taking into account all the hospital, VHI and other corporate buns, this has never been an argument.
The thing is that the “customer-contractor” work format itself sets a certain quality standard. But let's move from general words to a specific example.
No matter how much you want to emphasize the importance of the UX-specialist, the reality is that the development of interfaces never starts from scratch.
Prior to working with us, “Answer” already had a lot of things. Namely:
Virtually product. Lacked only the visual component - interfaces. What will the messenger look like? How will all the functionality fit on the screen? Will it blow the brain to the unfortunate user? And in general, will it be possible to bring your bright thoughts through the interface? Because functions are functions, and the context of use is another story.
All of the above fits into the set of responsibilities of the UX-designer. The standard formulation of the problem with two variants of the development of events: staff the staff with its own designers or transfer the work to an external contractor. "Answer" chose the second option.
Quite briefly, the basic idea of ​​“Answer” can be described as follows. There are plenty of messengers on the market, they are not bad in themselves, but they solve by and large one task - to chat. It would be nice to turn a corporate messenger into a more powerful collaboration tool. First, add a hierarchy of users vital for large teams and setting up access rights. Secondly, work with orders for which the task manager is too cumbersome, and personal diaries are unreliable. Well, a lot more on the little things.
As it should be at the beginning of the work, a certain share of working chaos was attached to it. And yes, it survived until the end of the project and did not prevent the Answer from rolling out the release. But - back to the chronology of events.
The first key point of working with an external UX contractor is the delineation of areas of responsibility for the very essence of the product. Almost always the customer is responsible for it, and the contractor is to adopt the vision - it is not always easy. We could criticize individual decisions of “Answer”, but this criticism was strictly constructive and not beyond the scope of our area of ​​responsibility.
Such “acceptance” does not relieve the UX-team from the obligatory stage of analytics. We conducted four interviews with potential users. Is it a lot or a little?
As a result of a short analytics, a document appeared describing the risks of implementation. More importantly, we have criteria for evaluating the functionality that the customer wanted to implement.
Designers are familiar with this pain in the first third of the project, when the customer is already noticeably nervous about the "lingering" analysts, and we want to talk and record two thousand more moments. Do not do it this way. So how should it be?
We exhale, describe life situations and scenarios (no one has canceled the methodology), we hammer on perfectionism and begin to design.
We immediately agreed that the web version and the mobile application are two different interfaces. So you can connect two designers at once to speed up the process. But the product is one, you need synchronization.
Next - long hours of design. And the new risks that something goes wrong. The success of the project depends on the customer and the contractor. And the success factors are as follows.
We called each other two or three times a week and discussed intermediate results, including with the developers. We immediately received answers of the form “we will do this” or “not, this is unrealistic”.
The customer could immediately see the incarnation of individual “wishes” - it turns out to arrange this in the form of an interface, or the “feature” does not fit into the interaction context.
It only seems that two designers and one manager worked on prototypes. In fact, one way or another, five designers, three managers and a couple of general directors shared their knowledge.
For all we will not say, but at Pavlova ’s Dog , life is arranged in such a way that the work of each employee is visible to everyone else. There are formal reports, internal presentations, and a simple “listen, need advice” communication.
Such luxury can hardly be afforded in a team with one designer. We will not tire of boasting that in each of our projects we have the experience and knowledge of about ten tough interface specialists.
This factor is entirely in the hands of the customer. It happens that he just says "Yeah" to individual pictures. But it was better (and in “Answer” it was exactly like that) when the customer asks to tell about each button and reference. Not in the documentation to describe, but in a voice talk.
We will be extremely honest, this way of organizing collaboration is incredibly effective in any team in general, it doesn’t matter if there are contractors and contractors, or if everything happens in-house.
In general, if by the end of the project the manager does not want to go to the monastery, it means that he did not give it all to all 146%, as is customary in our country. Work conflicts are inevitable. Especially when it comes to technically complex products. Especially when all parties involved really want to achieve a result.
The programmer is fighting for at least the theoretical possibility of realizing all that the designer has invented. The designer with a gun in his hands defends the interests of the user. These are always disputes, but not always constructive.
Constructive add, however prosaic, contractual relations. We can not afford to just argue about something with the programmer, noting the hours worked in the task tracker and getting paid for it (forgive someone you wanted to offend). We need to maintain normal relations, meet the project framework, bring it to the end and do well.
And defend their decisions. And capitulate to the sound decisions of the customer.
Prototypes accepted. Product created. There is a closed testing.
This is an incredible success, in fact, and we are glad that there is some amount of our work in this success. The story does not end, ahead of testing, development, support.
By the way, about UX-support, we also have something to tell. But another time, on a different example and on a different platform, this is our last publication in the corporate blog on Habré. Thanks to all readers, look for us in social networks.
The main question of life
Who should develop a new product interface, a full-time specialist in a team or an external contractor?
')
Our opinion is obvious. We are sure that the product turns out faster and better when external contractors work on it. No, not because the designer at the agency is cooler, in general, the degree of steepness of the specialists is about the same. And not even because it is cheaper, taking into account all the hospital, VHI and other corporate buns, this has never been an argument.
The thing is that the “customer-contractor” work format itself sets a certain quality standard. But let's move from general words to a specific example.
Our role in "Answer"
No matter how much you want to emphasize the importance of the UX-specialist, the reality is that the development of interfaces never starts from scratch.
Prior to working with us, “Answer” already had a lot of things. Namely:
- development team;
- product vision (text description);
- knowledge of the market, strengths and weaknesses of competitors;
- conceptual ideas for detuning from competitors;
- a whole bunch of functional that would be good to implement;
- sober assessment of their technical capabilities and limitations.
Virtually product. Lacked only the visual component - interfaces. What will the messenger look like? How will all the functionality fit on the screen? Will it blow the brain to the unfortunate user? And in general, will it be possible to bring your bright thoughts through the interface? Because functions are functions, and the context of use is another story.
All of the above fits into the set of responsibilities of the UX-designer. The standard formulation of the problem with two variants of the development of events: staff the staff with its own designers or transfer the work to an external contractor. "Answer" chose the second option.
Starting point
Quite briefly, the basic idea of ​​“Answer” can be described as follows. There are plenty of messengers on the market, they are not bad in themselves, but they solve by and large one task - to chat. It would be nice to turn a corporate messenger into a more powerful collaboration tool. First, add a hierarchy of users vital for large teams and setting up access rights. Secondly, work with orders for which the task manager is too cumbersome, and personal diaries are unreliable. Well, a lot more on the little things.
As it should be at the beginning of the work, a certain share of working chaos was attached to it. And yes, it survived until the end of the project and did not prevent the Answer from rolling out the release. But - back to the chronology of events.
Who about what?
The first key point of working with an external UX contractor is the delineation of areas of responsibility for the very essence of the product. Almost always the customer is responsible for it, and the contractor is to adopt the vision - it is not always easy. We could criticize individual decisions of “Answer”, but this criticism was strictly constructive and not beyond the scope of our area of ​​responsibility.
Such “acceptance” does not relieve the UX-team from the obligatory stage of analytics. We conducted four interviews with potential users. Is it a lot or a little?
- It is catastrophically small to build on these introductory new product.
- Enough to test the vision of reality. The mechanism is simple: if the interview revealed no significant contradictions with our ideas, then the ideas are OK. If one of the four target interviewers did not understand what was being discussed at all, then trouble.
As a result of a short analytics, a document appeared describing the risks of implementation. More importantly, we have criteria for evaluating the functionality that the customer wanted to implement.
Let's draw already?
Designers are familiar with this pain in the first third of the project, when the customer is already noticeably nervous about the "lingering" analysts, and we want to talk and record two thousand more moments. Do not do it this way. So how should it be?
- Artist - make a willful decision and stop. It is too tempting to create an ideal TK and then, for any reason, poke a piece of paper: "we did not agree." This approach does not work.
- Customer wait patiently. Believe me, to grasp a new topic, even if it is not the highest mathematics, will not work in three days.
- All together - trust each other. The natural "lapping" comes at the stage of work-work, and now there is a high risk of "not converging to the characters."
We exhale, describe life situations and scenarios (no one has canceled the methodology), we hammer on perfectionism and begin to design.
Design
We immediately agreed that the web version and the mobile application are two different interfaces. So you can connect two designers at once to speed up the process. But the product is one, you need synchronization.
- Single list of scenarios.
- A single list of functionality.
- Manual control of our manager.
- Control by the customer.
- Communication between designers.
Next - long hours of design. And the new risks that something goes wrong. The success of the project depends on the customer and the contractor. And the success factors are as follows.
Constant communication teams
We called each other two or three times a week and discussed intermediate results, including with the developers. We immediately received answers of the form “we will do this” or “not, this is unrealistic”.
The customer could immediately see the incarnation of individual “wishes” - it turns out to arrange this in the form of an interface, or the “feature” does not fit into the interaction context.
Collective UX Mind
It only seems that two designers and one manager worked on prototypes. In fact, one way or another, five designers, three managers and a couple of general directors shared their knowledge.
For all we will not say, but at Pavlova ’s Dog , life is arranged in such a way that the work of each employee is visible to everyone else. There are formal reports, internal presentations, and a simple “listen, need advice” communication.
Such luxury can hardly be afforded in a team with one designer. We will not tire of boasting that in each of our projects we have the experience and knowledge of about ten tough interface specialists.
Get to the mice
This factor is entirely in the hands of the customer. It happens that he just says "Yeah" to individual pictures. But it was better (and in “Answer” it was exactly like that) when the customer asks to tell about each button and reference. Not in the documentation to describe, but in a voice talk.
We will be extremely honest, this way of organizing collaboration is incredibly effective in any team in general, it doesn’t matter if there are contractors and contractors, or if everything happens in-house.
Spores hoarse
In general, if by the end of the project the manager does not want to go to the monastery, it means that he did not give it all to all 146%, as is customary in our country. Work conflicts are inevitable. Especially when it comes to technically complex products. Especially when all parties involved really want to achieve a result.
The programmer is fighting for at least the theoretical possibility of realizing all that the designer has invented. The designer with a gun in his hands defends the interests of the user. These are always disputes, but not always constructive.
Constructive add, however prosaic, contractual relations. We can not afford to just argue about something with the programmer, noting the hours worked in the task tracker and getting paid for it (forgive someone you wanted to offend). We need to maintain normal relations, meet the project framework, bring it to the end and do well.
And defend their decisions. And capitulate to the sound decisions of the customer.
And what is the result?
Prototypes accepted. Product created. There is a closed testing.
This is an incredible success, in fact, and we are glad that there is some amount of our work in this success. The story does not end, ahead of testing, development, support.
By the way, about UX-support, we also have something to tell. But another time, on a different example and on a different platform, this is our last publication in the corporate blog on Habré. Thanks to all readers, look for us in social networks.
Source: https://habr.com/ru/post/333774/
All Articles