Who We Are
About
Bert Miller
I design systems that have to hold up when the stakes are real.
My background is in regulated, high-consequence environments—medical devices, healthcare software, government-adjacent systems—where design decisions don't live in isolation. They ripple into documentation, training, compliance, translation, support, and operations. If something is unclear, someone eventually pays for it.
That's pushed my work beyond screens. I spend a lot of time untangling workflows, aligning teams that don't naturally talk to each other, and turning vague intent into structures people can actually use and maintain. Often that means design systems, service design, and UX architecture. Just as often it means saying, “this part doesn't make sense yet—let's slow down.”
I'm drawn to problems where things have grown organically, constraints are everywhere, and no one quite remembers why something works the way it does. Not to rip it apart, but to make it workable again.
Dylan Heagy
I solve problems that don't fit neatly into one department's inbox.
My background isn't traditional design—it's building systems that work when the rules are complicated and the stakeholders don't agree. Federal grants. Compliance. Training programs that have to survive contact with real people in the field. Work where you can't hand-wave the details because someone's eventually going to audit them.
That taught me how to map what's actually happening, find the constraints that matter, and build something that holds together when it's stressed. It also taught me that most problems aren't design problems or policy problems or people problems—they're all three at once, and you have to work the seams.
I'm drawn to the kinds of projects where the requirements are a mess, the documentation is missing, and five people have five different answers to the same question. Not because I enjoy chaos, but because that's usually where the real leverage is.
Together
How We Work Together
Most design work starts with assumptions. We start with questions.
Bert excels at taking messy reality and turning it into structure—systems that survive contact with compliance, translation, training, and operations. Dylan excels at understanding what's actually happening before we decide what to build—mapping stakeholder intent, finding the real constraints, and figuring out what people actually need versus what they think they need.
Together, we approach complex problems in two phases: discovery (what's really going on?) and systems (how do we make this maintainable?). Most teams skip discovery or treat systems as decoration. That's where everything breaks.
That's what GRIME is for.