How I cut client project delivery time by 17%

Every new client project meant rebuilding familiar UI. Designers styled components in separate files; developers rebuilt them from handoff. I brought the patterns into a shared system both teams could use.

RoleI designed the shared system for iauro's client teams, from product audit through reusable components and documentation.
OutcomeThe shared system cut client project delivery time by 17%.

Problem

iauro designed and built products for clients. Designers kept separate project files, so familiar controls picked up new styles each time. A button in one app could look nothing like the button in the next.

That variation carried into handoff. Developers had to interpret specs and rebuild buttons, fields and modals for each project. QA then had more inconsistencies to catch, and delivery slowed.

We needed to ship faster without lowering quality as iauro took on more clients.

ButtonForm fieldModal Project A Submit Project B Built again Submit Project C Built again SUBMIT

Each client project had its own buttons, fields and modals.

Decision

I considered two options:

  1. Build a component library first

    It was quick to start and would let designers reuse UI right away. But it would leave handoff issues in place, and teams might interpret components differently.

  2. Build the system from a product audit

    It was based on patterns teams already used, gave design and code a shared reference, and could change as teams gave feedback. But it would take time to research and audit alongside client work.

A component library would have made UI easier to reuse, but it would not fix the handoff. I chose to audit real products first, so the system reflected patterns designers and developers already knew. The audit took time, and client deadlines kept coming.

Root cause

I reviewed the process with designers and developers. The same components were restyled in Figma, rebuilt after handoff, then checked again in QA.

Design Handover Build QA Delivery Custom stylesper designer Specs open tointerpretation Componentsrebuilt from scratch Inconsistenciesto catch Slower forevery client The same work repeated at every step, for every project

Design, handoff, build and QA all added repeat work.

The extra work landed on each group differently:

  • Designers: UI changed between products, similar components had to be rebuilt, and teams had no shared design language.
  • Developers: Custom designs took longer to build, code varied between projects and was hard to maintain, and timelines were hard to estimate.
  • Business: Slow delivery hurt client satisfaction, more clients made the workload harder to manage, and rework drove up costs.

Once I saw where the time went, I looked for a fix teams would use in real projects.

Design

  1. Map how teams work

    I mapped how design work moved, then spoke with designers and developers about the slow spots. I reviewed common design-system practices, but kept the decisions tied to our team's needs.

  2. Audit the existing UI

    I reviewed interface elements across client products and grouped the patterns that kept appearing. Those became our primitives: color, type, spacing and corner radius. Then I rebuilt the components teams used most.

Audit across client products ButtonsForm fieldsfound again and again Primitives Color Type AaAaAa Spacing 48162432 Radius Components Button Form field Modal

Repeated patterns became shared primitives and components.

I organized the Figma files around a core library. New client projects could start with those components instead of a blank file.

Core library Primitives and components Every new client starts here Client A file Client B file Client C file

Every new client file could start from the core library.

  1. Document and update the system

    Each component page showed when to use it and how to meet accessibility standards. Designers and developers had one guide to check before they built.

Foundations ColorsTypographySpacing Components ButtonForm fieldModal Components / Button Button Use it for the main action on a screen UsageAccessibilityCode Do Button One primary button per view Don’t BUTTON Restyle it locally Text contrast 4.5:1 WCAG AA

Each page showed the approved button beside a common misuse.

Teams found gaps as they used the system. I updated the components and docs, then made those changes available to new projects.

Team feedbackFrom both teams Update componentStates and variants Update docsUsage and accessibility Every project gets itOne source of truth and again

A change to the core library reached future client work.

Constraints

Client deadlines kept running while I built the system. I had to deliver useful parts early, then make sure the structure could support more projects.

Client projects Project Project Project Design system Research Audit Primitives Components Docs Iterate Client deadline

I built the system in phases without stopping client work.

Trade-offs

  • Building components too early. I mapped how teams worked first; otherwise, the library might have solved the wrong problem.
  • Shipping components without guidance. Without shared rules, each team could still interpret them differently.
  • Documenting it once and stopping. I kept the docs and components open to updates as teams used the system.

Outcome

Client projects started from shared components. Designers and developers used the same guidance, so handoffs needed less interpretation. QA had fewer inconsistencies to catch.

Before the design system With the design system 17% less delivery time