I set up the conditions for good design to happen without me in the room.
For most of the last five years I’ve been the only designer on large product suites, so I’ve had to build the systems, rituals and relationships a bigger team would normally carry. Here’s how that works day to day.
Principles
Serve the new hire and the veteran at the same time.
On WM’s dispatch board, a week-one dispatcher and a fifteen-year one used the same screen. Defaults and inline suggestions carried the new hire, the layout kept the patterns veterans already knew, and the shortcuts I recorded in observation sessions came along. Jargon stayed, explained in tooltips that never cost the table any density.
A model’s suggestion is worth nothing if nobody acts on it.
So I design for legibility, confidence and the freedom to say no. Dispatchers’ override rate on WM’s scheduling model fell from 41% to 12% once the recommendations explained themselves.
Match the interface to the thing in people’s hands.
At AT&T the self-install flow followed the physical box, not the task checklist, and support calls fell 28%.
Systems should outlast me.
If you can’t tell when I stepped away, the system worked. Driver Assist launched after I left WM, built on the decision log, data map and tokens the team already had.
How I run a design system
Governance
One rule decided what joined the library: the moment a component was about to be reused, in another product or another part of the same one, it became a candidate. One-offs stayed local until that happened.
Contribution
With one designer and nine products, requests had to flow without a meeting. Engineers filed them in Jira; I checked each against what already existed, adapted where requirements genuinely differed, and kept the products aligned.
Rituals
Monthly reviews with engineering leads, more often around releases. Release notes went out through Confluence and Slack, so nobody had to ask what changed.
Working with engineering and product
Engineers come in at concept stage, not at handoff. When a debate is going in circles I’ll prototype in code or with AI tools to settle it faster, and every decision gets written down so nobody has to argue it twice.
Driver Assist: truck sensors couldn’t report reliably through patchy telematics and dead zones. Rather than fake a live reading, we labelled every value with when it last updated. We gave up latency and kept the driver’s trust.
People act on a model when they can see its reasoning and are free to ignore it.
Mentorship and team health
How I run critique
The presenter sets up the problem and constraints before any screens, so the room starts level. Everyone else asks questions until the decisions make sense. Feedback is direct and kind, and we close on written action items and a genuine “nice work.”
How I’ve mentored
A junior designer joined WM on a one-off B2B customer portal. I introduced her to every PM and engineer she’d need, met weekly to set direction and constraints, and asked where she wanted to grow. She moved onto the projects I recommended her for and started contributing to the design system.
How I work
Focused hours, written decisions, async by default, and no expectation of after-hours replies, from me or from anyone I work with. Good teams don’t run on heroics.
“Matt was in charge of so much, it was crazy that he still made me feel so heard and taken care of at the same time, all the time.”