Measuring Success
Define the denominator, measure a bounded change and keep the conclusion honest—with an actual image-response comparison from this portfolio.
Published Updated
A component library can grow while the product gets harder to use. Counting components tells me what a team has produced, not whether anyone can build a better experience with them. A useful measurement starts with a decision: what would I change if the result moved in the wrong direction?
Adoption needs a denominator
“Used on forty screens” sounds encouraging until we discover that there are four hundred eligible screens, or that every instance has been detached and locally repaired. I would define adoption as supported instances divided by eligible instances, for a named pattern, product area and release. An eligible instance is one the pattern was designed to serve; an unusual workflow should not be forced into it to improve a percentage.
Record exceptions beside that count. Repeated workarounds may reveal a missing state or unsuitable API. A small, coherent pattern with an explicit exception can be healthier than a nominally universal component that everyone has to bypass. This is a proposed measurement framework, not a claim about adoption inside a former client team.
One measured change in this portfolio
The current art collection provides a smaller, inspectable example. A contact-sheet image needs to communicate the composition; full-resolution inspection is a different task. I compared one source image with two responsive renditions on 4 September 2026, holding the asset and output format constant.
Scroll sideways or focus the table and use arrow keys →
| WebP response | Body size | Intended use |
|---|---|---|
| Original · 1,277 px wide | 142,350 bytes | Full-image inspection |
| 640 px · quality 75 | 33,896 bytes | Larger preview candidate |
| 384 px · quality 75 | 15,786 bytes | Smaller preview candidate |
Local production build; WebP requested explicitly. Response bodies only, excluding headers. The browser chooses a candidate according to layout, pixel density and its own loading decisions. These are not page-speed or visitor measurements.
At 384 pixels, the response body is about 89% smaller than the original. That supports serving a smaller candidate in the collection, not making the original unavailable. The resulting implementation supplies responsive sizes, retains the complete composition in each preview and opens the original for close inspection. You can examine the same work in the art collection.
Keep the conclusion smaller than the evidence
This sample establishes a transfer-size difference for one asset. It does not establish a site-wide speed improvement, a faster Largest Contentful Paint, or more completed hiring enquiries. Nor does a byte count tell us whether fine marks remain legible. I need a visual comparison at the intended display size as well as the number.
I would keep three records separate: a repeatable asset test; page-level tests under stated device and network conditions; and real visitor measurements over a defined period. The distinction matters because controlled tests and field data answer different questions. Google’s explanation of lab and field data sets out why those results can differ.
Measure the task the system is meant to support
For this portfolio, the human question is whether someone can find a relevant project, understand my contribution and inspect enough evidence to decide whether to contact me. A review should ask people to perform those tasks, observe hesitation and record what they understood—not ask whether they liked the website.
That review has not yet supplied results. Until it does, lighter previews are an observed implementation improvement, not proof of a better hiring outcome. The same discipline applies to a design system: define the task, measure a bounded change, document the exceptions and use the result to choose the next change.