I’m sometimes asked what my design process is like. I’ve been designing for software and for the web since about 2007, and I’ve worked with a number of different kinds of design teams in that time. I’ve learned a ton about designing, building, and shipping software – and I’m still learning, of course! This is the design process that has emerged from my practice.

I’ll note that my practice has been shaped primarily by working on small, high functioning teams primarily in early, high-growth organizations. I believe that much of it translates well to other kinds of teams, but not all of it does and it may not be right for every kind of organization.

My process can be summarized as a journey of discovering the emerging narrative, imaging where it’s headed or where it could go, and executing on it with creativity and openness to what it can become and what it can enable. 

This is important because story is how we make sense of everything, life doesn’t always go according to plan, and the best work is cultivated, not dictated.

Also, this process has been tested mainly on teams with a single designer and multiple engineers, sometimes with a product manager and often without. So I admit that my expertise outside of that setup is relatively untested (…and I’d love to hear your feedback if you’ve worked in different setups!).

My process has three phases: investigate, explore, and implement.

Investigate 🔍👀

Any effective process starts with a clear understanding of the rationale for the work. What are we doing? Why are we doing it? What do we know so far?

This phase focuses on curiosity – asking lots of questions and listening to other people’s perspectives, digging into data to find quantifiable insights, thinking from first principles to understand what the core building blocks are, and really seeking to identify an emerging narrative that can be the guiding vision for the work.

User research is a big part of this stage, whether or not new active studies are involved. I like to go over past studies and look for context and insights that will inform design decisions, interview internal stakeholders to understand business and product motivations behind the work, and if time and resources allow conduct new studies to address outstanding blindspots.

I also listen carefully to the perspectives of internal stakeholders and the team building the project to really see what is motivating and exciting them. And I often look at the competitive landscape for similar experiences that will affect user expectations, or prior art that may serve as inspiration.

What I’m searching for in this phase is:

All of this become a product design brief that the team can reference to track the ongoing evolution of the project. The brief is an important step that initiates a sub-process of clarification, alignment, and internal negotiation that will continue throughout the project.

Explore 🤔💭

After we have a product design brief and have agreed on scope, sequencing, and priorities we can start to explore solutions.

In this phase we begin to explore solutions to the problem. It’s all about imagining what is possible, and then using signal from what we’ve learned so far to further negotiate with cross-functional leads on scope and execution.

I start by drawing out as many viable concepts as possible and consider solutions from different angles in low fidelity. Often this is just rough sketching on paper, but when time allows or problem depth warrants it I will make actual paper mockups, which is both effective and quite fun (there’s something about drawing by hand and re-arranging elements physically that brings kinetic intelligence into the problem solving space; wheeee!).

I also often use diagrams to align discussion around a shared mental model of the higher level concepts or workflows involved.

Depending on the project, different levels of exploration may be appropriate.

For a project or organization environment where resources are very constrained and time is limited the exploration process may be just a series of thumbnail sketches that explore the main options enough for a discussion with key stakeholders. This is also appropriate when the problem is a very simple, the design direction is really obvious, or a decision has already been made about the direction from outside the design team.

Alternatively, for projects where there is enough time, resources, customers available for feedback, and data to draw from this stage may include a wide range of initial explorations as well as some cycles of sharing early comps or prototypes with users for feedback and iteration, repeating as often as needed until a final direction is settled.

Larger and more mature organizations (e.g. post-IPO teams) are more likely to take the path of test shipping during the design exploration process and iterating in cycles within that phase (depending on the project or org business unit, of course).

Smaller teams and early stage products are often more likely to use the judgment of internal stakeholders as a proxy for customer feedback in this stage just to get something shipped and into the full product experience as quickly as possible so that product development can continue elsewhere while more meaningful feedback can come in about the work.

The overall goal of this stage is to identify the most reasonable solution to start with, flesh out the challenges and opportunities in the solution (focusing primarily on the user journey and jobs to be done), and create enough high fidelity design direction for implementation to begin.

Some teams may prefer to have design comps fully fleshed out and finalized at this stage prior to a handoff process for implementation. That’s fine, and of course there are reasons for that. But in my experience it is best to focus on getting enough direction settled for implementation to begin because inevitably implementation will reveal problems that haven’t been considered in the exploration phase and opportunities for improvement.

That said, it’s still helpful to have clear decisions about higher level design direction by the end of this stage, but usually smaller details can continue to be fleshed out in implementation.

It’s also worth noting that at the beginning of the discovery stage we are focused on imagining what’s possible and ignoring constraints enough to envision creatively what is possible in the future beyond the initial scope.

But toward the end of this phase we are letting go of theoretical exploration and leaning firmly into the mode of pragmatic and practical thinking as a necessity for the initial implementation.

Implement 🛠💃🏽🕺🏾

The final phase is where we shift from the conceptual to a focus on bringing the experience to life.

This stage is all about building, shipping, and iterating. In the previous stage some implementation may occur as a spike or prototype, but by this point we are focused on building for an initial release.

I work directly with the engineering team during this phase, jumping into code by spiking out a prototype for engineers to work from or handing off annotated visual comps and then contributing to code after the core experience has been built via polish edits.

I stay in close communication with the team to clarify implementation details, and in its best form this stage is a like a dance.

To be clear, this is my personal favorite style of collaborating with engineering, but it is just my preference – not the right way or even necessarily the best way. Some teams delineate between design and implementation as a matter of process, aiming to complete all design work before starting implementation so designers can jump into the next project while engineering implements. That approach certainly has benefits and is right for many organizations.

But implementation often uncovers the rough edges and blindspots that are easily overlooked during design exploration (e.g. edge cases, engineering constraints, etc). Treating implementation as part of the design process acknowledges that design decisions are still being made at this stage and creates space for ideas to emerge from the engineering team during implementation, offering engineers a stronger voice in the work and a sense of ownership in the results.

Staying in step with engineering during this process also helps the product designer be fully mentally present in the work so that they can be responsive and creatively engaged in whatever emerges.

In this stage, the product designer is now fully switched into decision making mode as every question the engineering team has needs to be met with roughly a “yes” or “no” to help the team maintain momentum.

I’ve also found that staying focused with the team helps build a sense of team bonding and shared morale. Shipping a project can be a very emotionally rewarding milestone in your work and being able to share that when you’ve all been focused together fosters positive motivation that can really help teams stay healthy.

An Adaptable Framework

It is important to remember that this process is a general framework meant to give space for the different modes of operation involved in design thinking and execution.

That means it can be adapted to the project or environment and will almost always need to flex and bend a bit. It’s rare that a project goes exactly as described here, and that’s fine.

What’s important for me is having a structure to operate by and a shared understanding of what we are doing, why we are doing it, and how we will do it together.