Creating Great Designs: Ways to Overcome Uncertainty in UX

In my early days as a UX designer, I was taught that you must follow ALL the steps of the textbook UX process to a T.

Research → Define → Design → Validate → Ship.

What a lovely thought. Neat! Linear! Predictable! But as we all know, that’s rarely how projects go.

In reality, we’re often asked to move forward with little to no research, without a full understanding of the user, or while the technology and requirements are still shifting. Sometimes the business goal itself is still evolving, or engineering is still figuring out what is technically possible. Maybe stakeholders are aligned in theory, but not actually aligned once you start putting ideas in front of them.

We’ve been conditioned to see this as “bad UX practice” in the industry. But the more products and projects I’ve worked on, the more I’ve realized a hard truth: 

Uncertainty is part of the UX process.

But that isn’t necessarily a bad thing. In fact, when you work with uncertainty instead of against it, it can actually benefit the end product. I know, I know. That’s easier said than done, but there are some ways to make working with the unknown easier. Here are the tricks I’ve learned for embracing uncertainty during the UX design process.

1. You Don’t Have To Wait for All the Facts To Get Started
   
   When it comes to UX, there’s always going to be something you simply don’t know.
   
   “I need more user research or data.”
   “I don’t know every single product requirement.”
   “I need to understand the full tech stack and requirements before I can design thoughtfully.”
   
   Yes, those things are important. Yes, you should push for them when you can. But sometimes, you have to move forward before everything is perfectly clear. This isn’t about skipping research or throwing strategy out the window. It’s about accepting that if you wait for perfect understanding, you’ll never start.  
2. Not All Unknowns Are Equal
   
   When I begin working in uncertainty, one of the first things I do is separate “What do we actually NEED to move forward?” versus “What just feels uncomfortable not knowing?”
   
   Let’s say I’m designing a dashboard landing page for a coffee shop owner. 
   
   I may not know the exact charts and widgets from the start, but I can start designing the structure based on what I do know. I can start thinking through things like: what should they see the moment they log in? Today’s sales? Inventory alerts? Employee schedules? Something that tells them, very quickly, whether things are going well or if there’s a problem they need to deal with.
   
   What I need to know is what the owner actually cares about when they open the dashboard. Are they opening this every morning for a quick check-in to make sure nothing is on fire? Or are they sitting down once a month to analyze trends and make business decisions? Or honestly… is it both?
   
   A quick, scannable daily check-in dashboard should feel very different from a deep analysis and reporting dashboard. One is built for speed and clarity, while the other is built for in-depth decision-making.
   
   All of this to say, not every unknown has to stop your momentum. Knowing when to move forward and when to ask for clarity is really the trick to making progress.  
3. Design with Assumptions - On Purpose
   
   Another no-no in UX 101 is to never make assumptions about the user. Of course, you should gather as much research and answers as possible beforehand, but even in the most ideal situations, you still have to make some assumptions.
   
   That’s where assumption mapping comes in.
   
   Instead of pretending we know everything, assumption mapping helps us document what we’re assuming now, so we can validate and test it later.
    
   • First, it allows you to design without blockers. Rather than stopping every five minutes to say “oh, we don’t know enough,” you can say, “For now, we’re moving forward with this assumption.” 
   • Second, it gives you a clear list of what needs to be validated later, whether that is in stakeholder review sessions, usability testing, analytics or post-launch feedback.
   Assumption mapping makes uncertainty visible. Designing purposefully with assumptions turns it into something you can actually work with. Because once something is on the page, people react. Questions come up faster. Gaps become obvious. Conversations get more specific.  
4. Embrace the Power of Iteration
   
   Not everything needs to be final. 
   
   Like a lot of designers with perfectionist tendencies, this was a shift that took me a bit too long to accept. But it completely changed how I think about design and product development. 
   
   We put a lot of pressure on early designs to be “right,” fully thought through and impenetrable. 
   
   This mindset will simply slow you down. Instead, I design something knowing that it will ALWAYS change. Maybe it will change in two weeks during the internal review call. Maybe it changes after technical limitations come up. Maybe it changes post-launch, once you realize users are behaving differently than expected. Maybe it changes two years from now when design trends have changed and parallax and liquid glass UI are all the rage.  
   
   Start by ideating quickly, then eliminating your ideas even faster. As you do this, you’ll start understanding what feels promising, what’s not working and what questions continue to come up. And this is how you can actually make progress instead of constantly aiming for perfection.  
5. Build an Internal MVP
   
   I’m a big believer in MVPs. And I’m not talking about the MVP that feels like a money-grab beta launch. You know, the one where the app is technically live, but is so buggy or incomplete that users are basically unpaid QA testers.
   
   What I mean is building an internal MVP. Something good enough to test internally, validate the direction, and learn from before it matters externally.
   
   Stop trying to create the perfect solution on the first pass; instead, focus on quickly getting to a strong, testable direction. Consider how you can build ideas that are good enough to test internally and validate. It’s a safer space where you can move fast, break things and refine them before it really matters.
    
6. Launch Is Not the Finish Line
   
   Even after your product ships, the iteration begins again. Post-launch is when you finally start learning the truth about where users get stuck, what they misunderstand, and what ends up mattering way less than everyone thought. We’ve all been there when a feature the team debated about for weeks barely even gets touched by the users.
   
   Launch is not a finish line, but the beginning of your feedback loop. You now have more answers to continue improving your product. And by accepting a mindset of continuous, planned iteration early in the design process, this shouldn’t feel like failure or rework. It just becomes part of the process.  
7. Reframe Your Perspective, and Your Stakeholders’ Too
   
   Now you might be thinking, “This all sounds great in theory, but how do you actually get buy-in from leadership or stakeholders to work this way?”
   
   The honest answer is: you can’t always. Not everyone is comfortable with uncertainty. Not everyone wants to hear “this will evolve over time.” But how you frame the work can make a huge difference.
   
   If you position a project like:
   “We’ll deliver the first set of designs by this date. You’ll have two days to review. We’ll do one round of revisions. Pass it off to you. Then we will start the next set. Repeat.”
   
   You are trapping yourself. You’re telling them that Friday's presentation is the "final answer," which makes everyone, you and the client, sweat. Every decision feels like a permanent commitment.
   
   I’ve found it’s much better to frame it as an iterative process: 
   “Our goal is to get to a high-fidelity MVP by this date. We’ll start with an initial set of designs, then continue to iterate and refine based on what we learn each sprint, using those learnings to evolve toward the final experience.”
   
   This is the same timeline, but now you’re not promising perfection at every stage of the process. You’re promising thoughtful progress towards a quality product, knowing that you’re always able to iterate and improve. Most stakeholders are actually relieved when they realize they also don't have to get everything 100% right on the first pass either.
   
   That shift alone makes it easier for teams and stakeholders to accept iteration and change as part of the plan, not a sign that something went wrong.

The UX design process will be messy, ambiguous and constantly shifting. And instead of fighting that, we’re better off designing for it. The goal isn’t to design in perfect conditions. It’s to design despite them.