Process & Approach

tl;dr: Every project has different needs, goals, and constraints. Requiring keen flexibility with your process, tools, and approach.

Process is a performance that results in artifacts, and outcomes. The actual process matters little. The steps are mostly irrelevant.

How I go from “problem” to “proposed solution” isn’t linear, or clean. I make a big, ugly mess. This happens mostly in my head, and sometimes on paper. It’s an uneven cycle with lots and lots of iteration.

As cliche as it sounds, my real process is “It depends.”

An important part of any process is knowing when, how, and why to deviate from the “ideal” path to get the work done within the constraints, while still meeting the goals of the project. That is not an opening to cut corners, but an opportunity to understand what approach best serves the project and its audience.

There must be a framework or at least a plan that I follow?

Design Thinking. Double Diamonds. Design Cycles. Speculative Design. On and on... There are so many methodologies.

Here’s my current thinking.

If I constrain myself to a single process, even if it loops, and has built in checkpoints, I will eventually hit a wall. A wall I can’t climb, dig beneath, or go around. A literal stopping point, that quickly becomes a rock-solid blocker for solving problems, ’cause problems don’t care about process.

The reality is I have to do “things” to move the project forward. But, I don’t have to do those things the same way, employ the same tools, perform the same tasks, go through the same motions, or produce the same artifacts.

To solve a problem, I must, in no particular order:

• Understand the problem.
• Explore solutions.
• Make/Present proposals.
• Reduce/Prevent harm.
• Gather consensus.
• Communicate.

A-ha! That’s a process!

Not really. For that to be a process it would need to have defined steps, an order, tasks, and deliverables. A way to go about the whole thing. In reality this is a checklist of checkpoints. Goals. Things I should accomplish, but not, and this is the important bit, how to accomplish them.

I may explore solutions on a napkin, or in the tool du jour, or in my head before I understand the problem.

I may communicate ideas before I have a proposal.

I may learn something new after I think I’ve solved it.

I may never gather consensus, or in fact solve anything.

I might have to start over.

I might not finish because I uncover a more important problem.

All of this is normal. All of it.

Importantly, it is OK to discard work you’ve done. It is OK to fail.

In fact, failing is the only certain part of any process.

On the topic of failing, I want to quickly speak on a specific point Reduce/Prevent Harm. For a large portion of my career I had a very narrow view on this portion of the work, and I spent way too much time and effort focusing on very specific types of harmful outcomes. I wasn't thinking or acting broadly enough.

It is vital with every step, artifact, proposal, exploration, etcetera... that you are checking in and evaluating the harm you may be causing with your presence, actions, words, and deliverables. And even more importantly, acting to reduce or prevent that harm.

Failure is an opportunity for growth, a lesson. Do not ignore or worse, wallow in your failures. Deconstruct and learn from them, and take those lessons to the next attempt.

A Couple Notes

There’s a quote I like that I think applies here.

This is a wonderful philosophical view, and it so beautifully and perfectly applies to the pursuit of solutions.

A design approach that not only encourages, but necessitates flexibility in your problem solving practice.

The answer I gave earlier, “It depends.” holds true. In order to truly solve problems, you must be flexible, willing to fail, and OK with “wasting” time.

I recognize this whole “go where the problem takes me” approach isn't for everybody, and I would never advocate for that. This is just what is working for me, for now. And when I work with others, I've found this preference towards flexibility prepares me to adapt to, and work within more rigid frameworks and approaches.