"Rabbit Hole". UX designer in the product team
I am a UX designer and have always worked alone. But last year everything changed: on my birthday I had an interview in the ISPsystem and got into the grocery team. I had to delve into the new, learn to live on the screen and argue with the harsh programmers (constructive!). Now the design processes have settled down, I myself ask the guys about honest criticism, and the developers use my prototypes as TK. More about this - under the cut.
I had two years of designing interfaces, a broken Axure, and the feeling that in Irkutsk I would hardly find an interesting job. I designed websites and portals, sometimes I was distracted by SEO and usability audits. At the same time she wrote texts for websites and articles: about sprinklers and drenchers, gas holders and subtleties of slate installation.
Every day this work alienated me from the goal of designing complex interfaces and solving non-standard tasks. I was already desperate and began to look closely at other classes, but in December 2017, I suddenly found myself at an interview in the ISPsystem. I passed it and after a few days I started working in a team that designed a new version of ISPmanager, the most popular product of ISPsystem.
User research, market analysis, statistics collection - this is the beginning of the work on the product. I will not describe this stage, since the article is not about that. But if you're interested, you can easily find themed holivars in Habré.
In our company, the designer starts working on a prototype several months before the formation of the product team. First, he thinks over the information structure of the product and transfers the results to mind map.
Based on these data, prepares the first prototype in akshur. So far it has been worked out in general terms: there are most of the future pages, the main functionality and basic interrelations between sections are indicated. The elements common to the whole prototype are partially thought out: layouts, cap, basement, and the appearance of modal windows.
After this, the most interesting begins: collecting the team and working together on the product. The first time I was in a state of small shock. I understood that it was necessary to organize work with developers so as to simplify the life of each other and increase overall efficiency. I imagined how to do this: colleagues shared their knowledge, I read articles on the topic and studied the histories of other companies. But my practical experience came gradually. I'll tell you in order.
Without a productologist, the life of a pixer is complex and full of hardcore. We work quite closely: at the beginning of each sprint we gather and discuss which parts of the prototype should be worked out in detail for planning. I fill it with a car of questions: why should this element work this way and not otherwise? What is important for a person in this section?
Profit from communication with the productologist is huge. When I find answers not in Google, but for a person who perfectly knows the product, I easily get to the point. And it helps to make the most rational decisions for the product.
Product scientist explains how a new feature should work.
Be sure to think of possible states. What happens if there is only one row in the table? If there is not a single row, is the table itself needed? What to show to the user if the screenshot of the site is not loaded? Such moments may seem trivial, but it is from the small things that a positive user experience is being formed, isn't it?
By the end of the sprint, the prototype is overgrown with details and becomes interactive: you can click on all the links, follow the path of creating a new entity, see how dynamic elements will look like when hovering. I’m sending the finished prototype to a product specialist for review. Often he has small remarks, so the discussion is held a few days before the end of the sprint: this is how I manage to make edits before planning the team.
After the product manager has approved the prototype, the team is going to a general display. This meeting has several goals: to introduce the developers up to date, to once again check the prototype with a fresh look and find a compromise on controversial issues.
The controversial issues in the prototype - a separate pain UX-designer. It happens, you come up with a solution to a complex interface problem, and the developers say: in order to implement it, you have to spend six months. What to do? If the deadlines cannot be shifted, then the solution should be temporarily simplified. At such moments it is important to remember that it is better to give the user a working product faster than six months later to bring the interface to a made-up ideal.
This is the section in the “ideal” version of the prototype.
Developers will make the shortened version about three times faster.
It's time to mention the basic principle of design: constantly rework the prototype, ask others about honest criticism, analyze the results and adequately apply in practice.
After the final show, I make another iteration of the edits, and the prototype goes into development.
On the first working day, I learned that there is one visual designer for all the products in the company. I used to think that one such specialist is involved in the development of each product, or even more. Just before that I did not hear about the existence of a design system and atomic design.
Briefly about the essence of atomic design. Any product item: button, link, input field is an atom. Each atom has its own requirements, rules of behavior and appearance. All this visual designer describes in the design system. Based on the developed micro-components and rules, the mixer automatically arranges the product pages.
Designer's face when you ask him to draw an icon for DHCP
When new complex elements appear in the prototype, I think through the logic of their work and behavior to the maximum. The designer helps with the visual part: modifies the component so that it is concise and harmoniously fit into the design system.
Atomic design has accelerated our work, put in order the processes and saved a lot of nerve cells. If you have a large grocery team, then perhaps this approach will be useful for you.
Sometimes the task puts me in an absolute dead end. The more I think about the decision, the more the eye becomes blurred and the brain works worse. In such cases, I choose one of two ways. The first is to be distracted by another task, and return to the problematic issue later. The second is to go to the head to play ideological tennis. I use this option when the deadlines burn out.
I'm not sure that the concept of "ideological tennis" exists in the world. Most likely, we invented it, so I will explain the essence. I take a piece of work that caused difficulties, and bring it to the supervisor. Important: I don’t go at all without ideas. Ideally, I show a couple of options, even if I don’t like them.
In response, I receive criticism and thoughts about how to solve the problem. Usually, among my ideas, the manager finds interesting and tells how it can be developed. I often see flaws in these decisions, correct them and, along with my own criticism, again throw the ball over the net.
From the outside, it looks like a professional dispute, but in fact it’s a brainstorm, and it helps to quickly generate a good result.
UX designer in a creative crisis
The UX-design department is developing rapidly: we now employ 9 people. For Irkutsk, this figure is just cosmic :) Growth was not painless. It was difficult to search for new employees and train them, it is not easy to build processes in a team. Those who deal with UX are probably familiar with these issues. If you are interested in our experience in solving them - ask in the comments, I will be glad to answer.
I had two years of designing interfaces, a broken Axure, and the feeling that in Irkutsk I would hardly find an interesting job. I designed websites and portals, sometimes I was distracted by SEO and usability audits. At the same time she wrote texts for websites and articles: about sprinklers and drenchers, gas holders and subtleties of slate installation.
Every day this work alienated me from the goal of designing complex interfaces and solving non-standard tasks. I was already desperate and began to look closely at other classes, but in December 2017, I suddenly found myself at an interview in the ISPsystem. I passed it and after a few days I started working in a team that designed a new version of ISPmanager, the most popular product of ISPsystem.
Product start
User research, market analysis, statistics collection - this is the beginning of the work on the product. I will not describe this stage, since the article is not about that. But if you're interested, you can easily find themed holivars in Habré.
In our company, the designer starts working on a prototype several months before the formation of the product team. First, he thinks over the information structure of the product and transfers the results to mind map.
Based on these data, prepares the first prototype in akshur. So far it has been worked out in general terms: there are most of the future pages, the main functionality and basic interrelations between sections are indicated. The elements common to the whole prototype are partially thought out: layouts, cap, basement, and the appearance of modal windows.
After this, the most interesting begins: collecting the team and working together on the product. The first time I was in a state of small shock. I understood that it was necessary to organize work with developers so as to simplify the life of each other and increase overall efficiency. I imagined how to do this: colleagues shared their knowledge, I read articles on the topic and studied the histories of other companies. But my practical experience came gradually. I'll tell you in order.
The product manager, he is the designer’s comrade
Without a productologist, the life of a pixer is complex and full of hardcore. We work quite closely: at the beginning of each sprint we gather and discuss which parts of the prototype should be worked out in detail for planning. I fill it with a car of questions: why should this element work this way and not otherwise? What is important for a person in this section?
Profit from communication with the productologist is huge. When I find answers not in Google, but for a person who perfectly knows the product, I easily get to the point. And it helps to make the most rational decisions for the product.
Product scientist explains how a new feature should work.
Be sure to think of possible states. What happens if there is only one row in the table? If there is not a single row, is the table itself needed? What to show to the user if the screenshot of the site is not loaded? Such moments may seem trivial, but it is from the small things that a positive user experience is being formed, isn't it?
By the end of the sprint, the prototype is overgrown with details and becomes interactive: you can click on all the links, follow the path of creating a new entity, see how dynamic elements will look like when hovering. I’m sending the finished prototype to a product specialist for review. Often he has small remarks, so the discussion is held a few days before the end of the sprint: this is how I manage to make edits before planning the team.
Programmers: how to make friends with them and deliver the product on time
After the product manager has approved the prototype, the team is going to a general display. This meeting has several goals: to introduce the developers up to date, to once again check the prototype with a fresh look and find a compromise on controversial issues.
The controversial issues in the prototype - a separate pain UX-designer. It happens, you come up with a solution to a complex interface problem, and the developers say: in order to implement it, you have to spend six months. What to do? If the deadlines cannot be shifted, then the solution should be temporarily simplified. At such moments it is important to remember that it is better to give the user a working product faster than six months later to bring the interface to a made-up ideal.
This is the section in the “ideal” version of the prototype.
Developers will make the shortened version about three times faster.
It's time to mention the basic principle of design: constantly rework the prototype, ask others about honest criticism, analyze the results and adequately apply in practice.
After the final show, I make another iteration of the edits, and the prototype goes into development.
Visual designer: one for all
On the first working day, I learned that there is one visual designer for all the products in the company. I used to think that one such specialist is involved in the development of each product, or even more. Just before that I did not hear about the existence of a design system and atomic design.
Briefly about the essence of atomic design. Any product item: button, link, input field is an atom. Each atom has its own requirements, rules of behavior and appearance. All this visual designer describes in the design system. Based on the developed micro-components and rules, the mixer automatically arranges the product pages.
Designer's face when you ask him to draw an icon for DHCP
When new complex elements appear in the prototype, I think through the logic of their work and behavior to the maximum. The designer helps with the visual part: modifies the component so that it is concise and harmoniously fit into the design system.
Atomic design has accelerated our work, put in order the processes and saved a lot of nerve cells. If you have a large grocery team, then perhaps this approach will be useful for you.
UX Head
Sometimes the task puts me in an absolute dead end. The more I think about the decision, the more the eye becomes blurred and the brain works worse. In such cases, I choose one of two ways. The first is to be distracted by another task, and return to the problematic issue later. The second is to go to the head to play ideological tennis. I use this option when the deadlines burn out.
I'm not sure that the concept of "ideological tennis" exists in the world. Most likely, we invented it, so I will explain the essence. I take a piece of work that caused difficulties, and bring it to the supervisor. Important: I don’t go at all without ideas. Ideally, I show a couple of options, even if I don’t like them.
In response, I receive criticism and thoughts about how to solve the problem. Usually, among my ideas, the manager finds interesting and tells how it can be developed. I often see flaws in these decisions, correct them and, along with my own criticism, again throw the ball over the net.
From the outside, it looks like a professional dispute, but in fact it’s a brainstorm, and it helps to quickly generate a good result.
UX designer in a creative crisis
The UX-design department is developing rapidly: we now employ 9 people. For Irkutsk, this figure is just cosmic :) Growth was not painless. It was difficult to search for new employees and train them, it is not easy to build processes in a team. Those who deal with UX are probably familiar with these issues. If you are interested in our experience in solving them - ask in the comments, I will be glad to answer.