Portfolio Matthew Dingee

Skills

I spent the first half of my career becoming a software engineer and the second half becoming a designer. The interesting work has almost always turned out to be in the space between the two.

I started in a garage in Palo Alto at WebTV in 1996 and spent the next fifteen years supporting and building software in Silicon Valley — front-end infrastructure and internal web applications at Tellme and then Microsoft. I moved to EightShapes in 2011, where I learned to think about interfaces as systems of parts rather than as pages, and where I started calling myself a designer. Since 2015 I've been in public service: The Lab at OPM, the U.S. Digital Service, and now the Department of Veterans Affairs.

Human-centered design is the center for me, the set of underlying principles that binds the rest together. But the problems I get handed rarely live inside a single screen. They live in the seams — between a form and the system of record, between a design system and the sixty teams using it, between what a designer intended and what actually shipped. Being able to both design and build has mostly meant that I can go look. While the case studies cover some of what I've had the opportunity to do, there were plenty of other projects that allowed me to grow in the following ways:

Human-Centered Design

HCD is where I learned to slow down before setting direction, and it underpins everything below it: design discovery, service design, systems thinking, and UX design. I came to it the long way around, from engineering, which is probably why I'm suspicious of any process that produces agreement without producing evidence.

Design Discovery

Having worked with Dan Brown and been involved in discovery on projects with him, I'm a firm believer in his practical approach to design discovery. Depending on the gravity of the project I will spend ample time framing problems before setting direction. So much so that I co-created and taught a class on Problem Framing in The Lab to federal employees.

Problem Framing

In the class we discuss the importance of problem framing and give participants a number of methods to break their problem down including affinity diagrams, root causes analysis, and "How Might We" question framing. Measure twice, cut once. I also discuss a number of problematic problem frames, borrowing liberally from the great work of Stephen Anderson, and adding in some cognitive biases that may cause these problems.

Design Research

I've conducted dozens of stakeholder and user interviews including both qualitative and quantitative research to inform and validate designs. I'm comfortable creating test plans, scheduling participants, conducting sessions, and reporting the results.

Information Architecture

I've done content inventories and analysis for the purposes of normalization and driving teams towards standards as well as understanding the nuances of a problem space. Thanks to my time at EightShapes, I had multiple opportunities to attend IA Summit conferences and learn from the best in the field including a course with Abby Covert. If I'm ever a bit stuck on a project I start with the IA and work my way out form there.

Service Design

As we continue to try to tackle the large beast that is federal hiring I've employed more and more service design tools in order to design more holistically. This involves co-creating stories with, not for, end users. Sequencing events on service blueprints and visualizing with diagrams in order to make the intangible more real. Clearly, I'm a fan of Jamin Hegeman's work.

Complex problems

I've helped clients like Yahoo and Microsoft solve complicated and nuanced problems that required quick and deep analysis to gain a breadth and depth of understanding. I worked on visualizing and managing one of the largest VoIP networks in the world (before cloud was a buzzword) and spent five years tackling federal hiring. I'm not afraid of complexity.

Systems Thinking

Service design taught me to look at the whole journey. Systems thinking is what happens when you keep pulling that thread past the edge of the thing you were asked to design. Most of the failures I've been handed in the last few years weren't failures of a screen. They were failures of the seams between parts that each worked exactly as specified.

Finding the failure between the parts

The clearest example is the VA's Zero Silent Failures work. A Veteran would submit a benefits form on VA.gov, get a confirmation, and then the submission would fail silently in the handoff to a downstream system. No screen was broken. Every component did its job. The failure lived in the space between systems, and no one owned that space. I led a cross-functional tiger team that catalogued 143 Veteran-facing products for that risk, established logging standards and a shared dashboard so the failures became visible at all, and published a design system pattern so every team had a way to tell Veterans what actually happened to their submission. The system now catches hundreds of these a month. The follow-on report I wrote was less about design and more about architecture: shared submission infrastructure, dependency on a single mail portal, and gaps in who owns what.

Designing the conditions, not just the artifact

A lot of my work now is designing the conditions under which other people's design happens, which is a systems problem wearing a design hat. Standards, review processes, tooling, and defaults shape far more of the end experience than any one designer can. When I pivoted a form-building effort away from low-code tooling and toward AI-assisted development, the interesting result wasn't the forms. It was that the constraint had moved: the bottleneck was never the form editor, it was how expensive it was to get from an idea to something real enough to test.

Second-order effects

I try to ask what a change makes easy and what it quietly makes harder. Decoupling the VA's forms library from the monolith it lived in wasn't a design request. It came from watching ten forms break at once because of one undetected deploy, and noticing that the same coupling was blocking a completely unrelated goal, which was letting designers prototype with real form components. One architectural change, two problems. Those connections are usually there if you go looking.

UX Design

Strategy is great, but at the end of the day my strategic plan is doing things. Getting to shared understanding is important, however if design is the rendering of intent and your rendering is poor no one will realize what your intent had been.

Interaction Design

I know the difference between Fitts's Law and Hick's Law, and I think about interactions on a spectrum from touchpoints with goals to micro-interactions that may build a habit.

Communication

I've been working remotely for well over a decade. I know how to present designs remotely, how to make myself available to teammates and clients, and how to stay in the loop on a project. I've got a door I can shut and a structure to my everyday that works for me and my family.

Design Systems

I learned design systems at EightShapes, working alongside the Nathan Curtis who wrote the book on building smaller components into larger systems (and I'm still learning from him). I've been doing some version of design system work ever since. It's the discipline I've spent the most sustained time inside: a fork of the US Web Design System for USAJOBS, and then four years as Product Owner of the VA Design System, which serves 60+ product teams building for Veterans.

Components, patterns, and tokens

The VA Design System covers nearly 70 components and variants plus 37 design patterns across web and mobile. I ran the eighteen-month upgrade that brought it back in line with USWDS v3, got us fully onto web components with React bindings and decoupled the system from the legacy CSS framework underneath it. My team and I moved the design tooling from Sketch to Figma, and defined a repeatable pipeline for turning experimental work into supported components. We've also put our energy into defining semantic design tokens, because they're the layer where design decisions become machine-readable, which turns out to matter enormously once AI agents start writing your interfaces.

Governance and operations

Systems don't fail because the components are bad. They fail because nobody agreed on how work gets reviewed, who decides, and what "done" means. I was Product Owner of the VA Collaboration Cycle, the review process a platform of 60 product teams passes through, and scaled it from 22 touchpoints a quarter to a peak of 84 without loosening the bar. I added engineering and security review tracks so that governance covered more than design and accessibility, and led a revision of the VA.gov Experience Standards to restructure them around user outcomes rather than internal categories. In a recent quarter, 27% of staging review findings were launch-blocking issues caught before they reached a Veteran.

I also think a design system should be able to prove its own value, so I designed and built a public metrics dashboard tracking adoption, quality, and governance trends. As far as I know it's the first of its kind for a federal design system.

Accessibility as architecture

Accessibility is not a review step you pass at the end, and treating it that way is why so many teams keep paying for it twice. Section 508 and WCAG 2.2 AA conformance is a property of the architecture: it lives in the components, the contribution standards, the patterns, and the defaults teams inherit without thinking about it. The most leverage I've ever had on accessibility came from making the accessible path the easiest path, not just finding violations. Being able to read and craft code helps here, since building accessible components requires proficiency in interaction design and understanding the correct, standards-based way to achieve that design in code (and then the patience to deal with the idiosyncrasies of screen readers).

Development

Being able to make things happen on a screen is a critical skill. I've been at it for a long time and thus I'm familiar with the "full stack" required to produce a product or service on the web. I have been on all sides of digital projects: Manager, designer, back-end engineer, front-end developer, QA, and Dev Ops. My working stack is HTML, CSS and Sass, JavaScript, and Ruby — this site is Jekyll (it does the job), and I've been writing Ruby off and on since the Rails era.

Building with AI

This is where most of my recent work has gone, and it's the most fun I've had building things in years. My interest isn't in using AI to make design artifacts faster. It's in building the infrastructure that lets a design system become something an agent can correctly reason about, so that designers who don't write front-end code can still ship something real.

MCP servers

I designed, built, and published the VA Design System MCP server, an open-source Model Context Protocol integration with eight tools covering component lookup, validation, design token management, and Figma integration. The premise is simple: an AI coding agent that can query the actual design system produces VA-compliant interfaces, and one that can't produces plausible-looking guesses. The design system turns out to be the thing that makes the agent trustworthy.

Agentic prototyping

I wrote the product requirements and then built the VA Prototype Kit, a toolchain that lets designers assemble interactive prototypes from real VA Design System components with an agent helping. It took prototypes that were previously a multi-week engineering ask down to days. Ten or more VA designers are now actively using it to produce testable Veteran-facing flows, including an overpayment balances experience that is ready for usability testing. Tools nobody uses aren't tools, so the adoption number is the part I pay attention to.

Skills, prompts, and enablement

Building the tools is maybe a third of the work. The rest is writing the AI Skills, prompt libraries, standards, and training that let other people use them well and consistently — and then running the community practice around it so the knowledge doesn't stay with me. I've also built internal tooling this way, including a product directory that gave leadership the first comprehensive view of what was actually running on the platform, and the design system metrics dashboard mentioned above. Neither would have been worth staffing as a project. Both were worth building once the cost of building them fell far enough.

Prototyping

My background in software development allows me to quickly prototype functional sites, especially when I have a design system to work from. Getting to a real, high fidelity prototype site quickly was the philosophy at EightShapes and it has continued to serve me well. What's changed is the floor: the question is no longer whether a prototype is worth the cost, because it usually isn't a cost anymore.

Static sites

My work can still be seen on smeqa.usds.gov, which I co-designed and built as a guide for HR specialists working through a new hiring process — there's a case study on that project — and on design.va.gov. Turns out simple HTML and CSS sites still work quite well in many contexts.

About Me

I stumbled into Silicon Valley at an ideal time for me (1996) and worked my way from customer service at WebTV through a bunch of positions eventually ending in Senior Software Engineer for Microsoft. I made more friends than enemies and enjoyed that time immensely. I still miss California even though I've been back in DC since 2006. The weather, friends, food, running trails are all hard to beat. I still run and race as much as I can.

I've spent the last ten years in public service and have helped inject human-centered design into our government. I believe that our federal government could someday make evidenced-based policy decisions informed by qualitative and quantitative research done with citizens. There is much to be done to make that a reality however, it's a reality worth iterating towards.

I'm married, a Dad, an avid runner, a soccer fanatic, and played in a band here in DC for many years on Slumberland Records. We still play sporadically and like to spend time in the studio. Occasionally, music has bled into conceptual art. Fluxus is another passion. Ask me about the Fluxus-inspired piece I organized that took place at my best friend's wedding without the knowledge of the bride or groom.