the slowest part of the process was the process itself

When I joined in April 2025, Paul, the design lead, also ran front-end development. He was the only designer working in Figma, with a researcher on the team. Everything lived in one file: several projects, all the local components, and the prototypes for usability tests. The team was behind schedule, and Paul wanted a second designer to help it move faster.

The file was a symptom, not the problem. The project started small, and Paul wore two hats. One file was the fastest way to work alone: no switching between files, no extra context for anyone. As it grew, it slowed down. Clickable prototypes took 5 to 10 minutes to load before every usability test, and a shared link showed people far more than they needed to see.

So there was a choice. Paul could onboard me into the old way of working, or I could pause new features for a while and clean things up, while he kept the features moving. We picked the second. I put the plan in a short deck covering file structure, the design system, branching and documentation, and Paul said yes. He kept working in the old file until the new one was ready, then moved across.

Under the one file were three problems.

We started with the foundations. We split the one file into libraries, design files and docs. We were already on Carbon v11, but an older release, made before Carbon moved from styles to tokens, so we switched to the most recent one. Swapping the library broke a lot: new components didn’t drop neatly into old layouts, so we fixed many screens by hand, and some features we rebuilt from scratch.

The notes were a surprise. We wrote them with Figma’s own annotations, and for a few months nobody mentioned a problem, because nobody knew the notes were there. Then, on a design review call, someone asked what the tiny marks on the screens were. It turned out some front-end developers and all the product managers couldn’t see them, because they didn’t have the right Figma seat. We moved every note to a plugin anyone could read.

how we worked after

Pages got color labels and files got status tags, so anyone could see what was ready. Each new piece of work got its own branch, with a clear name and version number, and Paul and I reviewed each other’s before anything merged. Then we mapped the whole app as user flows in one end-to-end file.

results

• The old libraries were retired within a few weeks.

  Components, icons, pictograms and typography were all replaced, and every custom component was rebuilt on Carbon tokens.

• The front-end team worked from the new files.

  Designers worked in branches, so changes no longer got in the way of developers reading the designs in dev mode.

• Usability tests ran faster.

  Each feature file had its own prototype, so prototypes no longer took 5 to 10 minutes to load before every test.

• Everyone could see the state of every piece of work.

  Page labels and file status made it easy to see what was happening in each file, for the design lead, me, the developers and the product team.

• The team was still working this way when I left.

  The structure, labels, branches and reviews were all still in use in February 2026.

The team picked me partly because of my research background. They’d seen my adidas⁴ case study at the interview. I observed several user interviews, but most of my time went to the design system and the files, with a few small features for Paul along the way. Design systems weren’t new to me, but rebuilding one at this depth was, and I enjoyed it. Paul talked about moving me towards research once the system settled, but I left in February 2026 to start it depends.

Before Ipsos, my work always began with users’ and the business’s needs, then journeys, flows and wireframes. Component libraries were part of it, but never the whole job. Here, they were. I went deep into how a design system should be organized, how to document components, and how design tokens connect design and code. I also learned to check early who can actually see our work, not just whether it’s there.