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.

Your team does not know what to do. It's an obvious one, but if your team are repeatedly confused about how something should be done, then put the tool in place to help guide them through the steps of finding out and understanding.

You are forgetting things. If your team are forgetting to deliver on all aspects of the work. It's most likely because it's getting lost amongst all the moving parts. A process helps build habits and ensures your team check all the boxes during their week. Just as our parents installed the process of washing our faces, brushing our teeth...

You want to educate. "Do it this way, that way, that other way" is often a frustrating way to teach junior designers. Yes, give them freedom, but you have to guide them and instill a way for them to practice. From there they can break out and find their way of doing things.

You are hiring "We don't have a way to do that, just do it as you like". This is the single most painful sentence I have ever had to say when doing onboarding. I hated it, the new employee who we wanted to make sure had the best experience hated it. It's just unhelpful and in the context of wanting to make a good impression on your new team, it piles on unnecessary pressure.

Your team are asking. Duh. If you refuse your teams request for help and guidance, should you really be building teams?

Uncertainty. Uncertainty can put unneeded strain on your relationship with your other teams and/or clients. It can even lessen the perceived value of your team because nobody can see nor understand what your team are doing. A process not only guides your team but can help others understand what and why you are doing.

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.