About

I'm Martin Duggan, a UX designer who works at the intersection of product, UX, and development. My work has moved steadily toward complex, high-stakes enterprise systems — most recently AT&T's Plug-in Inventory Management platform, a $56 billion inventory system for the physical hardware that runs the national wireline network. I'm not a telecom expert, a supply-chain expert, or an auditor. I'm someone who's good at getting from "I don't understand this" to "I can design for this responsibly" — quickly, and honestly about what I did and didn't validate along the way.

Where I sit: product, UX, and development

Most UX portfolios describe a designer's process. Mine has to also describe where that process ends and implementation begins — because for me, it usually doesn't end there.

• UX is the core: user flows, information architecture, interaction design, visual systems.
• Product is where I expand outward: understanding business constraints, working with product owners on scope and trade-offs, and treating "what can actually ship" as part of the design problem, not something design hands off and hopes for the best on.
• Development is the differentiator: I read and write CSS, understand Sass architecture and design-token systems, and I'm comfortable enough in a real Angular codebase to debug a styling issue alongside a frontend engineer rather than filing a ticket and waiting. On the PIM team, I'm the only designer with that level of frontend fluency — which means engineers bring UI implementation questions to me, not just the other way around.

That combination is why I describe myself less as "a UX designer" and more as the person who helps make sure a design decision survives all the way to production — because I've seen, repeatedly, how much gets lost in the handoff when nobody on the design side understands what's actually happening in the code.

How I actually work

I deal with complexity by getting inside it, not by abstracting it away. On PIM, that meant learning telecom hardware terminology, audit compliance rules, and supply-chain operations well enough to design responsibly for people who'd been doing this job for years. On Capital Tools, it meant learning Apple's Human Interface Guidelines well enough to design a native iOS experience I had no prior background in, rather than just porting web patterns over and hoping they'd feel native. Both are the same underlying skill: treat unfamiliar domains as a fast, structured research problem, not a blocker.

I design against what a team can actually build. Every design decision on PIM had to survive a second question: can an agile team build this in a two-week sprint? That constraint shaped scope more than any style guide — breaking large changes into shippable increments, being deliberate about what to defer, and extending existing patterns instead of inventing one-off treatments that would take a sprint to build and another to maintain. I design with delivery reality built in, not layered on afterward.

I'm honest about what's research and what's judgment. A lot of my work is informed by pattern recognition and domain exposure rather than a formal research phase — and I say so directly, rather than dressing intuition-led decisions up as something they weren't. On PIM, the most useful validation didn't come from an upfront discovery study; it came from a staged beta rollout and weekly design reviews with the actual people who use the system, across four different operational groups with different (and sometimes conflicting) needs. I'd rather describe that accurately than perform a process I didn't run.

A capable team relies on my input, and I take that seriously. Presenting new designs weekly to representatives from audit, business, and field-service groups means defending decisions to people who will tell you plainly when something won't work operationally — and that's a better filter than most formal usability tests. Frontend engineers treating me as a real second opinion on implementation quality, not just a design source, is the outcome of years of deliberately staying close to the code rather than a title I claimed.

Leading on AI as a working practice

I use GitHub Copilot daily in actual frontend debugging and implementation work — not as a novelty, but as part of how I get design decisions into working code faster and more accurately.

The more durable piece of this, though, is something I built rather than just used: over the life of the PIM project, I kept a running, LLM-assisted knowledge base — effectively a working wiki — capturing domain knowledge, design rationale, and technical troubleshooting as it happened. The material in this portfolio is a direct product of that practice: the case studies here were built from that same knowledge base, not reconstructed from memory months after the fact.

That's the distinction I'd draw between "using AI" and having an AI-assisted practice: one is a tool you reach for occasionally, the other changes how you retain and transfer knowledge across a long, complex project — which matters more the bigger and longer-running the system you're working on.

What I bring to a new team

• Fluency in taking on unfamiliar, high-complexity domains quickly and designing responsibly inside them — without needing to become a subject-matter expert first.
• Real frontend implementation skill (CSS, Sass, design-token architecture, enough Angular/Angular Material fluency to debug alongside engineers) — not just visual design handed off and hoped for.
• A design practice grounded in what a team can actually ship on a real sprint cadence, not disconnected from delivery reality.
• Comfort presenting to, and negotiating between, multiple stakeholder groups with genuinely different priorities — audit, business, and field operations, in PIM's case.
• An AI-assisted working practice that's already produced a durable knowledge base, not just faster individual tasks.
• Direct, unvarnished honesty about what was validated by research versus judgment — which I think is a better signal of seniority than a polished process narrative.

Currently

The PIM program's budget winds down in late October 2026, and I'm looking for what's next.

info@martinduggan.com