Proven design process for the real world
The playbook I use to break down and execute on design projects.
Hey there! This is a 🔒 subscriber-only edition of ADPList’s newsletter 🔒 designed to make you a better designer and leader. Members get access to exceptional leaders' proven strategies, tactics, and wisdom. For more: Get free 1:1 advisory | Become an ADPList Ambassador | Become a sponsor | Submit a guest post
This newsletter is brought to you by Genway AI, a Research Platform powered by Conversational AI Agents. They help teams scale product research through natural, AI-moderated interviews - no scheduling, no staffing - just fast, actionable product insights.
The Product Design Playbook I use to Break Down and Execute on Design Projects.
Friends,
This week’s edition is a deep dive into the design trenches—from vague project briefs to high-stakes product expansion. Ted Goas, takes us behind the scenes of a massive transformation: turning a business phone platform into a full-blown, multichannel communication suite.
Sounds like a big task? It was.
But instead of getting lost in the chaos, Ted built a personal design playbook—a toolkit of proven activities, decision-making frameworks, and process shortcuts that helped him and his team navigate complexity, stay aligned, and ship faster.
What we love most is how honest and relatable this piece is. It’s not about perfection. It’s about real design work, real tradeoffs, and the messy middle that rarely gets talked about.
Here’s what you’ll take away from this playbook:
Why design processes often look clean in theory, but messy in reality
The exact activities Ted uses during discovery, definition, and development
How to build your own flexible framework for tackling ambitious product challenges
Let’s get into it 👇
Ted Goas is a product designer, researcher, manager, and sometimes developer. He leads teams that turn abstract ideas into usable products. He believes design is about taking the complex and chaotic and making it accessible to people, responsive, and as fast as possible. His aim is to create work that’s cool enough to show his friends and honest enough to show his parents.
You can connect with him on (LinkedIn), his (Website) & (Newsletter).
At the start of 2021, Dialpad’s core product was a business phone platform. We supported several use cases, but making and receiving phone calls over the internet was our bread and butter. By the end of the year, however, we acquired two companies and pledged to add email, chat, and social to our product. I was tasked to lead design for a project that would double the size of the product.
(cracks knuckles) Alright, I’m an experienced designer. I can figure out how to get this done.
I quickly discovered this was a hard statement to deliver on.
Product designers have never had so many tools and techniques at our disposal to help us do our job. Research, journey maps, Figma, code, Keynote, data analysis… the list is huge and keeps growing. With so many options, how do we know which ones to use for our projects and when?
And let’s be honest, how do we avoid doing this?
Some teams have distilled their product design process into a diagram or chart. At Dialpad, we adapted the double-diamond product design process into a triple diamond (influenced by Zendesk). Ours looks something like this:
That works most of the time. Though in reality, sometimes my process looks more like this:
So it goes 🙃
What do I say when someone asks me that dreaded question?What do I say when someone asks me that dreaded question?
“What’s your product design process?”
I’ve picked up a bunch of tools and activities in my years as a product designer, but until recently, had never documented them. As a result, I occasionally forgot parts of the process and my designs suffered as a result.
To fix this, I wrote down each part of my process so I’d have a playbook to refer to in the future. This is that playbook.
I think about my design process not as a mandatory set of actions for every project, but rather a reference and a prompt I can use to either do a task or understand why it can be skipped. Like a carpenter’s toolbox, it’s helpful to remember what tools are available, and how and when they’re helpful.
Discovery
Not having a clearly defined problem or goal can lead to hundreds of lost hours and resources because of misaligned expectations, incorrect project scoping, or unforeseen problems. While a team may feel they know these answers and so want to skip right to building something, it’s important to align and validate assumptions first so the project is set up for future success.
The goal of this phase is to help identify a problem statement, frame the problem, and gather enough evidence so we can confidently move forward into the ideation phase.
Potential activities: (chose which ones make sense for each project)
Make observations: What do we see? What do we know so far? This deepens our knowledge of the project and saves us from doing repeat discovery. Helpful when starting a Product Requirements Doc (PRD) or design doc. 🕓 2–3 days
Proto-Personas: A combination of research and intuition that represent what we think our users are like. Helpful when people disagree on who are users are or what their needs are. 🕓 1–2 days
Journey mapping: A visualization of the process someone goes through to complete a goal. Helpful when you want a big picture understanding of the user’s experience. This may include off-site things like user emotions or external touch points. 🕓 1 week. Example
Service blueprint: Map out the environment that will be affected by a project, including how different parts of the environment interact with each other. Good for large projects that might impact many parts of a system. Service blueprints also help break down a project into manageable chunks and milestones. 🕓 1 week. Example
Contextual inquiry: Understand how folks use your product and why they do what they do. Example
 | A guest post by
|