GRESB's reporting tools were five products wearing five different faces. I led the first design system — and report build time fell from four months to one.

Every report, rebuilt from scratch.

GRESB is the global standard for ESG benchmarking in real assets — used by investors and asset managers to assess sustainability performance. Across the product suite (Benchmark, SFDR, Transition Risk, TCFD Alignment, Portfolio Analysis), each report was being built and rebuilt with similar patterns, slightly differently each time.

The result: rebuilding the same components every quarter, inconsistent UX across reports, more bugs, and missed delivery dates.

Audit the chaos before designing the system.

I started not with components, but with evidence (Fig 1). I ran an interface inventory in Figma, cataloging every UI element used across the reports and organising them into atomic groups (atoms → molecules → organisms → templates). The exercise exposed how many variations of the "same" button, form or table we were carrying — and the cost of carrying them.

I then interviewed engineers, business stakeholders and data scientists across the reports to understand pain points and validate the inventory findings — turning anecdotal complaints into a concrete picture of which patterns were causing the most friction.

Foundations first, components second, adoption always.

I structured the work as three layered tracks rather than a single Big Bang release (Fig 3, Fig 4):

• Foundations — colour (a base palette consistent across reports, plus theme palettes that distinguish product lines), typography (consistent sizes and a clear hierarchy), tokens for spacing and borders, and accessibility (colour contrast and text sizing to keep the system inclusive).
• Core components — buttons, forms, tables, navigation — picked by frequency of use, not by what was most fun to design. Standardised and merged in the Figma library; integrated into Bootstrap on the front-end.
• Patterns & docs — opinionated, examples-first documentation, written with the developers who had to follow it.

A design system is a product. It needs users.

The hardest part of design-system work isn't designing — it's getting teams to stop rolling their own. I treated adoption as a product launch: start in one report, prove the library in production, then expand from there.

I worked closely with engineering to make the system the path of least resistance — if reaching for a system component was easier than building one, adoption took care of itself. The Figma library reached full adoption on the design side. On the development side, new reports adopted readily; legacy systems were harder, with developers reluctant to refactor working code — so older reports are still migrating piece by piece.

Measurable lift across delivery, quality and satisfaction.

• 75%faster time-to-market — report creation down from over 4 months to 1 month
• 90%fewer post-launch bugs (measured via GitHub issues)
• 84%CSAT on assessment submission (4.35/5, 554 responses) — a platform-level measure the design system feeds into, not one it produced alone

What I noticed beyond the numbers was a cultural shift: design, development and data science started sharing a vocabulary, decisions got debated against agreed foundations rather than personal taste, and new reports were built against documented patterns instead of tribal knowledge.

What I took from it.

Two palettes, one system. Keeping everything consistent while giving each product line its own colour taught me how much flexibility a system can absorb before it stops being a system.

Old code doesn't move. Design adopted the library fully, and so did new development. The legacy reports are still catching up, because developers didn't want to touch code that already worked. Honestly, fair enough — but it means adoption is still going, years after launch.

Deleting was harder than adding. Cutting duplicate components was the part I found most difficult. It is also what made the library usable.

I under-invested in documentation. I wrote down the process but not enough of the reasoning. People joining later had to ask me things they should have been able to look up.

The hard conversation. It was never about tokens. It was asking engineers to refactor working code for a consistency they hadn't asked for. I lost that on the legacy reports and won it on the new ones, by making the system easier to use than to ignore instead of mandating it. That choice is why the numbers hold up and the migration still isn't finished.