Design well, follow through: what makes a design last

It all starts with the strategic stakes

Before talking about components, you have to talk about what the product needs to achieve. Strategy dictates the method, not the other way around.

A product that needs to open up to new customers needs a highly modular system. A product for non-specialist users needs an interface that guides and explains. A product built by a remote team needs flawless documentation.

At Adcleek, the goal was to let people who aren't digital marketing specialists order campaigns on their own. That constraint shaped everything else: how much guidance to give, how much room to leave for explanation, and the consistency required from one screen to the next.

A designer who doesn't understand these stakes produces beautiful mockups that answer the wrong question. So I start every project there, and I come back to it with every trade-off.

A design system before the screens

A design system is the set of rules and reusable elements that make up a product: its colors, text styles, spacing, and components. I build it before designing the first page, for three reasons.

Consistency. When every button is an instance of the same component, you can't end up with two nearly identical buttons. The product looks more polished because it really is.

Speed. A new page is assembled from what already exists. You don't redraw, you compose.

Maintenance. Changing a component updates every page that uses it. It's the only way to evolve a product without degrading it.

At Adcleek, the design system was integrated into Storybook, the tool where developers document and test their components. The result was measurable in the team's day-to-day work: fewer consistency errors and faster development. At Nanotera, the design system is what allowed a platform bringing together very different functions to still read as a single product.

Components designed with their states

A component isn't just its default appearance. I design it from the start with everything it will go through in production:

• its variants: primary, secondary, or link button;
• its states: default, hover, disabled, error;
• its edge cases: what happens when the text is twice as long, when the image is missing, when the list is empty;
• its mobile version, when the structure changes and not just the size.

These questions always come up eventually. If the designer hasn't answered them, the developer decides alone, while coding, without the big picture.

Variables rather than values

I never enter a color or a text size by hand. Every value goes through a variable.

I keep these variables few: a short palette, a type scale, a spacing scale. They also carry the product's variations. With a mobile mode and a desktop mode for sizes and spacing, the same component adapts on its own when the mode changes. With a light mode and a dark mode for colors, a dark theme comes down to adjusting a few values, without touching a single screen.

The benefit goes beyond the designer's comfort. These variables are exactly the ones developers use in the code. When design and code share the same names and the same values, there's nothing left to translate, so there are no translation errors.

Prototyping to decide

A static mockup shows what a screen looks like. A prototype shows what happens between two screens, and that's where most problems are.

I prototype the key flows before development, for two purposes. To test with real users and watch where they hesitate. And to align the team: a prototype ends debates about interpretation, because everyone is looking at the same thing.

On Xola, the booking flow had to handle multiple guests and multiple payment methods, on desktop, mobile, tablet, and in-store kiosks. You can't validate that kind of flow with static images.

Clear documentation for developers

It's the most neglected practice, and the one with the biggest effect on the final result.

Good documentation answers the questions a developer will have when I'm not around:

• What is this component for, and when should you use a different one?
• What are its properties, and which values are allowed?
• How does it behave when the screen shrinks or the content varies?
• Which rules allow no exceptions?

I put it where it will be read: in the component's own description, not in a separate document nobody opens. And I use the same names as the code. If the component is called “Card · Project” in Figma, it should have an equivalent name in the code. Two different vocabularies produce two versions of the product.

Staying close to developers

Documentation doesn't replace the relationship. The best projects I've worked on are the ones where design and development moved forward together.

At Adcleek, I took part in planning poker sessions and technical discussions. That's where I learned why some ideas that are easy to design are expensive to build, and how to find solutions that fit the real constraints.

On Xola, the team was spread across France, the United States, and India. Closeness couldn't rely on being in the same place. It relied on regular communication and on deliverables that left nothing to guesswork.

Staying close to developers also means accepting that a technical constraint can change the design. A design that can't be built in the time available isn't a good design.

Follow-through, in three stages

Designing is only half the job. The other half is follow-through, and it happens in three stages.

1. Follow through to production

Until the product is live, nothing is finished. I do the design QA: I compare what was built with what was designed, screen by screen, state by state. I log the gaps, and I separate the ones that need fixing from the ones that are good compromises.

At Nanotera, this follow-through was fully part of my role, from specification to QA of what was built. It's what ensures the original intent reaches the user intact.

2. Follow through after launch

Once the product is live, assumptions become testable. I look at how it's actually used, and I gather feedback.

At Adcleek, analyzing the app's data revealed specific areas for improvement in navigation and in access to key features. User feedback mechanisms were then put in place to guide what came next. A product that stops listening to its users after launch ages very quickly.

3. Maintain the design system

A design system is never finished. Without maintenance, every new page adds its own small exception, and the library turns into a catalog of special cases.

Three rules protect it:

• a clearly identified owner, who has the right to refuse an exception;
• an entry rule: a new element only joins the library if it's used in several places;
• a regular audit, to catch hand-entered colors, detached components, and duplicates before they multiply.

The mistakes I see most often

These practices seem obvious once they're written down. In reality, four mistakes keep coming back.

Building the design system at the end. You design the screens, then “tidy up” by creating components after the fact. The system then inherits every inconsistency from the screens instead of preventing them.

Creating too many variants. A design system with forty shades of gray and twelve button sizes doesn't help anyone choose. Constraint is a strength: the fewer the options, the more consistent the product. When in doubt, I remove a color rather than add one.

Documenting for yourself. Documentation written in the designer's vocabulary, stored somewhere developers never look, is useless. It has to be written for the person who will read it.

Treating handoff as the finish line. This is the most expensive mistake. Approved mockups are only a promise. What users see is what was built, and the gap between the two only shrinks if someone takes care of it.

The checklist I apply to every project

• The strategic stakes are stated and shared before any mockup.
• Colors, text, and spacing all go through variables.
• Every repeated element is a component, with its variants, states, and edge cases.
• The key flows have been prototyped and tested.
• Every component is documented where it's used, with the same names as in the code.
• Developers were involved before the design was finished.
• Design QA was done before going to production.
• Real usage is observed after launch.
• Someone owns the design system.

None of these practices is spectacular. Together, they make the difference between a design that impresses in a meeting and a product that holds up over time.