WebSweep
The first product surface shipped on the overhauled design system. I owned the system side: the product design language in practice, and the two components the product needed that the system did not have.
- First
- Product surface shipped on the overhauled design system
- 2
- System components it gave back: a graph, and a table that becomes cards
- May 2026
- First tier live to customers, after an April beta
- Company
- Proctorio
- Role
- Staff Designer, design system and product design language
- Team
- Product design by Tory Barden
- Type
- New Product Suite
- Design Systems
- Design Tokens
- Component Design
- Responsive Design
- Data Visualization
- Figma
Problem
WebSweep had been designed on the legacy design system. When the overhaul shipped in January 2026, a brand-new product was about to launch on a system we had just retired, and the new system had never carried a real product.
Task
As the system owner, bring WebSweep onto the overhauled design system without losing its launch window, establish the product design language on a real surface, and build what the product needed that the system did not yet have.
Process
Worked alongside the product designer, Tory Barden, who owned the flows and product decisions. I owned the system side: mapping the redesign onto the new tokens and components, then designing a graph component and a responsive table that collapses to cards on mobile, both built as system components rather than product one-offs.
What WebSweep is, briefly
Exam content leaks to homework-help sites, forums, and file-shares, and the institution is usually the last to know. WebSweep scans the open web for leaked assessment content, surfaces what has already escaped, and turns a find into an action: a takedown notice, or swapping the affected questions so the exam stays usable. It ships as one half of Vault by Proctorio, alongside ScreenBlock.
The product design, the flows, and the product decisions were Tory Barden's. This case study is about my part: the design system underneath it.
Why the system owner was hands-on
WebSweep was first designed on the legacy design system, the one with 587 card variants and no semantic token layer. I was leading the overhaul of that system at the same time, and the overhaul shipped in January 2026, before WebSweep did.
That left a choice: launch a new product on a system we had just retired, or redesign it on the new one and hold the launch window. We redesigned it. The work ran from February, went to beta with real customers in April, and the first tier launched in May 2026.
It was the first new product surface released on the overhauled system, which made it the first real test of the design language. A system proves itself on a product, not in a library, and I wanted to be in the room for the first one.
Establishing the design language on a real surface
The overhaul had set principles on paper: no product logic in components, no variants for hypothetical use, start from the foundation and let the foundation grow. WebSweep is where those principles first met a product with its own needs.
My job was to make sure the new language held under real pressure: that the dashboard composed from the system's tokens and components without forking them, that the spacing, type, and color decisions were the system's decisions and not the product's, and that when the product needed something the system did not have, the answer was a system component rather than a one-off.
Most of the dashboard composed cleanly. Two things did not exist yet.
The graph component
The resolution-rate ring and the activity-over-time chart were the first data visualizations the system had to carry. I designed them as a system component on the semantic token layer, so chart color, typography, and spacing come from the same tokens as everything else. The graph themes with the rest of the product instead of carrying its own palette, and the next product that needs a chart starts from a component rather than from scratch.
The table that becomes cards
The compromised content table is dense by nature: course, quiz, content, link counts, status. It reads well on a wide screen and falls apart on a phone.
Rather than a separate mobile component, I designed it as one component with two presentations: rows on desktop, and on mobile each row collapses into a card that keeps the same data and the same actions. One data model, one set of behaviours, no fork. It is the "let the foundation grow" principle doing its job: a real pattern showed up in a real product, and the system absorbed it.
What it proved
Both components went back into the library, so WebSweep left the system larger than it found it. More importantly, it left a reference: the first shipped answer to "what does the design language look like on a product," which every surface after it could build from.