By now, most of us have come across numerous Agile analogies. A simple cupcake transforming into a plethora of sugary goodness, a pile of sand magically turning into a sandcastle or a skateboard becoming a race car (See images below). All good ways to communicate the Agile mindset and make it somewhat tangible. But there are two ways of looking at these images.
One is when the future state of your solution is clear (i.e., desserts, sandcastle, race car), and you just need to break it up into smaller chunks that add value. And the other scenario is when you're unsure about the future state of the solution, you just have a ballpark (i.e., I want something sweet, I want a house for my pet ants, I need to get from A to B). The latter being what people refer to when they tell you to "just get started with the information you have". Which in my opinion is what Agile is all about, with some nuance here and there. Coincidentally, this is also the scenario that divides designers' preferences into two camps.
There are designers that like to focus on the "first major problem at hand" and design a solution that is meant to add value now or at least fail fast enough to know what needs to change. They can let go of the next and later state of the product and design small iterations towards happy end users. It's ugly, but somebody has to do it.
Other designers prefer working on the later state first. They want to explore visually and test out creative directions and then work backwards in order to define an MVP. Some can even do this while thinking about the now, next and later states of the product. Now, whether or not this is the designer's responsibility, is a story for another day. And even though I believe that designers should be able to work in both scenarios, I believe we all have our preferences.
My own preferences
Now, I've had the opportunity to design in both types of scenarios. And I always saw myself as the type of designer that prefers the quick and dirty, iterative approach. At the end of the day, this is the most efficient way of building software in my opinion. As long as we accept that rework is inevitable. I'll come back to this later.
I've also noticed that I enjoy exploring design directions while breaking down my designs into prioritised states of the product. Because of these vastly different ways of doing my job, I started wondering about the reasons for preferring one over the other in certain situations. I wondered whether I could identify certain variables that would impact my approach for designing for a project. I boiled it down to two things, the deadline and the risks we are willing to take in order to make that deadline.
Approach 1 – Deadline is yesterday
With any project, we're trying to solve one or more problems for the end-user and/or our own business. More often than not, we need these problems to be fixed by a certain time or fall within a certain budget. Potato, po-tah-to.
Now as a general rule of thumb, the less time there is between the kick-off and the deadline, the more risk we should be willing to take. Risk here, refers to the risk of building the wrong thing. There probably won't be enough time to discover and define the problem the way we want to, so we need to focus on which one of our assumptions has the highest risk of us "fixing a nonexistent problem".
In this scenario, I opt to design quick and dirty solutions. If there's already a Design System in place it's as easy as sitting down with the developers and deciding on a direction. And more importantly, defining our hypothesis for the proposed solution. If there isn't a standardised set of patterns, then I tend to fall back on best practices. Anything to get the project moving along.
For me the biggest challenge here is to let go of my ego. Because more often than not, the solution doesn't really look the way I want it to. I'm not proud to have "designed" it. But when it's live, and I see the value it has added, whether for the user or for ourselves in the form of insights, I feel a rush of energy.
Approach 2 - Deadline is in the future
The other scenario is when there's enough time between the initial kick-off meeting and the deadline. Now when I say "enough time", I'm almost always referring to time for the discovery and define phase. Because to me it's pretty simple, the more time you spend on discovery and define, the less time you need to iterate in the ideation and test phases. And of course, the risk of building the wrong thing goes down.
It's so much easier to start designing when I know which problem(s) I need to solve. Also, stopping feels much more effortless since I'm creating with a clear goal in mind. The focus that gives me, feels as if i'm being creative with superpowers. And it's because of these superpowers that I can design the different states of the product and clearly identify the now, next and later phases on a high level.
Rework shouldn't be scary
Now there's almost never a project that solely demands either one approach. We jump in and out of different ways of working trying our best to support our colleagues and our end-users. But there is one thing that I believe is consistent throughout. And that is the notion that within Agile, rework is not only inevitable, it is part of the process. Or at least, it should be.
We can even see it in the visualisations that I referred to in the beginning. When we for instance start with a skateboard and move on to a scooter, the only thing we might be able to re-use is the board the user's standing on. Same goes for the iteration where we move from a pile of sand to the first phase of the castle. We're not re-using anything there and have to start from scratch.
Fortunately, with software, there is a lot we can re-use but we should really remember that there will come a time where it feels as if we're starting from scratch. Because after 10 iterations or so, you've found so many new insights that focused your product into a new era. And we should embrace this concept and not fear it. And yes, on paper, if you take the time to discover and define your problem then it would feel as if the risk for rework has been somewhat mitigated, but I promise you that will change after a couple of tests.
Conclusion
There isn't one way to design for uncertainty. Every challenge requires a different mindset and approach. And as long as we accept "good enough" designs now, that can at least test a hypothesis, we can make the designs add more value later, when new insights open up the door to pivot and rework the product. But this requires us to sometimes take some risks and be open to fail. Fast.
