Seeing systems
Dashboards, usage visibility, and the design work of making complex test infrastructure legible at a glance.
Case studies
Accessibility results, uninvited
Auto-enabling accessibility scans on ordinary test runs puts a11y results in front of teams who never asked for them — value realization and lead generation in one move. The design problem: presenting an uninvited, deliberately lightweight scan honestly, inside a dashboard built for a different job.
The grid you don't have to babysit
Teams that run their own automation grids spend their best engineers on Kubernetes babysitting. This note is the design scoping for a self-serve grid offering: what the open-source alternatives make people endure, and the three guidelines that came out of watching it.
Trusting a model with your test suite
Teams with hour-long test suites don't need faster machines — they need to run fewer, smarter tests. I'm designing BrowserStack's exploration of predictive test selection and orchestration: the design problem isn't the ML, it's persuading an engineer to let a confidence curve decide what doesn't run before their release ships.
The old dashboard was right about one thing
BrowserStack's unified test dashboard had to replace two legacy dashboards that users genuinely loved in places. I led the usability work that treated their complaints as specification: the navigation friction they named became a build-switching sidebar, designed against the best on-demand panels in the industry — and a lesson in when a design system should win an argument.
Who's using our parallels right now?
Two enterprise customers with hard capacity ceilings asked the same question in different accents: which teams are consuming our parallel test slots right now, and is the queue fair? This note maps the design space for real-time usage visibility — an API, a dashboard, or both.