The Golden Foundation of Process

A couple days ago, I was asked by a friend and fellow designer to share some wisdom about design process. His team has been hovering around 5 people and new growth has him worried about the lack of an established methodology. Sound familiar? This isn’t something that only he has worried about; just about everyone who has been apart of a growing company has experienced this anxiety.

While jotting down ideas on deliverables and steps to chat about, I felt like something was wrong. It was too mechanical, which made it seem boring and even scary for a growing team. Process shouldn’t be viewed as a cement sidewalk that forces you to stay on a rigid routine. It should be seen as a path through the woods that has been well traveled with plenty of opportunity to aim for more sensible trajectories if needed.

So I decided to take a step back and outline the foundation of a healthy process. A foundation that a team can start with to understand why process is needed; and why adjustments in an existing process may be needed. From my experience at Imgur and other projects, I find these rules to be most relevant:

1. Process without a clear grand vision is worthless. A simple rule, but it is the most important and the easiest to get wrong. Everyone involved in the creation of a project should have the same big picture in mind and know how their project is going to help achieve it. This helps cultivate ownership of the product among your team.
2. Not all projects are created equal, and you should strive to use the Minimum Viable Process for each. I lovingly call this the “Real MVP”. If it doesn’t make sense to do full photoshop mocks, or a huge dev spec, then don’t do it. Process for the sake of process will hinder your team’s effectiveness and can even burn them out. The trick here is to understand this is still a team decision, and one person shouldn’t be making these deliverable decisions. It is a collaborative effort, because everyone has different needs to be successful in their tasks.
3. Not all developers and designers are created equal but deliverables should be understood by all. The point of this rule is to protect your team from employment stirring. What if your senior dev leaves tomorrow and you have documentation that only she can understand? You now have to take a step back and translate it for another team member taking her place. It is disheartening and depending on the project can be expensive. Figure out what language and deliverables work best for your team. Sometimes it may make sense to create a company language that all creators learn when they join the team (more on this in a future post).
4. A deliverable does not replace conversation. Just because Photoshop mocks are done and are passed off to the developer, doesn’t mean communication stops and work begins. Sometimes questions will come up and it will be faster to give an answer on a complex interaction in person than to update documentation. There is another interpersonal angle here: If a dev only sees a PM or designer when something is wrong, then you will create a rift in your team. It is important to check up daily with your team about good and bad things on the project. If you start hearing groans when you walk into the room, then you have created a bad habit of only ever bringing bad news.

If one of these four rules are not adhered to then a project can crumble from its foundation and make it seem as if the team is stagnant and unmotivated.

The products you create (and their quality) are a direct result of the design process you implement. Although there’s no ‘one size fits all’ process, with these four pieces, every team should be able to begin a conversation about how to collaborate, critique, and improve not only the product but the team dynamics as a whole. This perpetual mindset of improvement and refinement in itself, is the design process. The rest is just details.

** Special thanks to Josh Couper for his suggested revisions to this article.