“Down the rabbit hole”. UX-designer in a product team

I’m an UX-designer and used to work alone. But everything changed last year after I had an interview at ISPsystem on my birthday and joined their product development team. I had to meet a lot of new things, learn to live with Scrum and argue constructively with harsh programmers. Now design processes are settled down now, I always ask for feedback, and developers use my prototypes now. More about this is under the cut.

I had two years of designing the interfaces, using a cracked Axure, and feeling that I would hardly find an interesting job. I used to design websites and portals, sometimes I worked with SEO and provided usability audits. At the same time, I was writing texts for websites and articles about everything: sprinklers, drenchers, gas holders, and laying slate.

Every day this work put me off from my dream of designing complex interfaces and solving out-of-the-box tasks. I have already abandoned my hope and began to think of other career direction, but in December 2017 I came to an interview at ISPsystem. I passed it and in a few days, I started to work in a team creating a new version of ISPmanager, the flagman product of ISPsystem.

User research, market survey, and statistics collection — these is where a new product is getting started. However, I will skip this chapter. If you’re interested in learning more about it, you can go around Medium.

In our company, the designer starts to work on a prototype several months before the product team is created. First of all, you need to think over the product structure and put the results to the mind map.

Based on this data, a designer prepares the first prototype in Axure. So far it is worked out in general, and most of the future pages, the main functionality, and the basic interrelations between sections have already been specified. The elements common to the whole prototype are thought out thoroughly: layouts, block heading, footer, and the layout of modal windows.

And this is where the fun starts: collecting the team and collaborative work on the product. At first, I was shocked. I did understand that it was necessary to arrange my work with developers to simplify the life of each other and improve overall efficiency. I even imagined how to do this: colleagues shared their knowledge, I read articles, and studied the cases of other companies. But my hands-on experience came gradually, so I’ll describe these processes further.

The UX-designers life is hard without a product owner, our work is very interconnected. At the very beginning of each sprint, we discuss and plan which parts of the prototype should be worked out in details. I ask a plenty of questions: why should this element work this way and not the opposite? What is most important for a customer in this section?

It’s hard to overestimate the importance of communication with the product owner. I can find an answer, not in Google but from a person who knows the product perfectly, and finally, I get to the point easier. It helps to take the best for the product.

For me, it’s necessary to think over the possible states. What happens if there is only one row in the table? If there is not a single row at all, is the table itself needed? What do we need to show to the user if the screenshot of the website is not loaded? Such moments may seem trivial, but the devil is always in the details, isn’t it?

At the end of the sprint, the prototype is normally overloaded with details and it becomes interactive, so you can click on all the links, go through the path of creating a new entity, see what the dynamic elements look like when hovering. I give the final prototype to a product owner for review. Often there are small remarks, so the discussion is held in a few days before the end of the sprint. That way I have time to make edits before planning with the team.

After the product owner has approved the prototype, the team is going to the general demonstration. This meeting has several goals: to bring developers up to date, to check the prototype once again with a fresh perspective, and find a compromise on outstanding issues.

The outstanding issues in the prototype is a pain point of any UX-designer. There are times when you came up with a solution to a complex interface problem, and the developers say that it will take six months to implement it. What shall I do? If the dates cannot be shifted, then the solution should be temporarily simplified. In such scenarios, you need to keep in mind that it is better to provide a user with a working product faster than to bring the perfect interface six months later.

The basic design principle: constantly redesign the prototype, ask others about their honest feedback, analyze the results, and apply them practically.

After the final demonstration, I work through the other comments and edits, and the prototype goes to development.

During my first working day, I learned that there was only one visual designer for all products. I used to think that for development of each product you need at least one designer or even more. Before that, I haven’t ever heard about the existence of a design system and the atomic design.

In a few words about the essence of the atomic design. Every item of the product such as a button, a link, an input box is an atom. Each atom has its own requirements, rules of behaviour, and appearance. The visual designer describes all these things in the design system. And then the UX-designer needs to fit together the product pages.

When new complex elements appear in the prototype, I think through the logic of their work and behaviour. The visual designer helps with the visual part, modifies the components so that they fit into the design system.

The atomic design boosts the work, puts in order the processes, and saves from frustration. If you have a big product team, then perhaps this approach will be useful for you.

Sometimes the task can put me in a dead end. The more I think about the solution, the more “tunnel vision” I get and the old lemon is slightly clouded. In such cases, I choose one of two ways. The first is to be distracted by another task and return to the problem later. The second is to go to the Head of UX to play the “idea tennis”. I use it when the deadline is tight and I don’t have any solution yet.

I’m not sure that the concept of “idea tennis” really exists in the world. Most likely, we invented it, so I will explain the point. I took a piece of work that caused difficulties and bring it to Head of UX. The main thing: I shouldn’t come to him without any ideas. Ideally, I show a couple of options of how to solve a problem, even if I don’t like them myself.

I get a feedback and thoughts about how to solve the problem. Usually, among my ideas, the Head of UX finds something interesting and tells me how it can be developed. I often notice the flaws in these decisions, correct them, and pass the ball along with my own thoughts.

From the outside, it looks like a professional contest but in fact, it’s a brainstorming process which helps to quickly generate a good result.

Our UX department is developing rapidly, right now we have 9 people. But the growth was not so smooth. It was difficult to find new employees and train them to take the hit, it is not easy to build the team. Those who deal with UX are probably familiar with the process described above. If you want to find out more about our experience in solving such problems, ask in the comments, I will be glad to help.