Skip to main content

Defining a design process for B12


Early in my career, I worked at a small development agency called RealDecoy. I have fond memories of our weekly design team meetings where one of our VPs of Design, Erik Hagborg, would walk us through the design process. At every step of the way, he would highlight the various tools available to help us understand our customers’ problems, come up with lots of divergent solutions, and test our designs. The things I learned in those meetings have stuck with me through the years and have once again proven valuable as I have taken on the responsibility of running our monthly design hangouts at B12.

Up until this point, I have done a number of things to keep those calls interesting. We’ve watched inspirational videos together, had good discussions, invited guest speakers, shared our work, and given project updates. While they’ve been good, I recently started to feel like things were starting to feel stale. As I was planning our November meetup I remembered how much I enjoyed those meetings at RealDecoy and decided I would try and recreate them at B12 — starting with collaboratively defining our design process.

Defining our design process

I set up a digital whiteboard with Figjam and laid out a four step process to kick off the meeting. Our conversation went really well and we aligned pretty quickly on the four steps thanks to our collective experience in design and product development.

Next up, we started to define the various tools at each step of the process and that went well too! The team was engaged and provided really good suggestions. We didn’t get through the entire process in November but we picked things back up in December and wrapped it up. We now have our design process mapped out and in the tools we defined, we have a roadmap of future topics to discuss at our upcoming design hangouts.

The process

There are four steps to this process and it scales really well to meet the needs of problems big and small. It is rooted in understanding the problem you’re trying to solve and the context in which it applies. Using the information you collect, you hypothesise as many solutions as you can come up with, pick the best one to execute, and then test for the intended results.


Before you can design anything, you need to start with understanding: understanding the problem you’re solving; understanding who you’re solving it for; understanding what resources you have available to solve the problem, and understanding how you’ll know when you’ve solved it.

During this stage you’re collecting information and organizing it in ways that surface patterns and bring clarity to the problem you’re trying to solve. You can leverage tools like stakeholder interviews, expert reviews, competitor analysis, usability testing, and many more to produce briefs, models, and reports to communicate your findings.


Once you have a clear understanding of what you’re trying to accomplish, then you enter the hypothesizing stage of this process. The name of the game here is to explore the problem space and come up with as many different options as possible. I always start with the most obvious ones and then branch out from there.

This can be done in the form of group brainstorming, going through the how might we method, playing crazy eights, or sketching — whether that’s wireframing, putting together mockups, creating information architecture (IA) or flow diagrams, writing user stories, designing with words, or plain old scribbles on a napkin, anything goes as long as you’re communicating a solution to your problem and you can get feedback on it.


When you’re happy with the options you’ve explored, it’s time to make some tough choices and pick the one(s) you believe in most. At this stage, you want to get your designs ready for primetime by filling out as much detail as you need to gather feedback or to test your design.

This can be as simple as arranging the designs you created in the Hypothesize stage into something that’s sharable or as involved as creating prototypes, high fidelity mockups, mocking up every state and use case necessary for the design, or even implementing your design if you’re ready for it.


With your design(s) in hand, it’s time to see how effective they are by collecting input. Budget and time permitting, this can be as elaborate as performing a usability study with real customers, running an a/b test, pouring over analytics, or as scrappy as conducting a quick guerilla test with your colleagues, friends, or family.

Once you’ve gathered your feedback, you’re essentially back at the Understand stage of this process and you can go through it all over again. You Hypothesize solutions to the problems in your design, you Make updates to your design, and you Test it again to see how it fares.

That’s a wrap

And there you have it, a nimble four step design process that can be applied to design anything from a spoon to a city. Thanks for taking the time to read this post. Make sure you’re following me on Twitter, LinkedIn, or my blog for more design related posts about how I work.


Signup for occasional updates from my blog.