“Correct” design process doesn’t exist
These frameworks are inconsistent at best, and harmful at worst. Disclosure: Typos are my super power.
Image originally by Vector Tradition, but with some added flair.
Sequential, concurrent, iterative, waterfall, agile, linear, double diamond, triple diamond, spiral, honeycomb. Ideation, conception, design, production. Discover, develop, deliver.
Ok ok, I think you get the point. And honestly, I’m sure there are even more. Each of these frameworks has their own unique quirks, but ultimately they’re attempting to accomplish the same thing: to capture the most effective, efficient, and collaborative process for design thinking and partnership across a company as a means to solve problems on behalf of users and businesses. So which one is the right one?
Here is my hot-take on this (if the title didn’t clue you in already): A correct design process doesn’t exist.
When I started in my career, I was a firm believer in the whole “fidelity of the artifact should match the fidelity of the idea” concept. This was how I justified starting every design project in tangible sketches (do the kids still do these now-a-days?), wireframes, and grey scale workflows. This idea that all projects needed to start at this exact stage was pretty cemented in my definition of design as a practice. There is a correct place to start, and that is with mountains of questions, and sketches.
I don’t think it’s bad advice — It’s just hopelessly optimistic.
The idea that design process had a ‘right’ and ‘wrong’ way was something I fully believed in. If it didn’t follow an exact order of operations and check the boxes, well then, you were doing it wrong. This is what, to me, separated Design from Art: Design had a correct and incorrect application, and Art was up for interpretation. There is something very comforting about that level of structure. But the longer I’m in the industry, the more I see what a load of crap that is…
Ok, admittedly that was harsh — but the truth is, design isn’t that tidy most of the time, at least once you’ve graduated beyond total beginner. Design is fluid. It’s the ability to acclimate to that fluidity that can make your design beautiful as well as impactful. Truly impactful designers can identify the correct tools at the correct fidelity at the right time to convey the idea. Sometimes thats a paper prototype, sometimes you can’t communicate the low fidelity idea without higher fidelity UI.
Now to clarify: Structure and definition isn’t bad, but rigidity around design process is. That’s what I’m calling out here. It’s the mark of a young designer, as well as a less mature design culture. Frameworks are helpful when learning design and explaining the general principals of the discipline. But if thats where the designer stops, then their growth (or lack there of) will forever be confined to those tools and single minded way of thinking. All you’ll ever know is how to use a handful of relatively linear phases that make up the basics. Your career, and your work, will suffer because of it. I think thats why so many of the case studies I see read so similarly… new designers are using the same tools in the same order. Every. Single. Time. Perhaps it gets you to an answer, but it’s not the road to innovation.
Example 1: Lets say you want to build a bookshelf. Without any context in what you want to build, I give you wood, a hammer, screwdriver, and a saw. I didn’t know what you’d be building when I packed the tools, but it doesn’t matter cause I tell you those are the only tools you can use. I also tell you the way you should use them and in what order. Sure you can probably pivot between a couple here and there, but overall this is the way you should go about it. (already feeling pretty bland isn’t it?)
You will probably find a way to build the shelfs, but two things are happening:
You are now thinking just as much about the tools as what those tools are enabling you to do.
You’re immediately boxed in, and you haven’t even started yet. You’re not thinking about how to build the best bookshelf, your brain power is now prioritizing the tools and what they allow you to do.
Example 2: Imagine using the exact same blueprint for every singe house in a neighborhood (little boxes song comes to mind). It will technically get the job done. You’ll have a neighborhood with livable homes and streets. But this isn’t the best approach if what you’re after is the most lovable neighborhood as possible, expanding your skills, trying new things, or create any level of character/interest. The house template could be truly stunning — but even great things get boring and less innovative with consistent repetition.
I remember once when I started on a new design team, the manager was walking through our “new” design process: a triple diamond framework to help designers know what to do and when, as well as to help partner teams know how to engage with us. The sentiment was great. The application was well thought out. But the only thing I kept thinking while looking at it was “this is great, but this will never happen”.
I can see how this might make me sound like a jaded cynic. However I stand by it — diamond, circle, square, line; the process isn’t (shouldn’t be) that tidy. You may not even start a project at the beginning of that first diamond.
So then this begs the question: why do we keep trying to nail down a specific process? Who are we doing this for? Is it for new designers? Stakeholders? Leadership? These visual aids are inconsistent at best, and harmful at worst. Well intended as they are, often they end up holding designers back. Particularly mid level designers who may not need to rely on high levels of structure, but think they’re supposed to do exact steps at exact times. So like in the example above, they are thinking just as much about the correct tool/phase/step as what it’s enabling them to do.
Designers who really know their stuff caters their process to the problem, not the other way around. They look at what it is they are trying to solve for, and pick out a few tools in different orders to solve the problem.
Beginner, diagram description: Drawing of a happy tidy linear design process. All is well
Mid level, diagram description: a little more chaotic but attempting to “do it the right way”. Using familiar go-to methods to solve problems, but running into some limitations while trying to do it the ‘right’ way.\
Senior, diagram description: drawing of similar phases but with lines jumping between in a decidedly non-linear way. This could have even more lines, but i ran out of flows permitted by the free version of this plug in… the point is each of these phases is arguably optional and my occur more than once. It’s up to the designer to decide.
Recommendation
At the beginning of a project consider what the problem needs not what you think you should do. Lay out all your tools, and make a recommendation for which ones you think would be most effective, when and why. You can also change your mind mid way through — X isn’t working? Don’t keep cranking on it just cause it was part of the original plan, take a moment to consider if this is the right tool for the job and don’t be afraid to re-evaluate. It’s ok to completely pivot mid project and decide that a prototype usability study isn’t required and what you really need is a card-sort exercise.
A very tactical mechanism I’ve encouraged to help with this is a Project Page. This artifact can go by a few different names; Design brief, approach document, kick off, one pager, the sentiment is pretty much the same. However the critical element here is that it allows you to gather all the known information in a singular place, identify the gaps, THEN lay out what your process is going to be. Sometimes the first thing you need to do is research, and sometimes you don’t need additional research cause you have mountains of it already. This allows you to completely change the “design process” to what will best suit the project.
Ok, now what?
Just throw all these frameworks out the window? Everyone doing whatever willy-nilly idea comes to mind? Have full-fledged anarchy?
No, not at all. But perhaps identify who in your organization are you’re creating these processes for. Don’t create a one-size-fits-all system. What your stakeholders need to know about how to best partner with design and when may different from how your designers approach a problem. And coaching for new designers is very different from how a more tenured designer may work, so stop pushing for a ‘correct’ process.
Leadership: Give your designers the freedom to tell you what they think the approach should be for each project. Don’t dictate the process, but allow them to take some time at the beginning of a project to let you know what they think the approach and process should be.
Designers: Don’t connect lines between your tools and phases at the start. Lay everything out first, then recommend the ideal order of operations that will get you to the best solution. Even outline which are mandatory or ‘nice to haves’ (Designing, design thinking? Nice.)
I’ve been privileged enough to have several managers who have allowed me this freedom, which is probably why I’m such a critic of rigid process. My current team has granted me the space to find a process for how MY mind likes to work through problems.
And if you’re on the nero-spicy side of the spectrum like me, then this will actually free you up to do some of your very best work. You won’t be thinking about how to morph your brain into a pre-determined box — you’ll create a process that fills the needs you have, and foster a culture of diverse approaches and ideas.
