UX Design Process

I don't have the answer, I have a process to find it.

Early in my consulting career, I was brought into a meeting about a struggling security application. Throughout the discussion, people kept saying, “We brought in the smee — he has the answer.”

Eventually I stopped and asked, “What’s a smee?”

They replied, “You. The S-M-E. The Subject Matter Expert.” I smiled — and clarified that I wasn’t there because I knew security better than they did. I wasn’t there because I had the answer.

I was there because I had a process. Most broken products aren’t broken because the domain is complex. They’re broken because users aren’t fully understood, the problem isn’t clearly defined, and the team isn’t aligned. What I bring to a project isn’t prepackaged expertise. It’s a disciplined process for uncovering the right problems and iterating toward solutions that work. I don’t arrive with answers. I arrive with a process to find them.

Discover

Without the who and why, we create nothing for nobody

This is the foundation. Before I design anything, I need to understand who we are building for and why it matters — otherwise everything that follows is guesswork. I work to understand users’ goals, motivations, behaviors, and constraints, alongside the business objectives and the realities of the domain. I study competitors, listen for unchallenged assumptions, and look for misalignment. I’m not trying to solve the problem yet; I’m defining the right problem to solve — because without clarity here, design becomes decoration.

Concept

Fail often and fail early.

Sometimes the problem is clear coming out of discovery. Often, it isn’t. This phase helps expose what we may have missed. I begin exploring solutions quickly and broadly, sketching on paper, mapping flows, and generating multiple approaches before committing to any one direction. As ideas take shape, gaps become visible and assumptions get challenged. What looked like the problem sometimes shifts.

Concepting isn’t just about inventing solutions; it is also about uncovering the real problem. I keep the work loose and lightweight so ideas can evolve without heavy investment. Some directions fail immediately, and that is the point. It is far better to discover weaknesses in a sketch than in a fully built product. The stronger the exploration here, the clearer and often simpler the path forward becomes.

Align

Designing an application is easy. Convincing people on direction is the hard part.

Strong concepts do not succeed without alignment. A common misconception is that alignment happens once all the details are worked out, but waiting that long is risky and expensive. I share ideas early with product, engineering, and leadership to test feasibility, surface constraints, and expose blind spots before heavy investment begins. These conversations often reshape the work in productive ways, clarifying trade-offs and defining what success really means. Alignment is not a final presentation; it is an ongoing dialogue that builds shared ownership and reduces downstream friction. When teams align early around the problem and the direction, execution becomes faster, clearer, and far less political.

Detail

The devil is in the detail.

This is where the experience becomes real. I refine user flows, structure information, define interaction patterns, and resolve edge cases that were invisible earlier. I think through hierarchy, states, transitions, empty conditions, and error handling. Every screen must support the larger journey, and every element must earn its place. Small decisions compound at this stage; clarity in labeling, consistency in behavior, and restraint in visual choices determine whether an application feels intuitive or frustrating. Detail work is not decoration. It is where usability, logic, and coherence are either strengthened or quietly undermined.

Prototype

It's cheaper to fail with a prototype than an application.

Static screens can suggest clarity, but interaction reveals truth. A prototype allows me to simulate behavior, test flows in motion, and experience the product as a user would. Transitions, timing, feedback, and conditional logic often expose friction that wireframes alone cannot. What feels intuitive on a static page can break down once movement and decision-making enter the equation. Prototyping brings assumptions into the open and turns abstract ideas into something tangible. It is where design stops being theoretical and starts behaving like a real product.

Validate

What people say, what people mean, and what people do are three different things. What we care about is what they do.

Once the prototype behaves like a real product, I conduct usability testing with real users. I ask what they think will happen before they click, and I watch where they hesitate, recover, or abandon the task. I am testing for clarity: Does the interface communicate what it does? Do people understand the path forward? But usability alone is not enough. I am also testing for utility, asking whether this is something they would actually use and whether it solves a meaningful problem in their world. Clarity determines whether people can use a product; utility determines whether they will. When something fails, I return to the process, refine the work, and test again.

Timeline

The UX design process is not linear.

Although I describe these steps sequentially, real work loops back. Insights from usability may reshape the concept. New constraints may shift alignment. Discovery may deepen midway through execution. The process is iterative by design.