Chapter 2: Process

A common design process you'll find amongst design teams is what's know as the 4 Ds; Discover, Define, Design and Deliver. This process is also known as the double diamond method and follows closely with the design thinking methodology. This linear process builds upon each step and supports the success of launching a product.

It’s important to note that there should be a high level of collaboration among stakeholders in each phase of the process. You'll hear the saying "get feedback early and often" so you can iterate on designs. This allows teams to work quickly and efficiently because issues will surface and resolve earlier. This saves time that could be spent designing better solutions that fit the needs of the user and business.


During the discover phase, you're trying to gain insight into the problem you are solving for. This is where you'll be performing user research and conducting user interviews to gather feedback to better understand pain points. You'll collect a bunch of data on the product space, target audience, competitors and more. You'll might also identify a problem statement, hypothesis statement and assumptions about your users. Creating these assumptions allows you to test against them to better understand what you're trying to achieve and for whom.

Here's what a problem statement looks like: "[Our service/Product] was designed to achieve [these goals]. We have observed that the product/service isn't meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?"

Here's what a hypothesis statement looks like: "We believe [this statement is true]. We will know we're [right/wrong] when we see the following feedback from the market: [Qualitative feedback] and/or [quantitative feedback] and/or [KPI indicator change]"

Here's what user assumptions looks like:

  • Who is the user?
  • What is the user doing just before interacting with the product?
  • What problems does our product solve?
  • When and how is our product used?
  • What features are important?
  • How should our product look and behave?


The define phase is where you'll identify the core problems you are solving for and identify your MVP (minimal viable product). Project documentation will also be created, such as a Statement of Work or Product Requirements Document, that help align stakeholders and outline project specifications. This phase should consist of defining the information architecture and it's hierarchy as well as user flows and personas.

When I create my product requirements document, I follow this simple outline:

  • Name of project
  • Stakeholders
  • Goals
  • Assumptions and Questions
  • Sitemap with a high level overview of pages and their components/features

Defining information architecture and hierarchy isn't too difficult. It's all about identifying what content you need, whether that's text, images or call-to-actions, and in what order they should be placed. For example, if you have an About page for your portfolio, you know you'll want to have a picture, a brief description and maybe some social media and email links. You'll need to identify that this is all the information you want on the page and in what order.

User flows are a way to understand how a user might move throughout your application. There's a fantastic article written by Ryan from Basecamp about a shorthand method of creating user flows. This is what I use to create mine, whether I'm writing it down in a notebook or creating it using Omnigraffle.


The design process is where you get to start designing user interfaces. Initially you'll start with simple wireframes to help generate layouts, identify pages and sections to better understand the complexity of your product. Low fidelity wireframes are simple sketches of a design, generally just boxes inside of boxes to demonstrate where things would be placed in a design. Higher fidelity wireframes include real text and images.

Once wireframes have been completed, mockups are next. Mockups are essentially the high fidelity wireframes with an applied style guide to make them look pretty and on-brand. After the mockups are complete, you can start prototyping your designs. A common way to quickly test designs and their flow are click through prototypes using tools like Invision. Basically you create hotspots on your designs that link to other screens. For example, I might create a clickthrough prototype to test my navigation on a website, so for each link in the nav, I'd create a hotspot and link to it's appropriate page. Yes, this means creating lots of screens, uploading them and manually linking them. It's not as bad as it sounds and is pretty straightforward.

Tools like Framer are being used more and more for its ability to test responsive design as well as animation. It utilizes code to handle the animations, which is basically how you would do it in CSS. There are many prototyping tools and will vary team by team on usage.


The deliver phase is where you hand off your designs to be implemented by the development team. Working closely with the product or project manager, you'll need to create a proposal for your designed solution. This proposal is meant to document your solution and help others understand what you've created. The template I use clearly defines what problem we are trying to solve, the goals, strengths, weaknesses, behaviors, high resolution image assets as well as any prototypes. Not only does this align stakeholders on a solution, but it's also used by the developers to help build it.