Ask most designers what their process looks like, and you'll get some version of: "Tell me what you want and I'll make it a reality." Unfortunately, they skip a crucial step in the design process, and it can cost their clients big in the long run. They don't mention anything about research, discovery, user mapping, or testing.
That absence is a serious problem. Not really for the designer, but for every client who ends up with a site that looks aesthetically great, but fails in the real world.
This is where UX steps in. A UX process isn't just a step in the design workflow. It's the foundation that every design decision is built on. Here's what that process should actually look like, and why skipping any part of it leaves the client with a product that offers a poor return on investment.
Before any visual design work begins, the right questions need to be asked. Who is the user? What are they trying to accomplish? What do they already know, and what do they need to be taught? What are their current pain points with existing solutions? What does your market landscape look like?
You need to fully understand your user personas before delving into your brand identity and structuring your website.
Now, more often than not, designers will call the "Discovery Phase" a 20-minute intake call. An intake call is important. You need to understand the full scope of the project and the initial brief, but that's not all the discovery phase should be. This phase is structured research consisting of competitive audits and audience analysis, which produces a clear picture of the design problem before anyone touches a tool. This phase exists to make sure we are solving the right problem for the client and their target users. Not just producing a solution that looks good on paper.
User research is where these assumptions get tested. It's easy to design for who you think your user is. It's a different beast, but much more valuable, to design for who they actually are.
This phase involves understanding real user behavior: what paths they take, where they become confused, what language they use, and what motivates them to act. It might include user interviews, surveys, or analysis of existing data. The user-research phase produces a clear output with an evidence-based profile of the person that the product is being designed for.
With the research finalized, the next step is mapping out the structure. Information architecture defines how content and features are organized. User flows are defined as paths a user takes from entry point to goal completion, and identify every place along the way where the user might drop off.
This is where (my favorite UX principle to talk about) cognitive load theory comes into play. How much information is the user being asked to process at each step? How many decisions are they being forced to make? Where is the friction, and how do we reduce it? These questions don't have visual answers quite yet. However, these questions determine every visual decision that comes later.
Once the research and architecture work is complete, then we may begin the visuals. This starts with wireframes. Bare bones. No UI. Just the wireframe.
Wireframes strip away color, imagery, and typography to focus purely on layout, hierarchy, and flow. Does the structure work? Can users find what they need? Does the page guide them toward the intended action?
From wireframes, the design moves into interactive prototypes (boy do I love Figma for these steps). The prototype is a clickable, navigable version of the product that can be tested with real users before the development phase.
Don't skip the prototype phase; it saves you so much money and time in the long-run.
This is the step that almost everyone skips. Some skip it because the client doesn't have an interest in testing, others because they lack the wherewithal to do so. A prototype without testing is just an assumption. Albeit a solid assumption backed by research, but an assumption nonetheless. Usability testing puts the design in front of real users (or representative users) and watches what happens. Where do they hesitate? What do they click that wasn't expected? Where do they get lost?
Testing before development is exponentially cheaper than fixing problems after launch. We can easily fix any potential issues in the prototype phase. It becomes a bit more difficult to fix these issues after we've developed and launched. Not to mention the users who abandon you forever due to the initial frustration with your untested product. This is the step that separates designers who are confident in their work because it looks good from those who are confident in their work because they've proven it works.
When a designer skips discovery, they build for assumptions. When they skip research, they design for the wrong user. When they skip wireframing, they paint walls before the blueprint is done. When they skip testing, they ship problems they could have caught for free.
The result is what you see all over the internet: sites and products that look polished but convert poorly, frustrate users, and end up needing to be completely rebuilt within a year or two. OOFTA — not wallet friendly.
With AMUX Designs, this process isn't a premium add-on. It's ingrained in how I work. Because building something that actually performs requires knowing what you're building before you build it. If that's the standard you're looking for, let's talk.
