My Design Process

2021-10-02

In the design world, a small industry has grown around selling the “perfect” design process. People write books, make courses, and argue online about the best way to design things.

The truth is simple: there is no single perfect process.

Different designers work in different environments. What matters most is having a process that is clear, flexible, and repeatable.

Where Design Processes Come From

Most colleges teach rigid design processes. These processes are meant to help students learn how to think and solve problems. Over time, large companies adopted these same ideas, but added layers of rules, meetings, and paperwork.

What starts as a helpful guide often turns into a slow, complex system inside big organizations.

One of the most common models taught in school is Design Thinking.

The Classic Design Thinking Model

Here is the version many designers learn in college:

Discovery – Learn about users and understand their needs through research.
Define – Clearly state the problem you are trying to solve.
Ideate – Brainstorm ideas and challenge old assumptions.
Prototype – Create early versions of the solution.
Test – Try the solution with users and learn what works.

On paper, this process makes sense. It gives structure to creative work and helps teams stay focused.

The problem begins when companies treat this process like a strict rulebook instead of a flexible guide.

In large corporations, each step can turn into weeks of meetings, approvals, and documents. Teams end up spending more time following the process than solving real problems.

Design thinking should support good design, not slow it down.

Finding the Middle Ground

Some designers believe creative work is too messy and human to ever fit into a process. Others follow processes so closely that creativity disappears.

I prefer to work somewhere in the middle.

I keep creativity free from heavy rules, while still using a clear step-by-step structure. This helps me stay organized and helps stakeholders understand how work moves forward. It also gives them a chance to give input at the right time.

Below are the general guidelines I use on every project.

My Core Design Principles

Never work without a contract
Get everything in writing, including signoff on completed work. People forget things, moods change, and written agreements protect everyone.
Always be ready to stop
No matter how much time or effort you’ve put in, sometimes stopping is the right move.
Form follows function
If a product is hard to use, it doesn’t matter how pretty it looks. A broken product with nice colors is still broken.
Clearly define the problem
If a stakeholder doesn’t know what they want, you can’t design it. Designers are not mind readers.
Question the requirements
Ask, “Are we solving the right problem?” Bad requirements lead to bad results.
Remove what isn’t needed
If a feature or step doesn’t add value, delete it.
Iterate through drafts
Try many ideas. Most good solutions come after several attempts.
Simplify and optimize
Clear and simple usually beats clever and complex.
Plan for delays
Expect indecision, changing priorities, and committee reviews. Slow planning saves time later.

My Workflow Stages

I break my work into clear stages and require signoff at each one before moving forward. This prevents wasted effort and keeps projects moving.

Stage 1: Requirements Gathering

I start by gathering all major requirements upfront. The goal is to make big decisions early and leave small details for later.

This lets me work faster because I don’t need to stop for constant approvals or missing information.

Ideally, decisions are based on data, user feedback, and industry standards. In reality, many decisions are based on personal taste. When that happens, I document it and move forward.

Once the goal and direction are clear, I begin designing.

Stage 2: Application Flowchart

Next, I create an application flowchart that shows every screen and how users move through the product.

This step helps:

Spot missing or unnecessary screens
Clarify user paths
Give stakeholders a clear “map” of the product

Many problems are solved right here before design even begins.

Stage 3: Wireframes

After the flowchart is approved, I create wireframes. These show layout and structure without visual polish.

This is the best stage for feedback because changes are fast and low-cost. I encourage stakeholders to be very critical here.

For freelance work, I always get signoff before moving forward. Any later changes affect time and cost. In corporate settings, changes often happen later, which slows progress. I try to improve this culture when possible.

Stage 4: Prototype

Once wireframes are approved, I create a detailed prototype that shows how the final product will look and behave.

At this point, most big decisions should already be made. The goal is final approval so the design can be handed off to developers with confidence.