Case studyWeb app
Operation Polish Scrooge
Redesigning our company's internal platform from the ground up
September 2026 - Ongoing
Key outcomes
- Built a design system in Figma from scratch: 856 variables in four collections, 90 components with about 1,150 variants, and ten text styles
- Redesigned about 260 screens across more than 30 modules, each paired with a section that documents every menu, modal, tooltip, empty state and error it can show
- Reused the same system for a second spin-off product, an EU university alliance's project management tool
- Kept the redesign frontend-only: every field on every screen exists in today's database, so it can ship without backend work
- Wrote the handover for the code build: ten briefs and acceptance checklists that a coding agent works through in the live repository
TL;DR
Scrooge is the internal platform our company, the Knowledge Innovation Centre, runs on: projects, budgets, invoices, payroll, contracts and more. It had grown one feature at a time over 4,800 commits, with three random UI kits and no shared rules. I redesigned all of it, about 260 screens in more than 30 modules, without changing how people already work and without needing any database changes.
I have no coding background, so I used Claude Code to read the codebase for me, and every field and behaviour in the designs traces back to the live product. I built a design system in Figma from scratch (856 variables, 90 components) with every rule written down, then used AI to audit hundreds of screens against it and apply each change everywhere at once. Interviews with colleagues led to new features, such as a new warning system that flags deadlines and end dates of contracts, projects and anything else that can expire.
Halfway through, the same system became a second product: a project management tool for EU4Dual, a European university alliance, where I was the product lead. EU4Dual's design is finished and ready for development. On Scrooge, most modules are designed, and the code build is about to start from a roadmap and checklists I wrote.
The problem
Scrooge (officially KIC Manager) is the platform the Knowledge Innovation Centre runs on. Projects and bids, budgets, invoices, payroll, staff contracts, leave, outputs, risks and contacts all live in it, and the team uses it every day.
It had grown one feature at a time, over more than 4,800 commits, and the interface showed it. Under the hood it ran three UI kits at once (Mantine, MUI and Radix), 104 CSS files with almost 40,000 lines, and 292 colour variables built around a single green. Similar problems were solved differently from screen to screen, and nobody had written down which way was the right one.
My job was to redesign all of it. The difficult part was that it still had to work the way people were used to. The team uses Scrooge every day, and if the new version worked too differently, the complaints would start on day one. On top of that, I'm a designer with no coding background, working on a codebase I didn't write. The answer to "what does this button actually do?" sat in a React file or a backend module I couldn't read on my own.
My approach
Reading the code before redesigning anything
The first step was to go through the platform by hand, to work out how its parts connect and how big it really was. Before the redesign I had seen less than a fifth of it, because I had no access to the admin side. It turned out to be large, and it had more layers than the surface showed: different combinations of settings produce views you would never come across in normal use. So before I drew each screen, I had to find it in the live code and list every field, where each number comes from, what every click, hover and right-click does, and what happens when there's no data.
This is where AI made the project workable. I used Claude Code as an interpreter between me and the codebase. I could ask "how is a project's P&L variance calculated?", "can a project manager delete an output on someone else's project?" or "what else is deleted when a project is deleted?" and get an answer with the file it came from. Any line of UI copy that describes behaviour, such as what gets deleted with a record or who can edit it, had to trace back to the repository. Without that, I would have needed a developer on call for every screen, or I would have been guessing.
Two more rules came out of this. Anything that would need a database change goes on a list of proposals for the developers, and the screens show only what the system can store today. And I keep the live names for fields, columns and statuses unless a new name is clearly better and still recognisable.
One template, eighteen modules
Reading the code also showed me where the effort should go. Scrooge is config-driven: one configuration file per entity drives its list, its detail page and its form, and 18 entities run through the same machinery. So the Projects list, the project record and its side panels became templates. Once they held up, most other modules followed from them. The real design work was in the 16 or so pages built by hand, such as Pulse (part of the tool used for tracking work hours), the calendar and leave management.
Listening to the people who use it
Some of the best changes came from conversations with users. In one interview, a long-time user mentioned that she hadn't noticed a contract was ending in a week. That one sentence became a new component, the Notice. It sits in the page above the content and lists the deadlines, expiries and failures that need attention there. Each line names the record, says what is due and when, and links straight to it. It stays until it is dealt with or dismissed, and it is still there after a reload, so it can't slip past the way a pop-up can.
The same idea went into the notifications. They now also include items that are about to expire or hit a deadline, such as a project ending in 23 days, a staff contract ending in 30 days or leave days about to lapse. It is one of the few changes in the redesign that needs a small backend change.
Another interview showed that Export is one of the most-used actions on the platform, so it now sits in the same place on every table, right beside the main action. Previously it was placed inconsistently, and sometimes missing entirely.
A design system with its rules written down
On a platform this size, consistency depends on rules that someone can check. I built the system in Figma together with Claude, and we wrote every decision into a rules file the moment it was made, with the reason next to it. Some of the rules:
- Colour is tokens all the way down: 856 variables in four collections (primitives, a light and dark semantic layer, area accents and brands). Components bind only to the semantic layer.
- Each area of the platform has its own colour: Main green, Projects blue, Artefacts cyan, HR raspberry, Accounting magenta, Admin purple. There's one set of components, and the colour comes from a mode set on the surrounding frame.
- Ten text styles and no more. I learned from experience that "text style creep" happens quickly unless you decide on the styles at the beginning, and stick to them religiously.
- Spacing and corner radii always come from tokens.
- Small rules that settle a lot of arguments: amounts and codes in mono, dates in sans serif; a missing value is always a grey dash; Edit is a secondary button in a side panel and a primary one on a full page.
The rules file turned out to be the most useful part of the system. It's what let the AI apply the system the same way on the 200th screen as on the second.
Checking and changing hundreds of screens
Every screen has a section beside it that holds everything the screen can open: menus, dropdowns, each step of a modal, toasts, tooltips, and the empty, filtered and error states. The developers may build any page first, so each page documents its full set, even when a sibling page already repeats certain modals or tooltips. That comes to about 250 of these sections.
Checking that much by hand wasn't realistic, so Claude ran audits through Figma's MCP. The most important ones compared the designs with the live platform: was every feature of live Scrooge in the redesign, and did every screen follow the data model? Others checked the craft, such as spacing and colours bound to the right tokens, and layers that overlapped. When a rule changed, the same tooling applied it everywhere, retroactively:
- After an audit of every Edit button, Edit became secondary in side panels and stayed primary on full pages. 142 buttons changed across both products in a few minutes - which would've taken ages by hand.
- When the live platform was updated to allow restoring of deleted rows, "This can't be undone" came out of 62 delete modals.
- When my boss asked for endless scrolling, pagination came off every table, and long lists were refilled with realistic rows.
I reviewed the work the way I'd review a colleague's: with Figma annotations pinned to the exact element, followed by "go through this page and fix them." Each fix was applied wherever the same problem existed, and my notes stayed in place so I could check every one.
AI did the reading, the checking and the repetition. The decisions stayed with me: what to show, what to cut, what to call things, and when a screen was considered done.
The solution
The new Scrooge keeps the old structure, routes and vocabulary, so nobody has to relearn where things are. What changed is how each screen is put together:
- A full page or a side panel. For every kind of record, it was a judgement call whether it needs a page of its own or whether a side panel would suffice. The question that usually settled it was whether the record has tabs of its own, which need to contain children tables.
- One table. Every list uses the same toolbar and card, with filters in one panel, columns you can pick, endless scrolling and the same row actions.
- Side panels for small records. Risks, milestones and outputs open in a panel over their list. It holds everything their old full pages had, so the full pages could be retired, and we could instead show the same information in a more compact way, which allows for quicker comparison of different items.
- One way to add and edit. Records are added and edited in the same place they open, so a record that opens in a side panel is also created and edited in one.
A second product on the same system
Halfway through, the system got its stress test. KIC also hosts a project-management tool for EU4Dual, a European University alliance of nine partner universities plus KIC, with nine work packages and 39 users. It was built in Zoho Creator and is being retired, so the plan was to rebuild it on Scrooge's core.
It was also the first time I was put in charge as product lead, coordinating the other people involved. With our developer, for example, I worked out how to split Scrooge into smaller modules that can be switched on or off. That way EU4Dual gets only the parts it needs, and those parts can then be tailored to its data model.
The first step was to work out what EU4Dual actually needed, and which parts of Scrooge it could reuse. An EU4Dual work package behaves like a Scrooge project, an EU4Dual task like a Scrooge work package, and a deliverable like an output with a few extra fields. So most EU4Dual screens could be Scrooge screens with different data.
The brand is one more mode in the token collections: EU4Dual's fonts and colours, with no component changes. One rule did have to change. Scrooge gives each area its own colour, but EU4Dual's blues were too close to tell apart and looked like a mistake when mixed. So EU4Dual uses one accent everywhere and keeps the area colours only in the sidebar. Besides that, I just had to flick the "brand" switch in Figma, and everything turned into the EU4Dual's design system with one click - although the harder part of tailoring the existing Scrooge modules to their data model came later.
The outcome
EU4Dual's design is finished: every page is built, audited and reviewed, and marked ready for development. On the Scrooge side, the projects, accounting, artefact and HR modules are designed and documented, and a handful of modules (Home, Notes, Tasks, Allocations, Payroll and the admin pages) are still to come.
The code build is about to start, and it follows a roadmap I wrote with Claude. It begins with the tokens and a gallery page that mirrors the Figma design system, then the app shell, then the Projects list as the template for every other table. Each step has an acceptance checklist written in terms I can check myself: open this, click that, compare it with Figma. The coding agent also keeps a lessons file, and every correction I make goes into it before the next screen.
As for the AI, it made this project possible at this size with one designer. It read a codebase of 4,800 commits for me, kept more than a hundred rules without dropping one, and checked hundreds of screens in minutes. But it also made mistakes, as AI does. What caught them was a habit I kept from start to finish: nothing was marked as done until I had checked it carefully against the live version, to make sure every flow and feature was there and had been sufficiently improved.