Section 1: Four parts of design

For context, and before we get into the actual project, we need to talk about the process. There are four fundamental phases of UI/UX design that occur in a real-world production environment. These phases are:

• Discovery
• Design
• Validation
• Delivery

Let’s go over each of them in a little more detail.

Discovery

In the discovery phase, you are actively seeking to understand the design problem better.

• What problem are you trying to solve?
• Who are you trying to solve it for?
• How do you know that it’s a problem?
• How do you plan on solving their problem in a way that nobody else does, that leaves them feeling great?
• Are your users willing to pay for your solution?

These are the four hallmark questions of discovery, and you need to be able to answer each of them in as much detail as possible so that you can translate your findings into real, actionable insights.

Typically, your problem will start off as a question or statement of observation by a client or stakeholder that has noticed a problem:

• “Wouldn’t it be great if ____________________?”
• “You know what sucks? _____________________________.”
• “I’ve noticed that people have a problem with _____________________.”

Once you’ve heard these words, or some variation of them, you have been given your initial problem statement.

This problem statement represents one of two hypothesis:

1. The problem hypothesis, and
2. The solution hypothesis (we’ll go over this one in the design phase).

The problem hypothesis is what your client or stakeholder assumes the problem to be for your target users.

Using this initial problem hypothesis, we conduct preliminary user research to determine if this problem is actually a problem, and if so, the details of the problem from the perspective of our users.

From there, we move into gathering business requirements, understanding the deliverables, additional work roles, and performing a smoke test.

• Business requirements: what information and results does the business need in order to create this product effectively? ROI, KPI’s, goals, metrics of success, up-front costs, etc.
• Understanding deliverables: what all does your application need to deliver, and who does it need to deliver it to? Tangible outcomes, intangible outcomes, associated/consequential outcomes, etc.
• Jobs-to-be-done: what all do your users need to be able to reasonably do within your application? Create documents, buy clothes, etc.

• Additional work roles: who all is going to be using this app, what capacity do they need to be able to use it in, and what information are they going to need access to? Normal users, administrators, license holders, business partners, etc.
• Smoke testing: are the people who will be buying this thing (target customers) actually interested in buying it for the price-point you’re offering it at? Are people willing the press the “buy now” button?

Don’t worry if this seems like a lot, we’ll get into all of this in super granular detail later, I just want to make sure you have a clear picture of how it all fits together.

Design

Once we’ve gotten to the bottom of who needs what, and confirmed that the problem hypothesis is supported by real users, we can safely move into designing our solution.

Now, in the design phase, you’ll have several parts:

• Ideation/Concepting
• Content strategy (including UX copywriting)
• Information architecture
• User-flowing & Wireframing
• Prototyping

Let’s break these down a bit further.

Ideation/Concepting

In this step of design, you’re literally just spitballing ideas to get as many of them out as possible. Do this with your whole team!

Stand in front of a whiteboard, and sketch what people talk about. Let other people sketch their own ideas. You can even do this virtually using tools like Figma Jam to make it even easier.

Don’t feel like you have to use any of the “right methods” to make this happen either. Give everyone a turn to speak and share, and you’ll be surprised with all the good ideas you come away with.

Content strategy (including UX micro-copy)

Once you’ve got your ideas for approach picked out, you’ll want to deeply consider your content, which is the main things that users will see and interact with in your app.

Without content, your application is essentially just an empty husk.

• What will your user see?
• Why will they see it?
• What should their takeaway be from this information?
• Why should they care about it?

This content includes images, illustrations, animations, and both regular & micro-copy.

Let’s talk for just a second about micro-copy in UX: micro-copy is essentially small amounts of text data that is used to communicate with your user.

Examples include decisions such as labeling your “submit” button for your forms to something more descriptive like “send message” depending upon what communicates the functionality most effectively.

Information architecture

From content strategy, which is what your user is going to see and what information you’re trying to convey to your user is, information architecture (or IA for short) is where a user will be able to find this information within your application based on their expectations.

So how do we find that out? By running a hybrid card sort with your users and seeing what they come up with.

The reason card sorts can be so effective, is because they can help you see how your users think in terms of where they will reasonably expect to find certain information in your system.

If you can’t do that right at the beginning, don’t worry, you can take a solid guess with you and your team at first, but just make sure that you refine this as you go along.

User-flowing & Wireframing

Once you’ve got the content and IA nailed down, you’ll want to focus on designing user-flows and wireframes.

A user-flow is a flowchart that showcases how a user will get from where they are to their desired outcome within your application.

Wireframes, on the other hand, can show rough layouts, interactions, and states that your application can be in while your users are working with it.

An approach that I personally like to use, referred to as “wireflows,” combines the above two methods into a single document which show both what a user is doing, where they will be routed in your application, and the various things they will see at a high-level.

Prototyping

Once you’ve got your flows and wireframes taken care of, they’re looking good, and your team feels good about them, it’s time to take it to the next level with prototyping.

Now, prototyping can happen in multiple levels of fidelity (lo-fi, mid-fi, and hi-fi respectively), each of which serves to better demonstrate what the actual application will look and feel like in it’s final form.

• Lo-fi prototypes: these types of prototypes are used to get a good feel of the general layout and flow of your product, without going into too much detail.
• Mid-fi prototypes: these types of prototypes are used when you and your team have a pretty good idea of what you’re looking to create, and include more content, interactions, states, and transitions.
• Hi-fi prototypes: finally, these types of prototypes are used when you need to both know and show exactly how your application will look and feel when it is released to the public.

Personally, I almost always recommend sticking to low/mid-fi’s until you’re closer towards the very end of your design process, and then moving to hi-fi’s after all your preliminary modifications and revisions have been completed, so you’re not having to do a bunch of extra work for no reason.

Validation

After you’ve completed your hi-fi prototype that will constitute what your product will actually look and feel like in the real world to the best of your ability, you’ll want to validate it.

This is done through four major distinct methods:

• Usability testing — checking to make sure the user can actually use the system you’ve designed to get to their desired outcome(s).
• User interviews — talking with users to see how they feel about your solution (but NOT if they “would” buy it, users are horrible at predicting future behavior, so don’t even ask that question).
• Contextual inquiry — observing how users use the solution in their natural context of usage and asking them questions as they move through their process.
• Surveying — either to ask users their opinions in mass, or to debrief users who have worked with your prototype to see what their takeaways were.

Additionally there are three types of usability test that can help you garner actionable insights

• 5-second test —show the user the application for 5 seconds and ask them what they think it is, and what stood out to them the most.
• Walkaround test — let the user work with your application and do whatever they want to do with it, exploring at their own pace.
• Essential task test — ask users to complete essential tasks and perform actions necessary to get to their desired outcomes.

In the validation phase, what you’re trying to ascertain is:

1. Does your proposed solution work well for your users?
2. What works well, and what needs improvement?
3. Do your users like your solution hypothesis and presentation?
4. Do your users feel comfortable, cared for, and like the product was designed for them?
5. Do your users feel like your solution is better than anything else that they’ve seen so far?

This is what it takes. Your solution must be so good in its niche, that your users can identify it as best in it’s class. Runner-up is not good enough anymore, you need to aim for being first in their minds.

So when validating, you want to be listening not just for unsolicited “high praise” or what you want to hear. Be listening for the downsides, what people hate about your proposed solution, why they think it’s a good idea, or why they think its a terrible idea.

Clear, direct, and honest feedback from your users is what validation is all about, and the better quality of feeback you get, the better you can design your product.

Delivery

In this final phase, you will be documenting your design, and creating the final deliverables that you will handoff to your development team.

These include things like:

• Final prototypes
• Style guides
• Pattern libraries
• Design systems
• Product specifications
• Notes & annotations

The job of these documents is to clearly convey the who, what, where, when, why, and how of your product to your development team in a declarative fashion.

You want your devs to know each screen, component/app states that they can expect, things that they’ll need to consider, and additional specifications that can influence the way that your product will be developed.

As an example: if there are areas in your design where you want to make sure your devs understand better, put comments there and annotate the heck out of it.

Don’t be afraid to be as thorough as possible, because while it is a ton of work in the last stretch for delivery, it is where all of your design efforts are collated so that they can come to fruition down the road.