Founding Product Designer
Designed one flow for two audiences: developers and non-technical teams
Built the design system from day one (tokens, components, patterns)
Set the depth of technical detail with two performance experts
Figma · Variables · Design Tokens · Prototyping
Web performance tools were built for developers. CatchMetrics wanted the same data to make sense to people who know their site feels slow but can't read the numbers, without losing the depth developers need to fix it.
Competitor tools were powerful but intimidating if you weren't a developer. The product was pre-launch, so I leaned on:
Two performance experts who'd spent years seeing how real users struggle with this data
Competitor analysis of SpeedCurve, Calibre and Chrome DevTools
Heuristics and cognitive load principles to cut the overwhelm
Each choice answers one question a non-technical user would actually ask.
User Need
Challenge
Design Choice
Is my site slow?
Where is it slow?
Users don’t know where to look
Pages ranked by impact
Why is it slow?
Element drilldown with a plain breakdown
Started with simple dashboards to see how people would enter the data: by browsing problems or by asking questions.
Entry points written as questions, not metrics. Someone who doesn't know what INP means can still ask "Are scripts slowing down my site?"
Split the product in two: exploring what's wrong, and fixing it.
The map was great for scanning but hard for comparing. The experts knew users needed to rank countries too, so I kept both behind a toggle.
Map-first
Quick to scan by region, hard to compare exact numbers.
Table-first
Each question in the table became one step.
Is my site slow?
One summary per metric. Failing ones are flagged so you don't need to know the thresholds.
Where is it slow?
Pages ranked by impact, so you start with the worst one.
Why is it slow?
The exact element, under a plain heading: "What caused the delay?"
The three questions held up, but scripts caused enough of the problems to need their own step. The final product has four.
Overview
Spot failing metrics quickly
Pages
Prioritise affected pages
Scripts
Identify slow scripts
Elements
Drill into root causes
New metrics were coming, and every new pattern would be one more thing for a non-technical user to learn. So everything was built from a small set of parts.
Design system with tokens and variables, so new screens match the old ones without me redesigning them.
One card, many metrics. A new metric slots into a card users already know how to read.
One drilldown pattern everywhere. Script, pages, detail. Learn it once, use it on every level.
Filters that carry through. Pick INP, LCP or CLS once and every view below follows.
The hard part: keeping it simple without hiding the depth. Progressive disclosure did most of the work.
What I'd validate next: where the handoff between non-technical users and developers should sit.
How I'd measure it: whether a non-technical user can answer "is my site slow, and where?" without help.
Some of the features can be seen here: https://www.catchmetrics.io/platform