Concept development starts with an idea, moves to conversation and drawings, then to prototypes and finally to a functioning system. This is some of my favourite work.
When I start with a concept, I work it through using a whiteboard and a large cup of coffee. In this stage it’s generally a bunch of boxes with lines coming out of them (and some notes to fill in the blanks). This tends to be a very collaborative time – this is when you can see if a project could work.
Not every concept passes this stage (working through things this way often shows problems that simply can’t be overcome). However, this is a great time to “flesh out” a concept. Ideas flow quickly and this is the least expensive time to add them. If a project concept passes this stage, I generally mock something up quickly and prove that the “big rocks” can be dealt with.
From there, I formalize things out and develop a scalable, maintainable system. This may involve setting up a proper project system (everything from a source control system to staging and production servers).
I believe in an iterative style of development. I’ve worked using various agile methodologies as they formalize this kind of development philosophy. At the heart of each of these formalized methods is the premise of building something quickly and revising it often.
In practice, that means that I have to view a project both from a top-down and a bottom-up perspective. When I interact with the client, the perspective must be a top-down, features based perspective. When I develop, it is exactly the opposite. I must look at the system as a whole and create the fundamental underpinnings in order to create something that is stable.
The end result is a completed project that everyone can be proud of – even if it has only a single deployment in a single office.