VMTech
Discuss a project →
← All capabilities
PRODUCT & GROWTH · 03

UI Design

A beautiful mockup dies in the second week of development if it has no states: an empty list, a long name, a failed load and text in three languages of different lengths.

Discuss a project
FROM MOCKUP TO SYSTEM

How a screen becomes a reusable component

Every element goes the same route — otherwise in six months the product has five different buttons.

design.vmtech.rs
Component: order card
LIVE
reused
Grid and typography 4 px scale
Colour and contrast AA · light + dark
States 6 states
Three languages sr · en · ru
A component in the system in the library
Alive in code reused
FROM MOCKUP TO SYSTEM
  1. Grid and typographyThe type scale, spacing and heading rules come first — structure, not decoration
  2. Colour and contrastThe palette is checked for contrast and works in light and dark themes at once
  3. StatesEmpty, loading, error, long text, disabled — what usually surfaces only in code
  4. Three languagesSerbian and Russian strings run longer than English — the layout accounts for it
  5. A component in the systemThe element enters the library with usage rules instead of staying a picture in a file
  6. Alive in codeThe developer assembles new screens from ready parts without re-approving every button
A FAMILIAR PICTURE

What happens to the design after six months

Design as a pile of pictures

  • The product has five blues and four button sizes — every screen was drawn separately
  • A new screen needs a designer, because there is nothing to assemble it from
  • A long product name breaks the card, and that is discovered in production
  • The dark theme looks like the light one with inverted colours
  • Small grey text on a grey background is legible only on the designer's monitor

Design as a system

  • Colours, sizes and spacing are tokens — they cannot be “accidentally” changed on one screen
  • A new screen is assembled from existing components in hours, not a week
  • The edge cases are drawn in advance: empty, many, error, a very long name
  • The dark theme is designed on its own terms, with its own contrast values
  • Contrast is checked against a standard rather than by eye in perfect conditions
SCOPE OF WORK

What the UI work covers

Visual direction

Two or three directions on one real screen — the choice is made on content, not on abstraction.

Typography

A type scale, weights, line heights and rules for both Cyrillic and Latin.

Palette and themes

Light and dark as two proper schemes rather than an automatic inversion.

Component library

Buttons, fields, tables, cards and notifications — with every state and usage rule.

Product screens

Key pages at three sizes — phone, tablet and desktop — with real copy.

Icons and graphics

One set at a single stroke weight, without mixing styles from different sources.

Accessibility

Standards-based contrast, a visible focus ring, thumb-sized targets and legibility when zoomed.

Handover

Tokens, spacing and component behaviour in a form that transfers to code without guesswork.

HOW IT LIVES

What a design system is made of

TokensColours, sizes, radii and shadows as variables shared by the mockup and the code
ComponentsElements with all their states, not only the happy path
Usage rulesWhen each component belongs — so a new screen is not reinvented
Grid and responsivenessHow blocks behave as width changes is specified, not left to the front-end
Interface copyTone, label length and error wording are part of the system, not an accident
Verification in the browserBuilt screens are checked against the design on real devices, not just in the editor

The source design files and the component library are handed over with the project: a design system has to survive a change of contractor.

QUESTIONS

What people usually ask

We just want a redesign. Why a system?

If the product is five screens and will not change, a system is genuinely overkill and we will say so. It pays off where there are dozens of screens and new ones keep coming: without shared rules every next screen costs like the first, and the product slowly stops looking like one thing.

Can we take a template and adapt it?

Sometimes yes — for an internal panel where speed matters more than distinctiveness. But a template carries someone else's decisions: its grid, its typography, its component logic. If the product faces customers and should look like yours rather than like another template, building your own from the start is cheaper.

Who designs error states and empty screens?

We do, and it is part of the work by default. An empty screen is not “nothing here” but the place where a person is told what to do first. An error message is not an apology but an instruction. If they are not designed, they appear in code as grey text reading “No data”.

Is a dark theme extra work?

It is, but not double. If the palette is described with tokens from the start, a dark theme is a second set of values plus a contrast check, not a redraw of every screen. It costs most when added to a project where colours were hand-set on each element.

What do developers receive?

Mockups with documented tokens and spacing, a component library with states, and rules for behaviour as width changes. On top of that we compare the built screens against the design in the browser — that step usually catches the discrepancies that would otherwise reach release.

Related capabilities

UX Design What happens and in what order iOS & Android The interface on a small screen WEB development Where the system becomes code Our projects How it looks in production

Let’s apply this capability to your project

We define the challenge, dependencies and a realistic delivery plan.

Discuss a project