A framework for guaranteeing good UX designs everytime

Ask yourself these 4 questions during each project

After designing hundreds of features and products, I always find myself running a bit on autopilot. Not that that’s bad — often a great way to increase the efficiency of your process is to systemize it!

Find yourself always designing new toggles? Make a UI component you can plug in any time you need one!

Find yourself always designing a table of contents screen for a multi-step onboarding? Save an example of a great one and reuse it for any new product!

The problem as you can imagine starts to rear its ugly head when you accidentally systemize something that needs to be thought about from first principles.

“Well! Here’s another onboarding, I’ll just use my handy dandy table of contents ux pattern here and then…”

…And then the user ends up having a 5 step onboarding for what could just be a single form field asking them whether they wanted cheese or salami (the answer is always the former, obviously).

Here’s a simple 4-step framework to always ensure you deliver great designs in a really efficient manner.

1. How well do I understand the business problem I’m solving for?

Someone says “we’re going to design a new landing page”, or “we’re going to redesign this new user experience”, etc. The first question to make sure you’re not running on autopilot is — if we do this what will it solve for the business?

Maybe it’s an increase in new users. Maybe it’s fewer support tickets. The goal however is to not fall into the trap of designing a beautiful, easy-to-use settings page when the company’s biggest problem is actually new user growth. All this can be avoided by simply making sure you ask yourself question #1.

Simple right? You’d be surprised how often this happens! But enough with boring business stuff, let’s keep going.

2. How well do I understand the user problem I’m solving for?

and subsequently — “do I need more clarity/confidence through research or is speed more important right now?”

Sounds simple again — but make sure you seriously sit down and be critically honest about how much you understand the user’s problem. It’s absolutely ok to say “I don’t know enough”, and to go and find the answer. It’s much, much better to do this than make an assumption that bites you later.

A customer support member says “We should change this dropdown to a toggle.” — do we know where this request came from? Was it a customer? How many customers? What exactly did they say?”

I saw this exact scenario happen between a designer and a member of the customer support team. The designer said “hold on — what exactly did that customer say?”

After asking the customer, turns out she had clicked the dropdown, selected an option, but then wanted to deselect all options and return to the null/empty state. She wasn’t able to because the null/empty state disappeared once you selected an option! This had nothing to do with a dropdown vs a toggle.

Ask yourself this question, and in turn seek more data if your confidence about the problem is low. That is after all, why they pay us the big bucks! (some of us lucky ones, anyway)

3. How confident am I about each step in the solution?

This question is pretty straightforward. How do I know that 5 steps is the right number for onboarding? How do I know that using a dropdown is better than a toggle? How do I know it should be red vs blue?

Asking yourself these questions being honest about your confidence level will help you either ship really impactful products or bubble up the risk of failure to the necessary parties. It’s okay not to be confident about a decision, but the wrong answer is to pretend everything’s gravy while you hide and pray that things work out.

The right answer is to pull other smart people in and help you either build confidence or switch to a different decision.

By doing this you also get the added benefit of stakeholder buy-in — everyone loves to have a voice!

A few optional sub-questions to tag onto this one:

• Do I need to explore more/dream bigger?
• Do I need to validate that the solution is desirable (talk to the user), feasible (talk to engineering), or aligns with our company goals (talk to the product manager)?

4. How do we know if the design was good?

Finally, after everything is said and done — how do you know that your decisions were good?

This can be tricky at times if you don’t have access to analytics, or perhaps you just don’t have time to sit and do a retro. In practice however, I’d strongly encourage you to ask yourself this question after every project — I’ve noticed I level up very quickly by doing so.

Join me for weekly product design insights where I share conversations I’ve had with top designers from companies like Dropbox, what I’ve learned from scaling a Series A startup into the millions in revenue, and more!