At work, we encourage a traditional model for digital product design. In essence—you start with planning, followed by design, followed by development.
But here’s the thing, .. I’ve never really worked that way. And—as a result, part of me used to feel illegitimate and phoney. As though I was doing something *wrong* by not following that hard rule. I do follow them though—just in a far less rigid manner, and one that is agile and continuum based. One that is iterative, and progressive, and conducive to trial and error followed by retroactive changes in any part of the product building sequence (specifications, design, and/or development).
Why is this better? Because well, you can plan until the cows come home, and you can design until your eyes bleed, but here’s the thing. Until you actual put all that writing (planning) and designing to the test, you are working in a hypothetical vortex. You are making assumptions, and in the best of cases (albeit rare) you are only stress testing user stories / scenarios to a limited extent.
If you’re too married to the idea of things happening in silos and on a chronological linear plane, then you’ll fall into the trap of settling for *final* decisions made at inopportune times—in premature stages. Unless of course, you’re a master guesstimator or fortune teller. Even if that’s you though, you’re a one in a million kind, these notions are for the rest of us.
Why do we do this then? Why do we more often than not work like this? It’s the common denominator practice because it’s predictable. Predictable means easier to project manage and budget, and less risk averse. It’s *safe* and it’s comfortable.
The alternative approach, is to continuously work on the three pillars in a *continuum* manner. As in, your design annotations / specifications (planning, interpretation, conceptualization), design, AND development, are constantly evolving based on iterative progress at key intervals.
Think of it as a perpetual loop, what you miss in the first loop you can always catch in the next.
For me, here’s what that looks like:
I largely start with design. Not exclusively, there’s of course always a root idea in my head but to really get the creative juices flowing, I need to see and feel something—I need to create. I have to sit down in front of the daunting white canvas and get going. As I create (design), some ideas spawn and mature. Others join forces and mutate into something new. And, many others wither away and die. My early "art boards" (a design file white canvas) are a balanced mix of bad, bad, not good, and great. I test theories, and then I formulate ideas and hypotheses based on those discoveries.
Once I have something I’m fairly happy with (static design), that becomes my baseline to work from. From here I can take out my quill pen and parchment paper to write design note intentions / aspirations *based on* the preliminary design trials and errors. The *next steps* to try and permeate on in design and/or in development (the functional specifications or aka design business rules as I like to say).
Now, I admit that I am fortunate to have the background, qualifications, and brain type to approach things in this manner. So no, I’m not suggesting this will come naturally for everyone. But, it is certainly a design process worth sharing that I’m sure many *can* relate to or take advantage of. For me, it has worked wonders.
Back to the process I’m describing.
After the preliminary design proofing stage, and after the design annotations one (design annotations that complement the design ideas and intentions), comes a plan. I’ll admit—for personal projects at least, this is sadly more often than not the part I don’t do and as a result, a lot of my really good ideas don’t change from conceptualization to realization.
A plan for what exactly you ask? The plan is a list of things you need to do, to make these aspirations become reality. By plan, I don’t mean a schedule. The schedule can follow or complement the plan but they’re two different things.
The plan, is more of a discovery and research task. The master task here is a "sandbox" one. What’s a sandbox you ask? A space to tinker and build, a space to test design and integration hypotheses. The plan could list new skill acquisition needs, proof of concept / trial and error period(s) to put your design and new skills learned to the test, etc. Basically, anything that needs to happen (the "what") to move past *design* and into *development*.
But isn’t sandbox a development phase? Yes, but not one with the same goals, intentionalities, and requirements as a public facing product has. The sandbox, is where you try and you fail. You make messes here, things are inordinate and unpolished. You put up walls held together only by yarn and you’re ready to take them down at a moments notice to see if they’ll hold up with duct-tape instead.
We learn by doing—we need sandbox phases. We move from theoretically speaking to objectively speaking only by "sandboxing".
After the sandbox phase (trial and error experimentations), is the formal development phase. It’s where you take your isolated sandbox experiments, and integrate them into your broader product that will be public facing. A good analogy would be architecture models. The models test theories at a marginal cost of real building materials. The modelling work is a form of development / architectural work, but it’s not at all the same as the high rise version, it’s purpose and requirements are completely different.
As you sandbox, and even as you develop, you will see opportunities for improvements, and guess what? If the opportunity enhances the build, should you stop yourself because you’re not in the official design phase anymore? No! Are there impacts to working this way? I mean, yes—you have to be reasonable since all projects have resource caps. For me, the way to manage this has always been to entertain the idea either in a visual "comping" manner and sometimes even in a prototypal / functional proof of concept way.
Why? Because a picture is worth a thousand words. I guess in this case, a design or a functional prototype is worth a thousand words.
Why does it matter how much a picture is worth? Because in the design world, part of the skill you must hone is *selling* your work, selling your ideas to yourself or stakeholders. And I’m sorry to tell you but your most eloquent and thoughtful text version will rarely raise the neck hairs required to get buy in.
More often than not, this gets me the buy in I want, which starts the conversation around how to make time or find the extra resources to make that happen. Sometimes it’s right away, and others it’s in a future version, those are both perfectly good avenues. Congratulations, you’ve yet again successfully permeated your product design—sold it—and then got the buy in required to refactor your product, making it iteratively better and better.
Good design is on a continuum—how exactly you do the continuum part is up to you, there are lots of ways. But the non-negotiable part is the continuum; exemplary design is continuum design—I mean design here in the most general sense, not just the visual DNA / composition one.
Waterfall vs. Agile
Instead of taking the Niagara Falls route next time, grab yourself a giant inflattable donut and join me in the [continuous] lazy river—it’ll throw you for a loop.