Having a process for your interactive projects / teams is a way of maintain some form of order in what could otherwise be chaos. A process is a framework for creating projects that teams are supposed to follow in order to make the creation of interactive projects a smooth one. These usually involve a flow of some sort, where the task is put into one person’s hands and passed to the next ie : Wire-framing -> Design / Copy Writing -> Development -> QA. That is a very basic flow, but you should get the idea.
As a junior/intermediate developer I always hated having process forced down my throat, which it always seemed to feel was happening. As I gained experience at a number of different agencies, I realized that process was important, but also never really consistent or at least consistently followed.
It wasn’t consistent for many reasons:
- the team was new
- the project fell outside the normal process
- the timeline was compress
- we had to use freelancers
One thing was for sure, there was rarely ever a ‘normal’ project that would fit the process exactly. What ended up happening in most cases was that the process was loosely followed and the process somewhat fell apart. This didn’t mean that the project failed, in fact, some of the best projects have I have ever worked on were victims of this falling apart process. What it does show is that processes are hard to have and even harder to follow and maintain.
After working with a number of teams at a number of different agencies, we realized that process is an important framework whether anyone follows it or not. If there is no process, there isn’t very much order. It is important for everyone on a project to know where they fit in and what is expected of them. This should be a big part of the process!
If a designer doesn’t work with a copy writer and the user experience person, they may miss things or not get the full feel for the project. If that is the case, the effects domino down because a design that is missing something will have to come back to the designer later for changes and that may have a large impact on development and QA timelines.
When discussing process it is important to consider many things, project timelines, what is required in a project hand-off from each person, is one persons role dependent on another’s. Something that we find really works well is to decide on this at the beginning of each project. Doing so, everyone on the team knows their exact responsibilities, what is expected of them, whom they have to work with, and when everything should be done. Whether it is followed precisely or not, it forces an iota of organization that would otherwise just be implied.
Everyone works differently, at different paces, and may prefer to be alone or in groups, everyone is different. So having a basic framework for projects and then openly and verbally adapting it to the team at the beginning of a project proves to be very fruitful. People can voice their opinions, recommend alternative solutions and processes, and each person on the team knows where they stand and what is expected.
In today’s fast past world, having a strict and solid process may not be the best. But doing away with a process is even worse. The method that we are proposing is to create that ideal process, but only use it as a framework and discuss it at the onset of projects to make sure that people are on the same page.