Where I started
The platform already had buttons, badges and forms, but the earlier portfolio showed them separately from the screens they belonged to. The components did not always match the product, and the documentation left too much to interpretation.
I went back to the current platform frames and grouped the repeated patterns including instrument status, row actions, date filters, form fields and review feedback. I kept their meaning and rebuilt the parts that needed a shared definition.
One component, from the screen to the library
The status badge is a small part of the interface, but it carries a decision someone needs to act on. I checked it in the instrument list and the review pattern before defining the shared component.
- Start with its use
A user needs to tell an incomplete record from a rejected one, then find the next action. A colour alone does not explain the difference.
- Keep the meaning fixed
I kept five named states. The label and symbol belong to that state. Changing an icon must not turn a warning into a success.
- Check it in context
I checked the small text contrast and put the badges back into table rows. The row keeps the rule and recovery action beside the status.
- Leave a clear next step
The Figma states and browser example are documented. A production release still needs engineering review and checks in the product.
What I prioritised
| Pattern | Decision | Reason |
|---|---|---|
| Status badges | Keep five named states | The same record needs the same meaning in an upload and in a pool. |
| Buttons and fields | Agree sizes, labels and states first | These parts repeat across almost every task. |
| Tables | Document cells and the full table | Consistent cells still need rules for selection, filters and recovery. |
| Custom components | Add one only when the existing pattern cannot cover the task | A smaller library is easier to understand and maintain. |
Agreeing the foundations
I kept Inter, the cyan identity and the quiet surfaces already used in the platform. I separated the raw colour values from the roles they play. A button now uses action/primary, rather than a colour copied from another screen.
The bright cyan remains useful for identity and charts. White text on that colour measured 2.47:1, so I introduced a darker action colour. The new pairing measures 5.27:1. I also checked the small status labels and made the field boundaries more visible.
Foundations
Colour, type and spacing variables set the rules used by every part.
action/primary · space/12Atoms
Icons, buttons, badges and selection controls are the smallest reusable parts.
Icon → ButtonMolecules
A label, control and message become a field. Each part keeps its own responsibility.
Label + Input + MessageOrganisms
Navigation, tables and review panels combine those parts around a task.
Sidebar · Instruments tablecyan/700
#23758A
↓
action/primary
↓
Button · Primary
↓
var(--tt-action-primary)The same names in design and code
I used atomic design as an organising method. Tokens sit below the components. The table and navigation examples show how those components are combined.
Semantic colours alias the primitives in Figma. The CSS uses the same names, so a change has a clear place to live. The library documents one light theme. Compact and regular sizes cover the dense tables and roomier forms shown here.
Building the components
I built the controls first, then used them in tables, feedback and review patterns. Components expose the parts that should change, such as a label, size or leading icon. Status symbols stay tied to their meaning.
The library includes hover, pressed, focus and disabled states where they apply. Forms also cover errors and read only values. A disabled field cannot be edited. A read only value can still be read and copied.
Using the parts in a real task
I used the instrument table to check how the components worked together. The record ID, status, amount and next action stay in the same row. Amounts align right, while labels and recovery actions align left.
The table rules cover more than appearance. Filters combine, selection applies to visible results, and a failed request has a different recovery action from a search with no matches. The example below lets you try those decisions.
Writing the handoff
For each component, I documented its purpose, anatomy, available properties and behaviour. The specs also explain what happens when a value is long, a request fails or someone uses the keyboard.
The table and review dialog are documented as complete patterns. That keeps decisions such as selection scope, saved drafts and focus return beside the parts that depend on them.
What changed during the build
| What I found | What I changed | What I checked |
|---|---|---|
| White labels on the brand cyan were too faint. | Kept cyan for identity and introduced a darker action token. | The text pairing moved from 2.47:1 to 5.27:1. |
| A shared icon override could give a status the wrong symbol. | Tied each symbol to its status variant. | Compared all five badges and their table instances. |
| A save error looked like an invalid field. | Kept the filled reason and showed a separate request error. | Retried the save without retyping the reason. |
These checks cover the documented reconstruction.
Working with engineering
In the original project, I worked with the frontend lead on component states and implementation decisions as the system developed. The documentation needed to answer the questions that came up while building a feature, including what happened after a failed request.
For this reconstruction, the Figma variables and browser examples use the same token names. I checked the table and review form with the same sample content, then documented the differences between a data error, a failed save and a successful submission.
The reference uses Figma variables, shared text styles, CSS custom properties and semantic HTML examples. The colour checks follow WCAG contrast guidance, and the review dialog follows WAI focus behaviour.
Component specifications
Construction
Dimensions, spacing, type styles, token names and editable properties.
Behaviour
Keyboard input, loading, cancellation, failed requests and recovery.
Usage
When to choose the component, what to write, and when another pattern is more suitable.
Keeping design and code together
A library needs a way to change without leaving older screens behind. I have included a release proposal for this rebuild: a designer and frontend engineer review the same example, record the change and check the screens that use it.
I would migrate the repeated controls first, then the tables and review patterns. An older component stays available until its replacement has been checked in context. Breaking changes need an example showing what consumers must update.
- Draft
Describe the repeated need and check whether an existing component can cover it.
- In review
Compare design and code with the same content. Check keyboard access, errors and long values.
- Ready
Publish the agreed states, usage notes and a change log together.
- Deprecated
Name the replacement, include a migration example and check affected screens before removal.
These are the maintenance rules proposed for the reconstructed library. I would start adoption with the instrument table and review form, check the first features that use them with engineering, and collect questions before expanding the library.
What is ready
The rebuilt library has shared foundations, 26 component families and documented examples of the instrument table and exception review. The component diagrams use the library’s semantic colours, dimensions and documented states.
The browser example checks the selection, filter, sort and review behaviour. The component reference includes every family, its state sheet and construction notes.
For designers
Editable components, semantic variables, text styles and examples made from instances.
For developers
Named tokens, semantic HTML examples and written behaviour contracts.
For the next release
A review checklist and a clear proposal for replacing older components.