Introduction

This article grew out of my lecture at Design Kommunalka 2025. Thanks to the organizers for creating such a unique festival for Samara and for giving me the chance to speak there.

Responsibility for the Outcome

Blaming development for an inaccurate implementation of a design is the last thing a designer should do. I am convinced that responsibility for how the final product looks lies entirely with us, as visual specialists.

To bring our ideas to life in production, we need to understand three things:

• How our ideas are designed
• How to write a technical brief for development
• How to communicate that brief to development

Let's go through these points one by one.

1. How Our Ideas Are Designed

In the end, a designer's job comes down to making sure the implementer, usually a frontend engineer, clearly understands the idea. But how do you reach that ideal if the designer speaks in abstractions and shapes while the frontend engineer speaks programming languages?

A better question is this: which of those languages is easier to understand?

I think it is code.

The language of abstraction is subjective. It is shaped by trends and visual taste, two chaotic factors that cannot really be systematized.

Code, unlike abstraction, is objective. It has a clear system, a set of tools, and most importantly an explicit body of knowledge you need in order to use it.

To speak the same language as a frontend engineer, a designer can get very far by understanding HTML↗ and CSS↗. HTML defines the structure of a web page. CSS styles elements, animates them, and adapts them to different devices.

By learning code, we also learn its limits. How blend modes affect browser performance, what constraints basic CSS animations have, how responsive behavior actually works. These and other browser limitations should already be in our heads when we make the first layouts.

You can learn programming in many places. For example, there is an excellent course by Zhenya Arutyunov, a designer who has been encouraging other designers to study code for a long time. I personally study programming at Purple School. It is a strong place with a systematic approach and a deep dive into each topic.

It is also worth following practicing specialists. On the Western market, a new role has been forming for several years now: the design engineer, someone who combines design and programming. I recommend following these people:

• Emil Kowalski↗
• Jhey Tompkins↗
• Jakub Krehel↗
• Rauno Freiberg↗

2. How to Write a Technical Brief for Development

A Figma file is just as much a technical brief as a branding brief. Once I understood that, my view of the work changed a lot. As designers, we are often demanding when clients describe a task. Now we have to take on the client's role ourselves.

Below are several tools we use when forming a technical brief, in other words a Figma file, for projects at Sirena:

• Working with Pages so the brief is easy to navigate

• A project design system so development can translate interface elements into code components and root CSS styles

• Screens arranged in user-flow order so the project structure, flows, and implementation priorities are explicit

• Semantic naming of screens where we rely on Figma Layout Autonaming

• Text descriptions of element behavior on screen

I want to highlight the last point separately. It allows you to explain the interactive side of a layout in much more detail inside static Figma screens.

The first use case is describing dynamic content. For example:

When a user signs in through Sports authentication, we assign a random nickname and place it inside the badge. It fits about 23 characters including spaces.

The second case is describing the behavior of an interactive element. Motion in web products deserves a separate article, so here I will only show one example: tooltip animation.

In these kinds of blocks we also rely on external tools: CodePen↗, a library of already coded animated elements, and Easing Graphs↗, a library of easings.

Inside our team, we introduced a checklist we use to double-check the main parts of a layout.

3. How to Communicate the Brief to Development

A handoff call for the layouts. On our side, we need to walk through the brief in detail and answer all follow-up questions. If necessary, we revise the layouts after the call. Sometimes feedback from teammates is exactly what makes the design better.

But communication does not end with the call. At every implementation stage, the designer should monitor the process as the owner of the idea.

Conclusion

The perfect layout does not exist, because there will always be things you have to compromise on. But if we understand code and communicate a technical brief well, we can get closer to the result we actually want.