Process, and File Conventions / Organization
When it comes to structuring projects and active source code, I try to lean towards simple and semantic. Mostly.
We’re in the middle of upgrading our office IT infrastructure, so I’m taking the opportunity to overhaul our weak, inconsistent, all-too-organic and out-dated organizational system.
No small task.
I think our biggest problem in this area is the challenge of consistency, given the broad nature of our projects, which include Motion Graphics, Web Development, and Print. Our process flow (per project) can change as well. Sometimes we’re implenting existing art direction and sometimes we’re generating concept and IP from scratch. How does one quantify all these variables into something consistent and understandable.
And why the fuss, you ask?
Several reasons, including:
- Less work. Currently, it feels like we’re creating new processes and workflows from scratch with each project.
- Easier collaboration. If everything’s consistent, then team members, both internal and external, can work together easier.
- Less screw-ups and less redundancy (means higher efficiency)
- Because our memory ain’t so good. We forget what we did how and why only a few days after a project is done. Nevermind a year later.
- Little client updates and changes (the things that can end being the most unprofitable and disruptive) become a snap.
Here’s what some people have to say on the matter:
- Software Conventions and Process for Start-ups (holy crap overkill, Batman)
- rewindlife: Some thoughts on organizing source code [PART 1]
Something else I wrestle with is how tightly to integrate our file structures and organizational schemes with our idealized mod7 ”Process“. My definition of process (in the context of design) is: a system or set of activities that brings about a logical set of solutions to a given need or problem. At my process lectures, I talk about an “activities template”:
- Research
- Rapid Prototyping
- Concept and Style
- Iterations & Blueprinting
- Production
- Execution / Publishing
- Wrap-Up / Analysis (which, by the way, we never do enough of, if at all)
Each of these activites employ the classic design subcycle:
- Discover
- Prototype
- Test
The ideal convention will also be self-documenting. You shouldn’t need to go through a project later to “clean it up”; chuck out stray files, rename oddly-named comps (finalfinal2b.psd), write a ton of explanatory docs. A good system, when followed, should eliminate all that.
A good system should also be flexible enough to encourage play and unexpected discovery.
Sounds easy enough.
