Design systems have a reputation for being a luxury for big companies with long roadmaps. In my experience they are the opposite: the tighter the deadline, the more a design system pays off.

On the Naqla driver app, three of us designed more than 40 screens in five weeks. On the Pirelli app, I designed more than 24 screens in two weeks. Neither would have been possible if every screen had been drawn from scratch.

Here is the small, practical kind of design system I build when time is short.

Build the System Before the Screens

Nielsen Norman Group's Design Systems 101 states the main benefit plainly: premade components let teams replicate designs quickly instead of reinventing them, and free people for harder problems like information architecture. It feels slower to spend the first days on buttons, inputs, cards and type styles instead of real screens. It is not. Once the parts exist, each new screen is mostly assembly, and decisions like spacing or button style are made once instead of forty times.

I keep the first version small: a type scale, a color palette, spacing steps, and the dozen components every screen needs. Everything else is added only when a screen asks for it.

Name Things the Way Developers Do

A design system is a shared language with developers, so I name components and colors the way they will appear in code and document their states: default, pressed, disabled, loading, error. On Naqla, turning requirements into interactive Figma prototypes on top of that system cut design-to-development handoff time by 30% and development iteration time by 25%.

Consistency Is a User Feature

The system does not only help the team. Users learn an interface faster when the same action always looks and behaves the same way. On a deadline it is tempting to make every screen a little special; a design system protects the product from that temptation.

Small, early and shared: that is the design system that saves deadlines.

Sources

• Design Systems 101, Nielsen Norman Group