Design Process Makes Perfect

Process? We don’t need no stinkin’ process. I’m here to explain why you do, and why you are very likely to be already using processes on your team.

“Process” is not the act of turning everyone on your team into robots who fill out time cards or have to follow a script to do their job. It is the act of creating a structure in which people know what is expected of them, the priority of their tasks relative to others, and the time they have to get their job done. Anything more than that is just fluff.

Here are a few examples of things you probably already do on a team that are really just processes in fancy disguises:

1. Meeting at the start of a project to determine scope/strategy/deliverables to ensure your team understands what problems you are trying to solve = project kickoff
2. Sitting down with a designer and mapping out the work that has to get done = task planning
3. Looking across all of the work that has to get done, and determining what has to get done by when = work prioritization, tracking deliverables and schedules
4. Discussing with your team who is doing what work, and ensuring everyone has a manageable workload = resource management / load balancing
5. Making sure that project partners and stakeholders know where you are at with a project and have a change to share feedback = stakeholder reporting

The following are a few tips for program managers out there who are trying to establish processes, and could use a few strategies to get people onboard.

1. Listen first, act second. In some groups, especially ones with very little existing processes, it’s tempting to come in swinging and want to overhaul everything that is not working overnight. Take a little time to listen to the team, understand what they believe is and is not working, and then you can start to roll out the right set of processes that people will actually be onboard with.
2. Leverage the team’s ideas. Building on that last point — the most effective processes are born out of what the team is asking for. After gathering a sense of what is and is not working, frame the changes you plan to make as solutions to what the team is looking to fix. Demonstrate you have heard them, and are using the ideas they’ve proposed to fix the problems — and they will be bought in from the beginning.
3. It’s ok to pivot. A lot of times we hesitate getting started with a process until it’s perfect. All processes that you roll out, whether they are around scheduling, task tracking, reporting, etc, should be thought of as living and evolving, and should never be set in stone. If a method is not working, change it.
4. Ask for feedback. Not only is it ok to pivot, but it’s ok to ask for feedback. Poll your team frequently on what is and is not working about the processes that you have put into place. Each time your team has the opportunity to share feedback on processed they will be more and more bought into working within them.
5. Remind people why. There are times when the need for certain processes such as bug tracking or status reporting can feel like a chore — but a lot of times, these are needed for higher level goals, like establishing transparency between design and engineering (tracking design tasks in bug reporting software) or to get project funding (stakeholder status reports). Before just telling people you’re going to start doing something that might feel laborious, explain the greater context around why you are doing something, and you will find you will be met with much less resistance, or possibly even eagerness to follow the process.