Matific · Design & build qualityFront-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.
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.
- Sole designer
- Design system
- Component adaptation
- Visual Design
- Design QA
- AI tooling
WithDevelopment team & CEOWhen2022–presentForFront-end & QA teams, and end users
Results at a glance: my staging reviews and estimate
Fewer issues reaching review, and far less of my time spent finding them
~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
~80% less effort
required for multi-size review and reporting once the AI agent was in use.
Mixed Scope
Carbon covers selected educator web app pages; much of the app is still legacy. The AI agent is shared with development and QA, with feedback pending.
How I measured
~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
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 sets
QA testing
Design QA on staging, when time allowed
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.
Evidence
My first review of the proof-of-concept build logged 176 issues across 8 pages, from wrong colours and sizes to menus that overlapped and controls the keyboard couldn't reach. It was typical of what I'd seen in earlier builds.
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
Teachers pick class and subject in one step, teaching and school administration get their own spaces, content gains height on smaller laptops, and class settings have one clear home.
How we worked
01
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.
02
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.
03
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.
04
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.
05
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
IBM Carbon Design System
· Chosen
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.
Carbon default: Edge-to-edge, square modal actions.
Before
Matific adaptation: Separated, rounded buttons to preserve brand interactive language and click affordance.
After
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
93 total 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
14 total 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.2 · Share ownership
Make build quality a shared goal
Rather than endlessly chasing manual fixes, I proposed shifting accountability by making UI build fidelity a core front-end KPI. By using my design QA scorecard as an objective benchmark, both the CEO and the Head of Front-End agreed to integrate these metrics into engineering targets.
This cultural shift fundamentally changed team dynamics—dramatically reducing friction and transforming me from a critic pointing out errors into a strategic partner helping them hit their goals.
The Workflow
01
Measure
I conduct a structured design QA round to produce an objective fidelity scorecard.
02
Align
The scorecard is shared directly with the Head of Front-End to review systemic trends.
03
Execute
Engineering leadership uses the scorecard data to set measurable KPI targets with the development team.
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.
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.