This site is a simple UI/UX checklist, dedicated to helping you take your next project from zero to done as smoothly as possible.

Who this site is for

This site is for anyone engaging in UI/UX activities as an independent practitioner or as part of a product design team.

It is free to use and always will be.

Why you should care

Good UI & UX is a lot like air. You normally won't notice it; but when it's not there, you become very aware!

Here's the rub: if a product these days doesn't have good UX, no one is going to use it. Why? Because there are a million other options out there in an absolute sea of competition, Jimmy, that's why!

Your customers don't need you, you need your customers, and that's one of the main reasons why UX exists: to help you engage with your customers on the level of their individual experiences with your product or service.

UX, therefore, is never a waste of money. It's the cost of creating a highly-valued product, and by extension, brand.

What this site can help you do

This site is here to help you answer the following questions:

  • What are you making?
  • Who are you making it for?
  • What specific problems are you trying to solve, and for who?
  • How do you know that what you think is a problem is actually a problem for your users?
  • Why should users care about your solution?
  • What is your solution's clear competative advantage?
  • What do your users need to be able to do with/within your solution?
  • Do users like your propsed/applied solution?
  • Are users willing to pay for your solution?

The answers to these questions are designed to help you avoid the following pitfalls:

  1. No market need for your product/service(s).
  2. Scope creep of initial project leaves you dead in the water.
  3. Users don't care about your solution.
  4. Solution is not profitable and your company fails.

UI/UX Process

The following is a simple, but comprehensive list of the major steps which you can take when designing the experience and interface of your product.

As a first step, you'll want to clearly define your problem.

Your goal is to interview your team, stakeholders, figure out what exact problem you're trying to solve, who you're trying to solve it for, and the context of the problem in general.

What you are attempting to figure out:
  • What exactly is the problem?
  • What would you be making?
  • Who would you be making it for?
  • What specific problems are you trying to solve, and for who?
  • How do you know that it's a problem? (We'll come back to this in step two).
What you'll do in this step

In this step, you will be validating your problem hypothesis against people who will actually use the software.

Normally, this problem hypothesis will come from defining your problem via a stakeholder telling you a problem that they have, or that they have noticed, which they are interested in creating a solution for.

As an example of a problem statement:

"We believe that users dislike/have a problem with _____________________, and we believe that by doing ____________________ and delivering them a solution that _________________________, we can help them solve their problem."

Remember: you want to state the problem as you understand it clearly so that you can easily communicate it to others,
and validate it when asking users about the problem itself.

What you are attempting to figure out:
  • Is the problem stated by the stakeholders really a problem for actual users?
  • That is, "do users really dislike/have a problem with ______________________?"
  • Should we even concern ourselves with trying to build a solution for this problem?
What you'll do in this step
  • User discovery interviews
  • Collation of data
  • Answering the questions: "is this actually a problem," and "should we build a solution for it?"

In this step your goal is to identify what users value the most when looking for a prospective solution to their problem.

After you have verified that, "yes, this is in fact a problem for people," you need to figure out what outcomes, relevant features, pain-points, and barriers for your users are, with resepct to how they currently solve the problem.

What you'll do in this step
  • Figure out how users currently solve the problem.
  • Figure out what users are looking for in a solution.
  • Determine tangible, emotional, financial, social, etc. outcomes that users need/want from a solution.
  • Gain a deeper understanding of the context of the problem itself.
Some specific questions to ask
  • Why does this problem exist for users to begin with?
  • Why do users feel the need to engage with this problem currently?
  • How do users currently feel when attempting to solve this problem?
  • How do users want to feel when and after solving their problem?
  • What other obstacles do users face on their way to/from their current problem?
  • What devices do our users like to use or use often as part of their workflow?

In this step, your goal is to analyze your data, plan for, and begin to conceptualize your product.

What you'll do in this step
  • Deeply look at and analyze your competition with their assosiated offerings.
  • Create 2x2's where you can identify areas of value in which users are currently underserved.
  • Locate the biggest, least expensive problems that you can fix, and emphasize those in the product design specifications.
  • Plan for content, information architecture, and how the application will be laid out logically.
  • Create a critical task inventories based on user types or work roles that will be interacting with your product.
  • Begin sketching, scaffolding, wireframing, flow-diagramming, journey mapping, and ideating on initial product concepts.
  • Talk with your team about timetables, projections, project roadmaps, and milestones.
Some specific questions to ask
  • What have our users said and done in our observations?
  • What do our users like? What do they dislike? What and where are their pain points?
  • What should our product look and feel like?
  • How should our product behave for our users?
  • What platforms does our product need to exist on or support?
  • What design principles do we want guiding our process?
  • What do our features look like based on our necessary outcomes?
  • Is there anything that we want to or should avoid doing or emphasize doing?
  • How can we differentiate our product on the open market based on what our users need/want?
  • Why should users ultimately care about and what to use our product?
    What is our product's clear competative advantage?

In this step, you'll begin actually fleshing out your plans as designs. These can take quite a few forms including:

  • Wireframes/wireflows
  • Lo-fi mockups
  • Hi-fi mockups
  • Interactive prototypes
  • Design documentation
  • Pattern libraries and design specifications

The goal here is to get your designs to a spot where they are reasonably representative of what the final product will look, feel, and behave like for your user.

Some things you should know
  • The blueprint is never the house. Your designs will always change when implemented by dev, and that's normally okay;
  • So long as those changes do not negatively affect the UX of your product,
  • Which you will find out down the road,
  • And can stress the importance of to your developers after vetting it with your users.
Some rules to live by when designing an interface
  • Keep it STUPID SIMPLE. People don't like complicated, people don't use complicated.
  • Back up your design decisions with data. Most of the time users don't care, but when they do, make SURE you take note of it.
  • Get constant feedback throughout the process and make it visible. Show your team what you have in mind.
  • Design with a base-spacing in mind. When in doubt, use 4px/.25rem (16px = 1rem) as your base measurement.
Couple of warnings:
  1. Please do yourself a favor and create your design system in something like Figma if you can (makes it way easier later).
  2. Back up ALL of your files early, and often. If your organization does not use DropBox, tell them they need it.

In this step, your job is to make sure that your proposed solution delivers the desired results to and for your users.

BE AWARE: this is not UAT (User Acceptance Testing), and we are not asking: "does this thing work?". No, we are asking:
"Does this solution work well for our users, while delivering them the results they need and expect, in a way that is satisfying?"

That's it.

The 4 major test types

Note that each of these tests will help you derive a different type of data that you can use to help improve your solution.

What you attempting to discern by testing
  • What are users saying, what are they doing, and how are they doing it?
  • Where are they slowing down, bottleknecking, or getting stuck?
  • Where are they getting frustrated, upset, confused, or are ASKING YOU FOR HELP DURING THE TEST?
  • How satisfied are your users with the proposed solution?
  • Do they like it? Do they hate it? What about it do they like, hate, and are neutral about?
  • If they could change anything, what would they want to see changed?
  • Would they recommend this solution to a friend or colleague?
Some things to keep in mind while testing
  • Record everything. Trust me, you may need it later.
  • 3-5 users per testing round is plenty, don't overdo it.
  • When recruiting users, do your absolute best to get people who are representative of your actual user base.

In this step, you will be delivering your final design files to your development team.

The files that you'll be delivering
  1. Interactive prototypes
  2. Hi-fi mockups
  3. Design specifications (redlines)
  4. Design system documentation
  5. Pattern/component libraries
  6. Style token libraries (more advanced)
  7. IA diagrams
  8. Implementation notes
What you're trying to communicate
  • What the product is supposed to look like
  • How the product is supposed to behave
  • What all the pages/areas/scope of the product are
  • What the relationship between aras of the product is
  • How a user moves through the product
  • Necessary outcomes for the user
  • Rationale for important design decisions

In this last, but ongoing step, you will normally be working with dev and marketing to come up with new features/offerings that can help expand your product's market reach.

These activities will include continuous improvement & innovation of existing products through usability testing, iterative design, and implementing changes to your product as you find things that need to be changed.

What you'll do in this step
  • Talk to marketing about product reception
  • Talk to dev and QA to make sure features are working correctly
  • Interview your users and perform usability tests to make sure those features are working well
  • Keep looking for ways that you can actively improve your product and add to its value.


This section is here to help you troubleshoot some common UI/UX issues that you may encounter.

No one is buying our product, what should we do?

Tweak your value offering, make sure you're marketing to the right audience, and try again.

Our engagement levels suck, how can we make them better?

Spend more money on advertising; implement user feedback early and often.

We're not meeting ROI, how can we improve market penetration?

Horizontal scaling is your best friend. Go wider and push hard for better brand awareness.

We're not meeting _________ KPI, how do we fix that?

Design your product so that your KPI can get hit, don't just arbitrarily assign a KPI just because you need a metric.

Our product isn't meeting QA standards, what should we do?

Talk with your designer and have a collaberation session between design, QA, and dev to get it sorted out.
You'll want your PM there for that conversation as well.

Our product isn't meeting milestone deadlines, how can we fix that?

Find the bottlekneck. This is normally in the form of being short-staffed and can be resolved by assigning more people to the product team and making absolutely sure that they know what they're going to be working on, when they'll be working on it, and when you need it by.

Get the checklist

You can download a comprehensive checklist that I use for almost all of my projects here:

Download Checklist