Client name withheld under NDA
A compliance automation platform that runs governance, risk, and compliance engagements across six regulatory standards at once. This is a real client engagement; the client's identity is withheld under NDA. It is also the project whose scope creep led directly to ShipLock, and where a design system moved out of Figma and into the code.
What it is. A compliance automation platform for a cybersecurity consultancy. It replaces a fully manual practice, spreadsheets, Word documents, WhatsApp threads, and email chains, with one system that runs engagements across six regulatory standards at once: ISO 27001, PCI DSS, BCMS, NDPA, PIMS, and SMS. One hierarchy holds it together: client, project, phase, document. Every standard moves through the same phase sequence, and every phase carries its own required documents through versioned review and approval.
Who it's for. The consultancy's own team and the client organisations they take through certification. Three roles share the platform, Platform Admin, Tenant Admin, and Client Admin, each seeing a different slice of the same truth. This is real client work; only the client's identity is redacted under NDA. The product, the decisions, and the numbers shown here are genuine.
My role. I led product design on a cross-functional team that included a fullstack engineer, on an eight-figure engagement. Partway through, I also took on something I had not planned for: moving the design system out of Figma and into the codebase as the single source of truth. That story is most of this page. It is also where I learned, the hard way, what unmanaged scope does to a build. That lesson became ShipLock.
Six standards, one system
Six standards could have meant six separate tools. The bet was one consistent system instead: every standard, from ISO 27001 to SMS, runs through the same client, project, phase, document hierarchy. Learn the shape once and the next standard costs almost nothing to add. That bet had to survive real discovery. I read through dozens of the client’s actual internal compliance documents to understand what a phase deliverable really looks like, the requirements were rewritten more than once as new standards joined the scope, and a 40-page consolidated requirements document arrived late in the build with about a month left to MVP.
The design problem underneath it all was density. Compliance work is tables, statuses, versions, and evidence, thousands of small facts that all matter to an auditor. Three admin roles, Platform, Tenant, and Client, each see a different slice of the same data. The job was making that navigable without dumbing it down. Consultants live in this tool all day, and it needed to feel calm rather than simplified.
Core mechanics
Five mechanics carry the product. Each block below is the actual production screen, embedded live from a sandboxed deployment. The client, risks, documents, and scores are fictional; the interface is not a mockup.
Every risk gets an owner, a likelihood, and an impact. The platform computes an inherent and residual score, then ranks the register so the highest-exposure items surface first. Residual score is inherent times control effectiveness: mitigation is measured, not claimed. This is the production risk register, running live with fictional risks.
Map a single control to many standards at once. Implement encryption-at-rest once and it satisfies the matching requirement in ISO 27001, PCI DSS, and NDPA simultaneously. The tracker shows coverage per framework and per control, with evidence and gaps attached where they belong. One control, many standards, no drift.
Each control asks for proof. Evidence is versioned and expires on a schedule, so audits never run on stale artifacts. Watch the expiry column: expired proof flags its control as at-risk automatically. The register spans every client the consultancy runs.
Every control that fails or lacks evidence opens a gap. Gaps carry a severity, an owner, and a remediation path, and they only close when the fix is verified, not when it is promised. The coverage index up top is the honest number: how much of the framework is actually accounted for.
Every change, a re-scored risk, an approved control, a swapped piece of evidence, is logged with who, what, and when. When an auditor asks how you got here, the answer is one immutable timeline instead of an email archaeology dig.
The turning point
Early in the build, the turning point arrived quietly. An engineer started shipping UI faster than the Figma file could stay current. AI-assisted tooling meant screens appeared in the product before their designs had settled in the file, and the interface drifted a little further from the design every week. I could have fought the gap with process, review gates, redlines, stricter handoff. Instead I moved the entire system into code: a real token architecture, a documented component library, a written specification covering color, typography, spacing, and motion. The codebase became the canonical design file.
It evolved rather than arriving in one dramatic rebuild. The engineer had already built a lighter surface standard, Surface System v1, to keep his own output consistent. What I authored on top of it is what turned it into a governable system: Design Language v2. A token architecture of 50+ CSS custom properties covering brand color, status color, a radius ramp, and a shadow ramp. A 20-component library built on 35 Radix-based primitives. And roughly 130KB of structured documentation living in the repo itself, 14 files covering color, typography, spacing and layout, radius and borders, shadows and elevation, buttons, cards and surfaces, forms, motion, data display, navigation, and a dos-and-don’ts QA checklist for every screen type.
50+
Design tokens
20
Components on 35 primitives
14
Spec files · ~130KB
329
Production imports
Adoption is the number that matters, not creation. The system now governs over 300 places across a live product, 329 confirmed imports as of this writing, against 11 legacy imports still being phased out on a documented cutover checklist. I am not going to claim a finished migration. The honest state is a dominant system with a visible, shrinking tail.
A design system that isn't documented is just a personal preference with extra steps.
Rules for the AI in the room
Then I wrote a second document. A CLAUDE.md sits in the repo and tells AI coding assistants how to work within the design system: which components exist, which tokens to reach for, what never to hardcode. It reads like onboarding notes for a new hire, because that is exactly what it is.
The model writing half the code needs the same rules a human contributor would. A design system built only for humans stopped being complete the moment AI started shipping alongside them.
The real test is whether a developer, human or otherwise, can implement something correctly on the first try, because the system told them how. That is what the tokens, the spec files, and the CLAUDE.md are all pointed at. Consistency that survives contact with a real roadmap instead of drifting the moment nobody is watching.
The system, running live
The blocks below are the real design system, embedded live from a sandboxed deployment. The client, documents, and scores are fictional. The components and tokens are the ones governing the production product.
The consultancy-side home: portfolio health KPIs, risk and evidence donuts, work queues, deadlines, and alerts across every client engagement at once. This is the real production dashboard running live; only the numbers are fictional. Information density was the design problem, and this screen is the thesis statement.
The whole system in one scroll. This is the product’s living design system page, the successor to the internal Design Lab, rendered by the same registry the engineers build against. It opens with foundations, color, typography, spacing, radius, and motion, each sourced from the 14 spec files, then walks every component family: actions, forms, pickers, data display, badges, feedback, overlays, structure. It ends with composed patterns, the full screens every new feature starts from. The left rail is a real scrollspy with search, and each entry carries its measured import count and status, stable, legacy, or unadopted, so adoption is audited rather than assumed. The 329-imports claim in this case study is a number you can go count.
Shipping under pressure
With a month left and a 40-page requirements document on the table, everything could not ship. I scored every requirement on four axes: complexity, time to build, how deeply it interlinked across standards, and whether it was must-have or nice-to-have. The framing to the client was simple. Ship fast, get real usability data, and prioritise what comes next from actual use instead of guessing.
A rigorous testing phase then surfaced feedback that required careful triage between genuine defects, already-resolved items, and subjective preferences. Categorising every reported issue by type and status became its own small case study in advocating for accurate scope assessment under pressure. It is the least visual work on this page and some of the most valuable.
The platform is in final testing, going live at the end of July 2026, on an eight-figure engagement. The pain this project taught me, evolving requirements, approvals living in chat threads, deferred features quietly becoming MVP scope, is the pain ShipLock exists to prevent. It was learned here first.