What Is My Design Process?

Design thinking. Double Diamond.

These were the two design processes I learned when I first started in digital product design.

Both of them had a clear structure and steps to follow.

And I was sold.

I love structure. Following a clear “5-step process” - that’s my jam. So, I’ve been using a similar framework for both my portfolio & case study presentations.

Yet, the more I thought about the “design process,” something feels off. I realized - I have been blindly following the standard process. I never asked myself:

What’s the point/purpose of a design process?

So, I took time to pause, do research, and ask myself:

What is a design process that speaks to me?

Because of this, I think I have discovered a design process that speaks to me.

But, before I share my new design process, I want to share how I got there.

The Three Inspirations

Product Development Flow | Gitlab

This article, recommended by Gina Doyle, led to this train of thought in the beginning.

Gitlab's product development flow
Source

In this article, you can focus on the left section (Validation Track).

Gitlab's product development flow with the validation track highlighted

For the first time, I learned a process that doesn’t look like design thinking or double diamond.

Now, it’s true that, on an abstract level, all these processes may be similar.

But this one speaks to me so much more because of one word:

Validation.

You see - designers are humans. We all have assumptions, and that’s okay. But what’s not okay is when a designer follows their assumptions without any sort of…wait for it…validation!

This perfectly aligns with what my past Roblox mentor - Sophia Song - said:

You research because you want to validate your assumptions and hypothesis.

Now, remember what a hypothesis is?

You probably didn’t think I’ll mention a scientific term in a design blog. But it does make sense, which brings me to my next inspiration.

How We Design for Growth At Strava

This article, written by Paolo Ertreo (Design Manager at Dropbox’s Growth team) is fascinating.

He describes his process of creating lean experiments to validate the team’s hypothesis quickly with the following process:

  1. Defining hypothesis (North Star & KPIs/metrics)
  2. Designing quantitative experiments / leveraging qualitative data
  3. Releasing experiments
  4. Evaluating experiments
  5. Graduating experiments

This blew my mind because what Paolo described is the scientific method.

It’s probably been a while since your elementary science class. So to recap here’s a graphic of it:

The scientific method
Source

Also, Paolo embraced experimental design by having a control and variant for their A/B tests. For example:

A control vs a variant comparing different strava log in designs
Their hypothesis was that surfacing signup options immediately upon app load would increase overall signup rate, especially through Facebook | Source

Lastly, since the previous articles are more technical, the final inspiration is about design philosophy.

Jamal Nichol’s Design Philosophy

Jamal is currently the Senior Design Manager at Careem. Before this, he worked at Facebook as a Senior Product Designer.

At the bottom of his portfolio, Jamal stresses that every product he works on has to solve three fundamental questions:

What people problem are we solving?

Framing up the problems we're solving as people problems align our work with the communities we serve.

How do we know if this is a real problem?

What research or data do we have that confirms that this is a real problem that is hurting customers and hurting the business?

How will we know we’ve solved the problem?

To know we've solved the problem, we need to define what success looks like and how we will measure it.

So clear.

Jamal’s design philosophy answers a question I’ve had for so long:

What’s the point of all these different steps?

It’s what Jamal highlighted - to answer the three fundamental questions:

  1. What people problem are we solving?
  2. How do we know if this is a real problem?
  3. How will we know if we’ve solved the problem?

So, What Is My Design Process?

Now, the big reveal.

Before specifying the design process, I want to lay out the design principles for the process:

People first

I’m a digital product designer designing for real people. People are always first.

Intentional

I don’t want to blindly follow any standard process. I want to be intentional with the process & methods I use to gain meaningful insights.

So, based on the inspirations I noted above and after much thinking, here is my new design process:

  1. Problem validation
  2. Design
  3. Solution validation
Wait Guo... What about "empathize", "define", "prototype", etc.?

I hear you. But the beauty of this process is that each step is a collection of "stages." For example, with design thinking in mind, problem validation consists of empathize and define.

Also, it’s important to note that the types of activities and depth of research will depend on how well I understand the user problem and solution.

1 - Problem Validation

Goals

  1. Understand what people problem we’re solving
  2. Validate the problem - is this a real problem?
  3. Identify business goals & key metrics to determine success

Notice how these align with Jamal Nichol’s three questions?

When

When my confidence in the proposed problem isn’t high.

Methods

  • Opportunity Canvas
  • User interviews
  • User surveys

2 - Design

Goal

Ideate different potential solutions. Identify the approach(es) that strike the best balance of UX, user value, business value, and development cost.

When

When I want to ideate solutions based on insights from the problem validation stage

Methods

  • Crazy 8s
  • Journey maps
  • Wireframes/sketches

3 - Solution Validation

Goal

See if our proposed solutions solve the people problem

When

When my confidence about the proposed solution isn’t high.

Methods

  • Usability testing
  • Tree testing
  • Card sorting
  • Feedback capture grid

Conclusion

You may have noticed that I didn’t write detailed notes for each stage.

This is because in the future, once I tried this new design process for a while, I may write a much more in-depth article.

At least at the moment, this structure makes a lot more sense to me.

Now, I want to preface that my design process is not perfect, and it may change. Yet, no matter what, I believe it’s beneficial to think about topics like this.

And that’s a wrap!

Thank you for being awesome and reading this far! :)

If you have any questions, feel free to reach out on LinkedIn, Twitter, or by email. Will love to set up a casual call and chat!

Read Next