Skip to content
All work
Design system2025

Loom

The design system I spent six months learning to be careful in

Internship work on a fintech design system: 34 components, a token rename that touched everything, and an accessibility audit nobody wanted to run.

Role
Design systems intern
Timeline
6 months
Platform
Web and mobile
Year
2025
ToolsFigmaStorybookDesign tokensStark
A hand interacting with a touchscreen showing a colourful flow diagram

(The brief)

Six months at Fold Financial as a design systems intern, on a team of three supporting around twenty product designers and engineers.

(The problem)

The library had grown by accident. Four button variants that were visually identical, colour values hardcoded in half the components, and documentation that described an older version of the product. Nobody could safely change anything because nobody knew what a change would break, so designers detached instances instead, which made the problem worse every sprint.

A bright workspace with a laptop, design tools and a pinboard of references
Most of the job was reading other people files carefully before changing anything in them.
01

Auditing before touching anything

My first three weeks were spent not designing. I catalogued every component, every detached instance across sixty product files, and every hardcoded colour value. Four hundred and twelve detachments, and roughly seventy percent of them existed for one of three reasons. That audit turned a vague complaint about the library into three specific fixes, and it is the reason the team let an intern near the tokens.

02

A token rename that touched everything

Colours were named for what they looked like, blue-500, grey-100, so nothing could be themed and dark mode was impossible. I proposed semantic naming, surface, border, content, action, mapped every existing value to the new scheme, and wrote a migration table so engineering could do it in one pass rather than piecemeal. Shipping it took three weeks of review and a lot of patiently answering the same question.

03

Components with all their states drawn

I rebuilt 34 components with the full state matrix, default, hover, focus, active, disabled, loading, error, and both densities, and every one documented with a plain-language when to use this and, more usefully, when not to. Focus states got particular attention since they had been inconsistent everywhere and are what keyboard users actually navigate by.

04

The audit nobody wanted

I ran a WCAG AA pass across the core library and found nineteen contrast failures, mostly in disabled states and placeholder text where everyone had quietly assumed the rules did not apply. Fixing them required arguing that grey-on-grey is not a style choice. All nineteen shipped. It is the piece of work I am most quietly proud of, because no user will ever notice it and several hundred will benefit.

A notebook, coffee cup and design sketches on a sunlit desk
Documentation written the same week as the component, or it never gets written at all.

(Key decisions)

  • Audit and quantify before proposing any change
  • Semantic token naming to make theming possible
  • Full state matrix drawn for every component, including loading and error
  • Documentation written alongside the component, never after
  • Contrast treated as a requirement, not a preference

(Outcomes)

Components rebuilt and documented
34Components rebuilt and documented
Detached instances traced to three root causes
412Detached instances traced to three root causes
Contrast failures found and fixed
19Contrast failures found and fixed
Core library on semantic tokens
100%Core library on semantic tokens

What I took from it

Systems work is mostly writing and persuading. The Figma part was the easy half, and the audit spreadsheet earned me more trust than any component did.

(Next project)

Sohum

A breathwork companion that teaches you to slow down

Made with Modulify