If you’re interviewing for a new role, chances are that a major portion of at least one interview will be discussing the approach you’ve made in the past, and perhaps the approach you want to take in the future.
If you’re pitching or sponsoring a project, chances are that you’ll dedicate as much effort to describing how you’ll do something as to what you want to do.
We talk about process in specific terms, like case studies, to give evidence that an approach worked for a specific problem. Documenting case studies is a great way to share our knowledge of what worked for a specific problem, so that we can apply those experiences to a similar problem.
We talk about process in more general terms, like methodologies, to try and capture a more general purpose approach for working that we can be applied to a wider set of problems and situations1.
While the meaning of process is clear (a series of actions made in order to achieve something), this still leaves a broad area of what process can include.
Process can include how work is planned, how decisions are made, how teams are organized, what tools are used, and even the type of outcome that is sought.
Process can describe our approach to work at a variety of different levels, but we seem to lack the mental models and language to discuss these different levels2.
Perhaps as a result of this gap in our language, many current conversations around processes tend to direct our thinking round design process towards making a choice between either waterfall or agile (with UCD standing awkwardly on the side).
While we can lean a lot from all of these methodologies, there are four big problems that I suspect many of us are experiencing.
To use an analogy of European history, I suspect that many people would consider our industry either to be experiencing a renascence of process (having started 25 years ago with Cooper’s personas and the agile manifesto), or at least its dawn (with the lean approach that’s gained popularity in the last 5 years).
I’m no scholar, and my knowledge of history is probably full of stereotypes, but rather than a renascence, I think that we’d do better to compare today with the Crusades of the Middle Ages.
My association with the Crusades is a period of religious dogma where people were violently discouraged thought that questioned historical teachings of Rome and Christianity.
It’s a dramatic, and probably inaccurate comparison, but the parallels I see is a general willingness to accept that some process as being ideologically right or wrong without taking the effort to understand what that statement actually means. I see this manifest with calls to return to ‘best practice’, and how designers, and teams are encouraged to choose a single process to work under.
I believe that we can start our journey into the golden ages of collaboration between disciplines, consistency of quality, and confidence in our approach to how we work by accepting that there is no single perfect process, and that depending on what you are trying to achieve, and the context that you’re working within, that some approaches to process may serve you better, and some may serve you worse.
Thankfully our industry seems to move faster than any other in recorded history, so hopefully we’ll advance quickly.
If we agree that some process isn’t better or worse than another, we’re left with the question, how do I choose what process to use?
I don’t have any easy answer for this, but I have some perspectives that I think are useful.
My mental model of process used to be something akin to a template for working. This unpacked to a process being something that was singular, and applied end-to-end to some project.
I’m trying to shift my thinking of process from a template, to just a tool to be used. This helps me think of process as something with an intended purpose, and something that can be used occasionally, and in combination with other tools.
Using an intuition pump I’ve started mapping qualities of different processes to help give some structure for thinking about processes:
These questions won’t give you any direct answers, but the activity of categorization will hopefully help trigger some thoughts around the purpose of process, and perhaps help you reflect on what qualities are important for your project.
Here’s my take at mapping these qualities for some well-known processes:
Here’s a quick story of a small project that our team used to experiment with our way of working.
Instead of following a specific process, we chose principles that we associated with productive, happy teams, and quality output, and built in regular points of reflection into the project to think about how successful we’d been at applying those principles, any opportunities to apply a principle that we’d missed, and how we might be able to apply these principles more in the future.
The hypothesis being that the more mindful of what we think are positive qualities, the more likely that they will occur.
For our project kick-off, each team member had a deck of cards each containing a principle that as a studio we believed was associated with high-quality work.
We played a simple game to narrow down the principles that we thought were most relevant for this specific project, and used our choices to have an initial discussion around why we thought this was an important principle, and initial thoughts about how it might manifest for this project.
Some of these principles had very tangible impact, like our decision to use an all-analog team board for tracking team tasks and process, to the more intangible such as making it explicit that experimentation (and expected failure) was not only hypothetically encouraged, but something that was actively questioned on a daily basis: What are more ways that we could be learning through experimentation?
This philosophy continued right to the end of our project with our team retrospective, where we interpreted making work visible and learning by experimenting to share our experiences with the wider studio not by a Keynote presentation or lunch and learn, but by taking an unused meeting room and converting it into a cosy space designed to encourage people to reflect on their projects, and held an unveiling party to share some of our philosophies.
This approach focused less on having control and organization of how teams worked, but attempted more to change how teams think about working.
While still a process, this approach feels so different to other approaches to working that I’m more comfortable calling it an anti-process.
It’s interesting to reflect on the difference of available material that discusses process in specifics versus generalizations. For example there are lot of books describing methodologies and philosophies, but comparatively fewer on case studies of specific projects. On the other hand, grassroots efforts like meetups that reach a smaller audience often seem to take an approach of a case study. ↩
For example process at different levels can describe how an individual works versus how a team works, or what happens in the period of one week versus what happens over the period of one year. We can talk general terms of macro/micro or high-level/low-level processes but these binary terms fail to capture the nuance of how I think we should be thinking about process. ↩
I think that many people also have a strong urge to try and find unifying ideas. As a young designer I had an obsession with trying to design a single process, that was both flexible enough to apply to a wide variety of problems, but also specific enough that provided clear practical steps to follow and reproduce success. ↩