David
Lossev

About product

Bricks is Avito’s internal low-code product builder that empowers teams to rapidly create, evolve, and scale digital products.

It enables the assembly of flexible, modular interfaces, advanced customization of UI and business logic, orchestration of process dependencies, and seamless data integrations — accelerating product delivery without building everything from scratch.

Bricks is Avito’s internal low-code product builder that empowers teams to rapidly create, evolve, and scale digital products.

Fast results and hypothesis testing.
The ability to quickly test hypotheses and add or edit your product's functionality

Ease of setup with drag-and-drop blocks.
You can change the structure of a page or product block in no time by dragging and dropping widgets within the product layout.

All versions are stored securely.
If you need to revert to a previous version, you can select it from the list stored in the product.

Old Design & Problems

The product was developed without product design involvement - developers created the interface on their own. This led to overload, weak navigation and broken user flow logic.

The product lacked visual hierarchy. The Bricks interface was visually flat: headings, containers, static and editable content, and interactive elements shared the same styles and spacing. This made it hard to distinguish what was primary or secondary, slowing users down and causing confusion, especially for new users.
Labels and descriptions were overly technical and unclear. Placeholder-style names (e.g., Widget Label, widgetName, MenuItem) didn’t convey the real purpose of components, making template editing confusing, error-prone, and hard to adopt without guidance.
The interface lacked feedback for user actions. Before the redesign, the system provided no visual confirmation for saves, publishes, or edits. The absence of status indicators or interaction feedback caused user uncertainty, repeated actions, and frequent support requests.

The product lacked visual hierarchy. The Bricks interface was visually flat: headings, containers, static and editable content, and interactive elements shared the same styles and spacing. This made it hard to distinguish what was primary or secondary, slowing users down and causing confusion, especially for new users.
Labels and descriptions were overly technical and unclear. Placeholder-style names (e.g., Widget Label, widgetName, MenuItem) didn’t convey the real purpose of components, making template editing confusing, error-prone, and hard to adopt without guidance.
The interface lacked feedback for user actions. Before the redesign, the system provided no visual confirmation for saves, publishes, or edits. The absence of status indicators or interaction feedback caused user uncertainty, repeated actions, and frequent support requests.

The product lacked visual hierarchy. The Bricks interface was visually flat: headings, containers, static and editable content, and interactive elements shared the same styles and spacing. This made it hard to distinguish what was primary or secondary, slowing users down and causing confusion, especially for new users.
Labels and descriptions were overly technical and unclear. Placeholder-style names (e.g., Widget Label, widgetName, MenuItem) didn’t convey the real purpose of components, making template editing confusing, error-prone, and hard to adopt without guidance.
The interface lacked feedback for user actions. Before the redesign, the system provided no visual confirmation for saves, publishes, or edits. The absence of status indicators or interaction feedback caused user uncertainty, repeated actions, and frequent support requests.

The product lacked visual hierarchy. The Bricks interface was visually flat: headings, containers, static and editable content, and interactive elements shared the same styles and spacing. This made it hard to distinguish what was primary or secondary, slowing users down and causing confusion, especially for new users.
Labels and descriptions were overly technical and unclear. Placeholder-style names (e.g., Widget Label, widgetName, MenuItem) didn’t convey the real purpose of components, making template editing confusing, error-prone, and hard to adopt without guidance.
The interface lacked feedback for user actions. Before the redesign, the system provided no visual confirmation for saves, publishes, or edits. The absence of status indicators or interaction feedback caused user uncertainty, repeated actions, and frequent support requests.

My role in product

I owned the full design responsibility for the product, leading UX improvements, interface unification, and the adoption of a product-focused design approach. I defined and ran design processes end-to-end, ensuring a cohesive user experience and aligning design decisions with product strategy and business impact.

I introduced a layout preview feature that enables instant result visibility, simplifying a core product workflow and eliminating the need to wait for production release to see the final layout.
The interface lacked feedback for user actions. Before the redesign, the system provided no visual confirmation for saves, publishes, or edits. The absence of status indicators or interaction feedback caused user uncertainty, repeated actions, and frequent support requests
The interface lacked feedback for user actions. Before the redesign, the system provided no visual confirmation for saves, publishes, or edits. The absence of status indicators or interaction feedback caused user uncertainty, repeated actions, and frequent support requests

I introduced a layout preview feature
that enables instant result visibility, simplifying a core product workflow
and eliminating the need to wait for production release to see the final layout.
The interface lacked feedback for user actions. Before the redesign, the system provided no visual confirmation for saves, publishes, or edits. The absence of status indicators or interaction feedback caused user uncertainty, repeated actions, and frequent support requests
The interface lacked feedback for user actions. Before the redesign, the system provided no visual confirmation for saves, publishes, or edits. The absence of status indicators or interaction feedback caused user uncertainty, repeated actions, and frequent support requests

8х

Faster interface creation

67%

Reduction in ramp time

72 → 94

Program NPS

Benchmarking

Since Bricks is a complex product with no direct competitors, there are no established market solutions to reference. Competitive analysis is therefore conducted through native patterns and approaches from adjacent and non-adjacent domains, as well as everyday user experiences. This requires deep contextual immersion for each problem and the development of non-standard, thoughtful solutions.

The end