Identifying the need for a process

Processes seem to bring out a special kind of anger in people. I don't know why. Have you worked in a team with no processes? It's a structureless mess of confusion and wasted time. Why? Because all a process does (and is intended to do) is provide structure to your team that sets them up to do their best work.

The dislike of processes from product and UX designers becomes really bloody funny when you think about how we spend much of our time. Building consistent systems and patterns to help our users do their jobs quicker and easier by alleviating unnecessary thinking. I'm not sure about you, but to me, that sounds a hell of a lot like teams process.

Many of the processes in the companies I've been involved in, formed organically out of a need. The team needed to share what they were working on? The daily stand up was born. Did people need to know how to file bugs? Bug filing was born. All a series of actions taken to achieve an end goal (Define: process).

In both examples above, I mention the "need" - This is the most essential part of any process. It has to be delivering on a need the team has. If you are designing a process to solve a need your team does not have, you are wasting your time and quite frankly annoying them or even making their lives harder. Poor TX.

We need to be able to identify the team has a need to solve. Here are a few signals to look out for.

There is a great chance you've seen some of these signals in amongst your team. This doesn't mean you should run off and start thinking about all the possible ways your team could work, but it is a clear signal to open a conversation with your team and start looking for small incremental ways to start solving some of those needs.