From time to time I am asked about the design process — or maybe that should be Design Process™ — that I use at Noodle.ai, and so I thought I would put it in writing.
You’ll see a lot of mid-size to bigger digital product companies codify their processes, often in a series of diamonds (is two diamonds the best? No three diamonds. No, the best is 15 diamonds!). That’s all great and the more people you have involved in a process the more structure needs to be built around it. Noodle AI, on the other hand, is a small, young company that has never had more than a few designers and a handful of front-end engineers, and as such, we have been able to stay a more nimble, and really adapt our process as needed by the given project. In this respect the biggest differentiator between projects is whether this project is Visionary (open-ended) or an execution (defined goal). But that is really a topic for another day. Rather than a series of diamonds, which seem to convey a sense of rigidity and inflexibility, we use the squiggle line approach.
I didn’t invent this squiggly line idea — that would be Damien Newman — but I find it useful. It means that we start with a very wide, undefined concept that honestly portrays the messiness and uncertainty inherent to a creative process, and over time narrow it down to something that is simple, refined, and concrete. This mental model also helps me keep the the steps fluid when they need to be. Just because I have taken on a task in the definition phase does not mean that I can’t realize an unanswered question and move a step backwards into Discovery.
Does that mean we have no process and each project starts in a state of abject chaos? As you probably guessed, no. Our design process starts with a toolbox — a list of activities and criteria that fit into three project stages. This is essentially Ted Goas’ design process with a few tweaks of my own.
Having a defined tool box helps me not have to go back to the drawing board at the start of each project. Not every tool in the toolbox is necessary, and some are more aspirational than anything, but this gives me a starting point, a menu of items to select from depending on the project at hand. Having the list also helps me have concrete steps to put into Jira in our planning phases, so that other team members can see what I’m working on at a glance.
My toolbox looks like this:
Potential activities
Exit Criteria