Class Lead / Systems
Class Lead / Systems
Lot 01 / SS26
Lot 01 / SS26
Base Costa Mesa, CA
Base Costa Mesa, CA
Units 05 / Active
Units 05 / Active
Status Open / Lead roles
Complicated
is easy.
Obvious is hard.
Good for health
Bad for education
Lot 01 / Subject 26
Health screening ops. Fintech onboarding. Legal underwriting. Real-money trading.
The regulated, multi-step stuff nobody wants to own. Where one confusing screen costs somebody real time, or real money.
Right now I’m at Quest Diagnostics, on an employer health platform merging three separate products into one. I own the information architecture for that merge.
Before that: Principal, Salesforce, and a crypto betting startup that moved faster than it should have.
Service years
15+
Leading design
Since 2022
Regulated domains
04
Published by
Published by
Design systems
●
Workflow architecture
●
AI design ops
●
Regulated products
●
Specs before screens
●
Design systems
●
Workflow architecture
●
AI design ops
●
Regulated products
●
Specs before screens
●
DEPLOYED AT
Quest Diagnostics
|
Principal
|
Salesforce
|
Cartiga
|
LEVR
|
Entrepreneur MEDIA
01
PROJECTS
05 total
02
Operator file
About
I got here by reading the manual nobody wrote
I got here by reading the manual nobody wrote
I started in editorial and brand. You learn fast there that nobody uses a thing they don’t understand first.
Fifteen years on, same job, harder rooms. Take a process that lives in six people’s heads. Turn it into something a team can build and a stranger can operate.
I keep landing on products where being wrong is expensive. Retirement savings. Legal underwriting. Health screening for thousands of employees. Real-money trading.
In those rooms the interface is rarely the interesting part. It’s the workflow logic underneath. The edge cases nobody wrote down. The decision somebody made by accident three sprints ago that everything now depends on.
So I write things down. Specs, status models, decision logs, open questions with somebody’s name on them.
Not because I like documentation. Because a written answer scales and one that lives in my head doesn’t, and I’ve been the bottleneck enough times to stop enjoying it.
Least glamorous part of the job. Also the reason the rest of it works.
Lately most of my leverage comes from putting AI inside that process instead of next to it. Auditing designs against requirement schemas before handoff. Coded prototypes with real state logic, not static mocks. Specs drafted straight from research transcripts.
It’s changed how much one designer can actually hold. It also gets things wrong, confidently, which is its own discipline.
Currently
Senior product designer, Quest Diagnostics employer health platform
Looking for
Staff, lead, or principal roles on complex products. Enterprise SaaS, health, fintech. Remote or Southern California.
Outside the work
Costa Mesa, twenty minutes from the water. I read more manga than is strictly dignified for a man my age, and I will talk about Otomo’s linework longer than you want me to.
What other people ended up using
A ten-minute design-acceptance check before a story gets marked done. Proposed it because I’d lost the argument about redesigning built screens. A team I don’t manage still runs it.
A four-gate review for regulated features. Usability, responsive logic, front-to-back integration, compliance, ADA. It outlived the feature it was built for and got used on internal tools, which is exactly where that kind of thing usually gets waived.
A visual grammar for architecture diagrams. Piloted with two scrum teams, ended up feeding Salesforce’s Well-Architected standards.
None of that came with authority attached. That’s sort of the point.
03
Method
Operating principles
M/01
Specs before screens
Specs before screens
Specs before screens
On ambiguous programs I write the business rules, status models, and open decisions before I draw anything.
The document becomes the thing the team builds against. Answers live in a reference instead of in my head, where they’re no use to anyone at 9am on a Tuesday. Primary instrument: a written spec.
M/02
AI inside the workflow
AI inside the workflow
AI inside the workflow
Audit designs against requirement schemas before handoff. Coded prototypes with real state logic instead of static mocks. Specs drafted from research transcripts.
It changes what one designer can own. It also means checking the work, every time.
M/03
Decisions, not opinions
Decisions, not opinions
Decisions, not opinions
Conflicts get framed as documented decisions and routed to whoever actually owns them. Not answers I made up because I was the one holding the file.
Teams move faster. And nobody ends up stuck with a call they never got to make.
設計
“A strategic systems thinker, always designing with the bigger picture in mind. He asks the tough questions and challenges assumptions.”
Cory B. / Designer
“Quality designs that balance business outcomes, user experience, and technical reality. He is intentional in his work.”
Rene P. / Lead Developer
“Working with Kevin never felt like work. He brought collaboration, honesty, and fun on top of his UX expertise.”
Hannah L. / Marketing
“He adapts with every level of feedback, stays flexible with shifting priorities, and drives problem solving.”
Carli B. / Stakeholder
Got something complex and slightly on fire?
Open a channel →
ケビン・チャップマン
No. 26 / Lot 01 / SS26