Hello everyone! My name is Artem Suslov and in this article, I want to tell you about the design review process that we have set up at Playdex. We are building a hub for players who play play-to-earn crypto-games mainly from Asian countries.

It is difficult to assume who will read this article — experienced IT professionals or newcomers to the field, but in any case I want to bring a few concepts that will make this material more accessible.

• Production (prod) — what the user sees when they go to the site.

• Test stand — an environment in which final tests are conducted before deployment to production.

• Pull request (PR) — a function with which a developer can deploy or change something in the project without affecting the rest of the code. The pull request goes through review, after which it is sent to the test stand and then to production.

• Preview — a viewing mode to test how correctly the feature is deployed.

When I came to the product and passed the first layouts to the layout, I had to experience unpleasant emotions after seeing the result. Colors, typography, margins, component behavior differed significantly from what was in the layouts. Something had to be done about this and the expected idea of implementing a design review process arose.

This process is useful for the future of the whole team, as it improves communication between developers and designers.

At first there was a noticeable slowdown in feature releases, as it took time to adapt to the new process. However, after a month the speed returned to approximately the same level, and the quality improved, as all participants did their work responsibly and understood the value of design.

To make our product look consistent and unified, we started by creating a component library in Figma and transferring them to Storybook. The priority was buttons, inputs, and pagination as they were most commonly used in the current interface.

Storybook is a service for developing reusable UI components. It allows you to interact and test them before deploying to production. It is important to note that when a component is changed in Storybook, it will also be changed in production after deployment. This initiative belongs to our ultra-frontend developer — Misha, for which he deserves huge respect.

Before starting development, I create a task in the task tracker and attach links to the interactive prototype, step-by-step scenarios for desktop and mobile, and components used.

You can also describe all your ideas and the behavior of components when scrolling, adaptability. If there are animations — it is desirable to attach references. In general, try to answer all possible questions of the developer in advance.

But if necessary — we hold a meeting with the developer who is doing this task and discuss the nuances. Perhaps the implementation of animation in this task may take a long time, and since we work in a startup — the priority is the speed of development. So everything that was not done in the current task — we put in the backlog. The main thing is to do this immediately, otherwise it will be difficult to remember later what was not done.

After the first iteration in the pull request, the developer notifies that it is possible to start the design-review. For preview, we use Vercel.

Vercel is a cloud platform for hosting frontend applications and static websites. One of the coolest features is the ability to leave comments on a specific component or part of the interface in the preview.

Thanks to this, there is no need to communicate in private chats (which is not always possible) and all other developers see the comments.

Logic and edge cases. Example: there is a Discord account joining flow on the website. What if a person goes to the account joining page but then clicks the “Cancel” button? In this case, a relevant modal window should be provided.

Adaptiveness and padding/margin sizes. This is done with the help of the developer mode. Here, the designer needs to know at least the basics of HTML/CSS in order to make any necessary changes and attach a screenshot to the comment.

Component states: hover, active, disable, focus.

Typography. I check this with the Font Ninja plugin. Very convenient tool.

Colors. Either by eye or through the developer mode.

Content. Are the texts in the interface written correctly and nothing is missed.

After the comments have been sent and the changes have been made, the pull request goes through a second iteration of review. And it is desirable that it be the last. But often it does not always work out, either because I will miss something or decide to change something after previewing the preview, or the developer will do something different than what is indicated in the comments. But we try :)

It is also necessary to understand that since we are working in a startup, speed is our priority and often some things that we would like to implement now go into the backlog.

We have made several changes to the code online through screen sharing several times. The quality of the output is better than leaving comments, but such calls take a lot of energy, especially with a lot of edits.

I realized that this method is best used when deadlines are burning and work needs to be done on time.

• To compare the result of work in the editor and in production;

• To improve communication between designers and developers;

• To understand the result of your work;

• To improve HTML/CSS skills. To understand development limitations.

Thank you for reading this material. I hope it was useful!

Subscribe to my Telegram channel. It is mostly on Russian, but you can find useful staff that I post there!