Problems with design review

Hi, my name is Vika, I manage the product design department, but since this is not an article for an HR brand, but my thoughts, we will omit its title. I read an article by Alexander Kuznetsov about design review, and decided to supplement it with my experience and the experience of the teams I have worked with.

Design review is a wonderful process that can involve a designer, UX writer, and DS designer alike. But there are a couple of issues that can't be ignored.

Problem #1 – Time to Market

At the design review stage, when it is conducted after testing or during, the designer can find minor inconsistencies with the layouts. Minor by business standards. It is quite difficult to defend the correction of such inconsistencies – on the one hand, there is a question of money and deadlines, on the other – about managing attention, beauty, compliance with the UI kit, ToV and other important things. A designer with a high level of influence can block the rollout of such a feature until the fix is ​​made, but such a situation is an exception to the rule. Often, a feature is rolled out with visual discrepancies, and additional bugs are introduced, which for the same reason can have a low priority – there will always be something more important than the indents between blocks. The circle closes, the design debt grows.

Problem #2

If development has not tried to comply with pixel perfect and ToV before implementing design review, it means that it is not interested or does not understand the value. Selling, explaining and teaching is quite a challenge. Developers’ dissatisfaction with designers is a common occurrence, which negatively affects work, so we conduct a satisfaction survey every 3 months. To the item “What issues bother you in the processes between development and design?” 90% of developers answered “I do not understand why I should comply with pixel perfect.” The level of awareness may vary from team to team, but I highly recommend conducting such a survey – perhaps there are questions for you too.

What to do?

For the first problem, we implemented the “pre-review” process – this is the fastest possible check of the layout at the stage when the feature is still in development. Not the entire flow and logic are checked, but the components and layout of screens and blocks. There is no need for templates to fill out, separate tasks, and so on – the process takes place in a personal message or in a thread between the designer and the developer. For this, we created the “Ask the Designer” channel in Mattermost. From experience, such a process takes no more than 15 minutes, but reduces the design review process by 50% percent, and also allows testers to relax a little. As a result, the user sees the very text with the very hyphenation that the designer intended, the feature is not delayed and, in general, everyone is happy.

There is no universal solution for the second problem. A heart-to-heart talk over a bottle of beer, a couple of articles from the Internet on the topic of pixel perfect, or a series of presentations for development that clearly show the dangers of systematically ignoring layouts will help. We went down the latter path because beer did not help.

In conclusion, design review is necessary, important and has high value, but it should not turn into a bottleneck. Each process should be optimized for the team, promptly responding to problems. And thanks to Alexander for the article.