The Fuel and the Engine: Building a Process That Purrs

As a younger, less experienced creator, when someone mentioned process, my eyes would glaze over and I’d picture a factory mass producing cheap tchotchkes of humdrum sameness. I believed process was anathema to the truly creative person, a shackle keeping ideas from soaring.

If you can’t describe what you are doing as a process, you don’t know what you are doing.
— W. Edwards Deming

What I failed to see when I pictured process as a factory was the opposite end of the spectrum. The same mass-production facility that can produce a worthless plastic trinket could be retooled and redefined to produce an iPhone or a BMW. The quality of the creation is not defined by the fact that it passes through a process, but by the quality and tools within that process.

Now I view process as a system for transforming ideas and passion into products. Process is the engine, and passion is the fuel. A good creator needs both. Process without passion leads to monotonous, meaningless work, but passion without process leads to failure and burnout.

So how do you build, evaluate, and refine a great process?

My former boss Tom Illmensee and coworkers at Snagajob introduced me to this method for evaluating your process as an individual and within a team. Over the course of several months, every team member ran through a series of exercises that helped us map our individual process and then evaluate them in terms of the rest of the team.

1. Frame your foundation.

As a team, we often discussed the Build-Measure-Learn and Think-Make-Check iterative process concepts from The Lean Startup and Luxr. These process models formed the basic foundation that framed the rest of our discussion. As we mapped our overall process, we added our tools to one of those three buckets. Our team leaned toward the Think-Make-Check model because thinking is an important first step of the design process, where Build-Measure-Learn is a more intuitive process for engineers who are heavily focused on production.

Having a basic framework helped us to define where in the process each of our tools fell. Some tools fell squarely into one bucket: discovery research was obviously a part of the “Think” phase while usability testing clearly belonged in the “Check” phase. Other tools blurred the lines between phases — is sketching thinking or making? It wasn’t important that tools fall strictly into one bucket or another, so long as they made sense in the overall map and flow.

2. Catalog your toolbox.

I found it tremendously helpful to write down each individual step or tool in my process on a notecard. By breaking each step into individual cards, I could see the whole picture and rearrange it as needed. As I filled my cards, other tools I’d heard about but never used came to mind. I wrote these down as well as a way of cataloging things I could add to my process.

3. Map it out.

Once I reached a point where I couldn’t think of more cards to write, I began arranging them in the order that they occurred in my current process. For tools I hadn’t employed but wanted to, I placed them where I felt they logically fit. We used a long conference table to map our cards, so I ended up arranging them linearly left to right. To capture the cyclical nature of process, you could also arrange them on boards/walls in large circles. Occasionally I would reach a point in the process where I would realize a card was missing, and I’d write it and add it.

Moving from left to right, I arranged the cards in order of granularity and fidelity. So for example, a portion of the process progressed left to right from ideation to sketching to wireframing to mockups to prototypes. The flow didn’t have to exactly capture every situation. Sometimes it might make sense to skip individual steps or do them in a different order. The important part is thinking out your process and seeing where you might have gaps or opportunities for improvement.

4. Reconvene and recombine.

Over the course of several months, everyone on the team went through the above steps and defined their individual processes. After that, we got together and compared our individual flow. We pulled out similarities between each individual’s process and mapped them to an overall team process. This recombination was helpful in several ways:

• It again helped to highlight where each of us had gaps in our individual process.
• It accentuated strengths in each team member for certain tools or steps in the proces. (So when we wanted to improve a specific skillset, we knew who to approach.)
• It helped us to define an overall team process that could be shared with other parts of the company to help them understand how we work and where we were within the context of individual projects.

The entire exercise was really eye-opening and particularly effective for getting the whole team on the same page in terms of our collective process. Even if you’re a team of one, this exercise (sans the reconvene portion) can help you define a more deliberate process.

So what defines a good process?

A good process:

Anyone who interacts with process has a choice. You can either blindly follow the bulleted lists or you can ask why.
— Michael Lopp, Rands in Repose

• is a toolbox, not a checklist. You don’t have to check every box for a process to be effective, but a good process gives you the tools you need in the order you need them.
• is deliberate and habitual. If you aren’t intentional and regular in the maintenance of your process, then it will fall into disuse.
• introduces good creative constraints. Try and iterate through 1–3 full cycles of your process within a shorter time period like a week and listen to your creative engine purr.
• gets things started and keeps things moving. Nothing kills the blank page fear better than having an obvious next step.
• creates opportunities for quality. Without an obvious process, it’s easy to get stuck in a make and release cycle that never validates the quality or value of what you’re making.
• helps fill gaps and answer questions. A great process should be able to defend its existence and explain why things are done a certain way.
• is repeatable. If it’s not repeatable, then it’s not a process. Like a recipe, if you can take the ingredients, run through the steps, and get a consistent result, then it’s a good process.
• should be evaluated and refined periodically. As new team members join and old members fall away, refining your process can help teach and test it.
• is your product as much as anything you create with it. Your process is the seminal product by which all of your other products are built and tested.

Want to learn more?

• Embrace Uncertainty: Building a UX Process for an Agile World — This talk was a direct result of the process I described above.
• 10 Principles of Lean User Experience — Including #5, FLOW: Think-Make-Check that defines the basic three-step framework.
• The Process Myth — Rands explores how processes are defined and defended.

Image credit: The awesome animated gif of Pop Tarts being made was originally shared on Reddit.

Originally published at uxcellence.com on May 18, 2014.