I design the software for important moments.
Medicare enrollment. Federal financial systems. Voter registration. The tools people have to use at work every day. When this kind of software is confusing, people don't leave for a competitor. They suffer through it. They make mistakes. Or they give up on something they were entitled to. That's the problem I've worked on for twenty years.
I'm Eric Murphy, a product designer in Maryland. Most of my work has been in regulated, high-stakes places like CMS, the VA, NATO, Capital One, and Estée Lauder. Places where the real challenge isn't adding something new. It's modernizing what's already there, legacy systems, layered policy, workflows that made sense twenty years ago, and making them usable without breaking the operation underneath.
What I believe
There's a saying I keep coming back to: design is the rendering of intent.
It sounds abstract. It isn't. Every screen is a decision made visible. If a form is confusing, someone's intent was confused, or nobody's intent was there at all and the screen is just what the database looked like. My job is to figure out what a product is actually trying to do for someone, then make the screens say exactly that. Nothing more.
That's why my mission is simple to state and hard to do: make complexity feel simple.
Not be simple. Feel simple. A Medicare analyst moving billions of dollars needs a dense tool. A 68-year-old picking a drug plan faces a genuinely hard choice. You can't wish that away. But you can decide where the complexity lives. In the policy. In the backend. In the interface. Or in the user's head. Only that last one is a design failure. Good design carries the weight so the person doesn't have to.
Accessibility makes everything better.
I've shipped Section 508 and WCAG work for years. Designing for keyboards, screen readers, and tired brains improves the product for everyone. Every time. Accessible design is just careful design with witnesses.
The cheapest fix happens before anyone draws a screen.
In government and enterprise work, the expensive mistakes come early. A requirement read too literally. A workflow copied from the old system because nobody asked why. A lot of my value is asking the question that saves a team three months of building the wrong thing.
Small teams do the best work.
I work best on lean, high-trust teams where designers own a problem start to finish, from research through shipped code. Fewer hands, more accountability, better products. That's a choice, not a limitation.
How I work
Every project is different. The shape stays the same.
- 01
Learn the system before touching the screens.
Regulated products fail when designers treat policy and legacy systems as someone else's problem. I start by mapping how things actually work. The rules, the data, the workarounds people built to survive the current tools. On MACFin, that meant sitting with financial analysts and translating dense policy before any design started.
- 02
Make the problem visible.
Journey maps, blueprints, workflow diagrams. Not to decorate a slide deck. To get a room full of stakeholders pointing at the same picture. Most alignment problems are really visibility problems.
- 03
Design systems, not screens.
One-off screens rot. I build component libraries, pattern docs, and rules for using them, so screen one hundred is as clear as screen one, and so the team can keep building without me in the room.
- 04
Test against reality, not opinion.
Usability testing, contextual inquiry, expert review. I'd rather be wrong in a prototype than in production. I've killed plenty of my own favorite ideas because five users couldn't find the button.
- 05
Stay through the ship.
Design QA, engineering partnership, testing with real assistive tech. The design isn't done when the Figma file is done. It's done when the thing in production matches the intent. That's the "rendering" part.
Taking on senior and lead product design work in regulated, complex domains. Contract, fractional, or full-time.