How one designer covered five teams

A design system engineers can import.

Aurora is the design system in code, with token layers, a component library, a live documentation site and Storybook on staging. It was the single source of truth for UI decisions across the five teams, and legacy pages were gradually moving onto it. A prototyping kit sits on top, so every feature prototype starts from the system instead of a blank Figma frame.

The reference site is checked against the staging foundations and the Figma specs, and the validation log is on the page.

Engineering and I built it together. I worked on the token model, the component specs, the documentation and the prototyping kit, and engineering built the production implementation.

Engineers got design answers without waiting for me.

A PM had started a Claude project for design advice, and I expanded it into the Scaler Design Assistant. It knows our usability heuristics, the UX writing standards with a 290-term ESG glossary, and the Aurora tokens and component rules, and it can open a Linear ticket for design approval. Engineers got accurate answers on spacing, states and copy straight away, so the questions that still reached me were the ones that actually needed my judgement.

Behind it are nineteen skills that write down how design worked at Scaler. Thirteen are mine and six were shared with the company, and most of them started as input for the assistant before becoming references in their own right.

Design QA became a script.

Design QA used to mean booking a testing slot and clicking through every state with staging open next to Figma. I replaced that with a script that compares the build with the design and files the differences as Linear tickets, and I ran it before every release.

I used the same approach in other places too. One set of meeting notes became Linear tickets, a Notion page and a Slack summary, and the whole team used a Slack reaction that turned a message into a ticket.

I audited every screen in two weeks.

In February 2026 I audited every user-facing screen across Collection, Analytics and Reporting, and gave every issue a severity level, a screen and a recommendation. I delivered it as an interactive tool, built with Claude Code in a few days, so the team could filter it and keep it up to date as fixes shipped.

The 27 urgent issues won a quarter of engineering time and started the Product Coherence programme. Each issue is pinned to the spot on the screen where it happens, with a status so the team could track fixes. It became the company’s UX issue log.

I built my own research tools for a workshop.

For the information architecture rework, four Account Ops colleagues and I each sorted 78 pages. Then we reverse-sorted each other’s results and looked at where we disagreed. No off-the-shelf card sort tool could do that, so I built my own.

The votes turned into thirteen Linear tickets, and three navigation changes shipped within weeks.

I shipped front-end fixes, reviewed by engineering.

I shipped front-end fixes with Claude Code, and engineering reviewed every one before release. The biggest was an overhaul of navigation between modules, where I audited every route, mapped each page to its equivalent in the other modules and then implemented the fixes, so switching modules now lands you on the right page.

I build tools at home too.

If something normally needs a person, I try building a tool for it first, and only hire for the part that still needs one.