How I Work

I use the same six steps on most projects: Empathize, Define, Ideate, Prototype, Test and Build. Here's what each one actually looks like when I'm doing the work.

Empathize

Years of consulting at Accenture and Fairway meant walking into a new client's culture every few months, with no history and no runway to figure things out slowly. That means empathy starts before I even open Figma: I have to earn a client's or stakeholder's trust fast enough that they'll tell me what's actually broken, not just what they think I want to hear. Running research sessions with community college counselors for ASSIST.org taught me most of what mattered was in what they weren't saying directly.

Define

This is where I turn a pile of research into a short, honest list of what actually matters. At Topcoder, the research kept surfacing complaints about individual features, but the real problem wasn't any one feature, it was that the platform was trying to be everything to users who wanted completely different things from it. The fix wasn't more features, it was picking one clear focus and cutting the rest.

Ideate

I'd rather have ten rough sketches on a whiteboard than one polished idea I fell in love with too early. The AI assistant that ended up carrying most of Topcoder's platform started as one of a dozen half-formed ideas for getting people through task setup faster. Most of the best things I've shipped came from combining two decent ideas, not committing to one too soon.

Prototype

Prototype is where an idea gets just real enough to react to, whether that's a rough Figma flow or a few connected screens I can put in front of a stakeholder. The goal at this stage isn't to be right, it's to be concrete enough that people stop describing what they want and start pointing at what's wrong with what's in front of them.

Test

Testing is the step most likely to get cut when a deadline tightens, so I try to protect at least some version of it. When I can, that means real sessions with real users. When I can't, I'll take whatever I can get, drop-off numbers, support tickets, a handful of quick reactions, rather than just going with my own opinion. The goal is simple: don't guess when you don't have to.

Build

This is the step that didn't used to be mine. A designer hands off a validated prototype and an engineering team turns it into the real thing weeks later, with plenty lost in translation along the way. These days I take that design straight into Cursor and build the production code myself, so what ships is the thing we tested, not someone else's reinterpretation of it. It also means I can iterate fast. When something doesn't land right, I rebuild it myself that same day instead of filing a ticket and waiting on someone else's sprint schedule.

Reality Check

If I'm honest, most of my career hasn't happened in the clean version of these six steps. Deadlines move, budgets shrink, priorities shift mid-project, and something almost always gets compressed or cut. That's not the exception for me, it's closer to the default. What I've built over 22 years isn't just comfort operating that way, it's the ability to still land strong, well-considered work when three of the six steps above get squeezed into one week. Knowing which corners are safe to cut and which ones will come back to bite you later is the actual skill, and it's the one no textbook teaches.

PROJECTS

Eric Roodenburg