~85%fewer issues
in my review of a recent Class Management build than in the first proof of concept, on the same pages and modals
Matific · Design & build quality
Closing the gap between design and build
I established Matific’s first design system on IBM Carbon, made build quality a shared goal through front-end KPIs, and added an AI-assisted QA agent so developers can check builds against the design before my review.
- With
- Development team & CEO
- When
- 2022–present
- For
- Front-end & QA teams, and end users
Design
Production
Results
Fewer issues reaching review, and far less of my time spent finding them
Results at a glance: my staging reviews and estimate
~80%less effort
required for multi-size review and reporting once the AI agent was in use.
~85% reduction in UI discrepancies
Dropped from 93 logged issues in the initial proof of concept to just 14 in a recent mature build across the same core pages and modals. To ensure an accurate 1:1 comparison, deprecated screens were excluded from the final count. Notably, 5 of the remaining 14 issues were caught autonomously by the AI agent.
~80% reduction in manual reporting effort
A conservative estimate of the manual time saved on cross-viewport checking, annotation and bug reporting after deploying the AI agent. While I still perform the final human review, automating the repetitive baseline checks drastically accelerated the overall process.
01 · The problem
Built screens kept drifting from approved designs
Who it served
Front-end developers
Translate designs into production code efficiently and accurately.
Need
Well-crafted, shared components so they can match the design perfectly without building from scratch every time.
Quality assurance testers
Validate builds against project scope and design specifications before launch
Need
Clear, prioritised criteria to efficiently spot and report visual inconsistencies across all screen sizes.
Teachers and admins*
Manage daily classroom workflows without friction.
Need
A cohesive, predictable interface that behaves consistently and looks professional during daily use.
* Though built initially to stabilise the educator experience, this foundation is designed to eventually scale outward to support parents and all public visitors across the broader platform.
Where quality slipped
- Approved mockup
- Built from scratch or separate component sets1
- QA testing2
- Design QA on staging, when time allowed3
- Production
What wasn’t working
No shared foundation
Screens were built from scratch or from separate component sets, so presentation was inconsistent.
Quality checks sat outside the build
Visual and UX issues kept getting past QA, so the CEO asked me to review front-end quality as well.
I became the bottleneck
When Product, Marketing and other requests filled my time, reviews were skipped and issues reached production.
Goal
Make the intended quality repeatable with a shared foundation, make it the front-end team's goal too, and catch the gaps that remain without relying on my time alone.
Why it mattered: Teachers and admins use the app daily, and inconsistent screens undermined trust in the product as Matific grew.
02 · The approach
Raise the baseline, share ownership, then scale the checks
I adapted IBM Carbon’s Figma components to Matific’s interface and reviewed staging builds against the designs. I later developed an AI-assisted QA workflow to extend my review capacity, while retaining final human review.
How we worked
Requirements & Alignment
Pitched a design system and secured the CEO’s go-ahead. I shortlisted Material and Carbon; development’s own research confirmed them, and Carbon was chosen.
Structure & Design
Adapted the components the proof of concept needed first, then adapted the rest in small pieces between product work until the library was complete.
Review & Iteration
Reviewed each build on staging against my designs, logging issues beside screenshots and verifying fixes, until the proof of concept was ready for production.
Shared ownership
Agreed with the CEO and Head of Front-end to make build quality part of front-end KPIs, with my QA scorecard as the reference.
Automated checks
Turned my review into an AI agent that checks builds against the design, so developers can catch issues before my review.
2.1 · Raise the baseline
Establishing a scalable foundation with IBM Carbon
To close the gap between design and engineering, I proposed adopting an existing framework via a phased rollout. After development corroborated my research on the top two contenders, we evaluated the finalists:
Option 1
Google Material Design
A strong baseline, but lacked native data visualisation, requiring us to maintain a secondary library for charts.
Option 2
ChosenIBM Carbon Design System
The development team's preferred framework. It included robust, out-of-the-box charting components and naturally suited Matific's dense, enterprise-level interface.
Strategic adaptation and execution
I adapted the core components required for our initial Class Management proof of concept first, reviewing staging builds directly against my mockups. I then incrementally customised the remainder of the library between daily product cycles.
Component adaptation
Rather than taking the library strictly out-of-the-box, I modified key elements to fit Matific’s existing UI system. For instance, I adapted Carbon’s default edge-to-edge, square modal actions into separate, rounded buttons. This preserved Matific’s established interactive language and ensured clear click affordance, which development successfully implemented.
Managing constraints
A legacy board decision dictated that form labels sit on the field border to save vertical space. To accelerate development, I agreed to descope a complex floating-label animation (similar to Material Design), logging it as a fast-follow enhancement for post-launch.
The Result
An 85% reduction in UI discrepancies
My initial design QA reviews more than halved the visual bugs, allowing a highly polished proof of concept to reach production. Crucially, as engineering gained fluency with the Carbon framework, a recent build of those same Class Management pages saw an 85% reduction in visual QA issues—proving the system successfully aligned design and development.
Previous
Pre-system workflow
93total issues detected
Reviewing the initial build revealed massive friction between design and engineering.
Systemic failures
Issues were heavily concentrated in basic component styling, structural alignment, erratic spacing, and broken menu overlays.
New
Post-system workflow
14total issues detected
9 found via manual review, and 5 caught by the AI-assisted QA agent.
Core Component bugs eliminated
Foundational component styling issues dropped to zero. Barring minor, pending component-level spacing cleanups, systemic UI errors were completely resolved.
Remaining edge cases
The few remaining issues were isolated to macro-layout alignment (outside the system's scope) and minor menu clipping, proving the system successfully solved the core UI drift.
2.3 · Scale the checks
Automating the baseline
To reduce the manual QA bottleneck, I integrated a Claude Code agent that autonomously compares staging builds against Figma designs and Product Requirement Document specifications across all viewports. Developers now run this agent to self-serve visual QA before requesting a formal design review. This empowers them to catch baseline issues early, protect their build-quality KPIs, and drastically reduce the defect rate reaching the QA team and me.
Managing AI variability
Because AI models inherently vary between runs, this is an evolving, human-in-the-loop system. The agent surfaces prioritised findings and flags me when it lacks context, but my final manual QA is still required. While not fully autonomous yet, it successfully handles the repetitive baseline checks, drastically reducing my overall manual effort.
Catching invisible bugs
The agent flagged a subtle tooltip clipping issue inside a parent container that human eyes missed during manual review. I quickly confirmed the bug on staging, engineering pushed a fix, and the build was cleared.
AI QA in action: The agent's automated report flagging a subtle, tablet-specific tooltip clipping issue on staging that human review missed.
03 · Adoption & Governance
A foundation in use, and a rollout in progress
The Carbon framework now powers critical areas of Matific’s Educator Web App. Beyond the successful Class Management proof of concept, it drives the core navigation framework and the upcoming 2025 Teacher Onboarding flow.
Ongoing migration & Shared KPIs
To balance systemic updates with daily feature work, the remaining migration is carefully phased. Dashboard conversion began in mid-2026, with Reports, Activities, and Admin sections scheduled to follow. Crucially, the Head of Engineering is actively using my initial QA scorecards to set measurable build-quality KPIs for the team throughout this rollout.
Managing technical constraints
Because migration competes with product delivery, much of the app remains legacy. We also had to make strategic compromises to maintain velocity: when engineering encountered technical blockers integrating Matific’s custom UI icons, I agreed to temporarily adopt Carbon’s default icon set so the broader rollout wouldn't stall.
System governance and maintenance
Working directly with the front-end lead, I am actively auditing our Figma design tokens against the production environment to correct early misalignments. We are also co-reviewing the team's new live component documentation to log spacing cleanups and fast-follow UX enhancements (like the descoped form-label animations) for future sprints.
Reflections & Next Steps
What this rollout taught me, and what I'd do next
What this rollout taught me
A library alone doesn't guarantee fidelity
Even with a robust framework like Carbon, our initial proof of concept required heavy staging reviews. The massive 85% drop in UI bugs only happened once the engineering team achieved fluency with the system. Furthermore, I learned that macro-level layout fidelity still relies heavily on front-end execution—proving that a system augments, but doesn't replace, engineering skill.
Quality scales when builders own it
When I was the sole reviewer, I was both a bottleneck and a critic. By tying UI fidelity directly to front-end KPIs, I transformed my role into a strategic partner. Developers now proactively engage with me during builds and take pride in resolving discrepancies before a formal review.
What I'd do next
Empowering autonomous QA
My immediate focus is utilising development and QA feedback to further refine our AI-assisted workflows. The goal is to empower the team to catch and resolve standard component issues entirely on their own, reserving my direct reviews strictly for complex macro-layouts and UX ambiguities.
Automating design-to-code parity
While our manual QA and token audits successfully stabilised the initial rollout, true scale requires automation. My next initiative is integrating Figma’s Code Connect to bridge our design files directly with the engineering repository. If successful, this will eliminate the need for manual token syncing and establish a flawless, automated single source of truth between design and production.
Helping customers choose tyres with confidence
From collaborative customer research, I created possible flows and a feature list for JAX Tyres’ desktop and mobile booking experience. In the MVP workshop, we agreed the flows and features to take into prototyping and user testing.
Next: JAX Tyres · Research & direction →