Services Product design
Design systems
A shared library of components, tokens and usage rules that keeps design and code consistent.
At a glance
- Includes
- Tokens, component library, usage guidance and documentation
- Works with
- Your existing designs and front-end code
- Delivered as
- Design library and documentation, with coded components where agreed
- Starts with
- An audit of what your product uses today
Fit
Is this right for you?
Usually the right call when one of these sounds familiar.
Many buttons that are nearly the same
Each screen has its own version of each element.
Designers and developers disagree
The design and the build do not match.
Slow to add a new screen
Everything is made from scratch.
Several products, one brand
Each team ends up with a different look.
Not the right service? Only a few screens to design: UI design. Testing an idea first: Prototyping.
Scope
Scope and what you get
Each piece of work has a matching thing you receive.
- What we do
Interface audit
We collect and compare what the product uses today.
What you receiveA clear inventory
A list of the elements in use and where they differ.
- What we do
Tokens
Colour, type and spacing defined once and reused.
What you receiveReusable foundations
A set of tokens designers and developers both use.
- What we do
Component library
Components built with their states and rules for use.
What you receiveA library to build from
Components ready for designers and, where agreed, developers.
- What we do
Documentation and governance
How to use, change and add to the system, written down.
What you receiveGuidance that lasts
Documentation and a simple way to propose changes.
Use cases
Relevant use cases
Practical situations where this service is put to work. Open a card to see how it applies.
Consolidating an inconsistent product
One set of components replaces the many near-duplicates across a product.
- Audit of current elements
- One component for each need
- Plan for moving screens across
Aligning design and code
Designers and developers working from the same components and tokens.
- Tokens shared in design and code
- Component states documented
- One place to check how things work
Supporting several products
A shared system for teams and products that must look like one brand.
- Common foundations across products
- Room for product-specific parts
- Guidance on adding to the system
Sample use cases, drafted as placeholders. The Plethora team confirms the final list.
Process
How it works
Each stage is agreed with you as we go. Each shows what we do and what we need from you.
Audit
We doWe collect the interface elements in use and note where they differ.
You doYou give us access to designs and code, and tell us which products to include.
Define
We doWe set the tokens and decide which components the system needs.
You doYou review the foundations and agree what comes first.
Build
We doWe build the components with states, and document how to use them.
You doYour designers and developers try them on real screens.
Adopt
We doWe help the team start using the system and set up how it will be maintained.
You doYou decide who looks after it and how changes are proposed.
Quality
Quality and handover
How the work is checked, accepted and passed to you.
Based on real screens
Components come from what the product needs, not from a template.
States covered
Each component documented in its different states.
Design and code agree
Design library and code components are compared with each other.
Written guidance
How to use and extend the system, written for your team.
Tools
Tools and technology
Tools we use in delivery. We choose them to suit your team, and the list does not imply any partnership. Logos belong to their owners.
- Figma
- Storybook
- React
- TypeScript
- Miro
Engagement
Engagement and cost factors
Ways to work with us
A scoped project
A defined system, built and documented.
A team alongside yours
Our designers and engineers join your team.
Ongoing care
We keep the system current as the product changes.
What shapes scope, timing and cost
- Number of products and platforms
- Size of the existing interface
- Whether components are coded as well as designed
- Amount of documentation needed
- Number of teams who will use it
- How much help you want with adoption
Scope and cost are confirmed with you in writing before work starts.
FAQ
Frequently asked questions
Not always. It pays off when several screens, designers or products share the same elements. We say so if a smaller step would do.
If you want them. We agree in scope whether the system is design files, code or both.
Yes. We begin with an audit of what is in use.
You decide. We write the guidance so your team can, or we can continue to support it.
Keep design and code in step. Start with a conversation.
Tell us what you want to build and we will come back with next steps.
Talk to usRelated