Most UX portfolios are written for other UX designers. This one is written for the people who actually hire: technical directors, engineering managers, product owners — people who need to know whether you can make a real system safer, clearer, and cheaper to run, not whether you ran the textbook process. So instead of a persona deck and a research ritual, what follows is closer to an engineering case study: the scale of the problem, the constraints I was working inside, the decisions I made and why, and what happened as a result — including where I'd do it differently next time.
Snapshot
The scale of what I actually worked on.
Plug-in Inventory Management (PIM) is part of AT&T's Procurement & Inventory Management suite, alongside Capital Tools, Minor Materials, and (in progress) TEO order management. It replaced a set of legacy SharePoint-based tools the business had outgrown, and its success became the reason AT&T funded the wider rebuild.
What I actually bring
Four themes, pulled straight from how I actually work.
I go deep into domains I don't start out knowing
I'm not a supply chain expert, a telecom engineer, or an auditor. On PIM I had to build a working mental model of wireline network hardware, SOX-driven audit rules, CAPEX/OPEX accounting, and the difference between "service-affecting" and "non-service-affecting" actions — well enough to design for it responsibly. That's a repeatable skill, not a one-off. Full story →
I write the CSS. Most designers hand off; I stay in the code.
I'm the only designer on this team with a working knowledge of frontend implementation — CSS, Sass architecture, and design-token systems specifically. That let me debug real Angular Material/CDK styling issues alongside frontend engineers, define the token architecture the design system runs on, and catch UI regressions before they shipped rather than after. Full story →
I use AI as a working practice, not a slide
Daily use of Copilot in actual frontend debugging and implementation work. And over the life of this project I built and maintained a running knowledge base — effectively an LLM-fed wiki — capturing domain knowledge, design decisions, and technical troubleshooting as they happened, so none of it lived only in my head or got lost when priorities moved on. More on this →
A capable team relies on my judgment
Weekly, I present new designs to a room that includes audit, business, and field-service representatives with genuinely different priorities — and the designs that come out the other side are the ones that ship. Frontend engineers come to me, not just the other way around, when a UI implementation doesn't look or behave right.
Case studies
Each one short enough to preview in 20 seconds — the full narrative lives on the page.
Turning a functional-but-fragmented enterprise tool managing $56B in national network inventory into a coherent product — while learning the domain, enforcing business rules through UI, and designing for four constituencies at once.
→ 02 Capital ToolsExtending the same design language onto a Capacitor-wrapped native iOS app with real hardware integration, and rebuilding a 100-field desktop data grid into something usable on a phone.
→ 03 The PIM Shell & Design LibraryWhat it took to make design tokens survive contact with Angular Material — CDK overlay debugging, a token architecture that scales across four sub-applications, and becoming a genuine second set of eyes for the frontend team.
→Get in touch
Available now — the PIM program's budget winds down in late October 2026, and I'm looking for what's next.
Earlier work: CommentSold case studies →