Design systems

Who it is for

Teams whose product has started to look and behave differently from one screen to the next, and teams about to build who want to start consistent.

• Teams building a first version who want tokens and components in place from day one, so new screens are put together from parts that already exist.
• Teams with a live product where every new screen is designed from scratch and the interface has drifted.
• Products with more than one surface, such as a web app and a mobile app, that should feel like one product.
• Teams in larger companies that need a system for one product line, built in their codebase with their engineers.

The problems it solves

• Twelve versions of the same button. Without shared components, each feature reinvents the basics and the interface drifts. A system gives every screen the same parts.
• A design file that does not match the code. A system drawn only in a design tool falls out of step with the product. Here the components are built in code by the people who designed them, so the two stay in step.
• Every new screen costs as much as the first. When nothing can be reused, nothing gets cheaper. With a system in place, new work is mostly assembly.
• Accessibility added late. Contrast, focus states, and text sizes are cheapest to get right once, in the components, rather than screen by screen.

What you get

• Design tokens for color, type, spacing, radius, and motion, named once and used in both design and code.
• The components your product uses, built in code with the states they need, such as hover, focus, disabled, loading, and error.
• Plain rules for using them: which component fits which job, and what to avoid.
• The product screens in the scope, built from the system.
• The designs and the source code of the system, yours once each deliverable is paid for.

Each case study on the work page ends with the visual system behind the product, which shows the kind of decisions a system holds.

How it runs

A design system is not a separate project that runs before the product. It is built with the product, from the screens that need it.

1. Start from real screens. The first critical workflow shows which components the product actually needs. Nothing is built in the abstract.
2. Set tokens and components once. They go into the design and into the code at the same time, from the first week.
3. Grow it with the product. Every new screen either uses an existing component or adds one on purpose.
4. Check it in use. The live link every Friday shows the system working inside the real product, not on a poster.

Price and timeline

A design system is priced as part of an engagement, not on a separate price list. Prices are in US dollars, with no tax added on top.

• Inside a build (Ship it). From $19,000 for four to six weeks. The system is set up for the screens in the scope and used across the whole release.
• For a live product (Grow it). From $9,900 a month, month to month. Setting up or cleaning up a system can be the one priority for a month or more.

Teams in larger companies can buy it as a company project, scoped in writing from $19,000. The written scope says what the system covers before work starts.

When not to hire Choie for this

• You need a design systems team, not a system. Running governance and contributions across many product teams for years needs a dedicated in-house team. Choie can set up the system for one product line and hand it to that team.
• The goal is a component library for its own sake. A system pays off when it serves a product people use. If there is no product to apply it to yet, start with the product.
• The product is about to be rebuilt. Put the system into the rebuild instead of retrofitting code that is about to be replaced.

Common questions