Building in digital can feel a lot like playing with LEGO®. Sometimes, it’s cool to freestyle and see what odd things you can come up with, you can use a set in new and interesting ways. But, sometimes you just want to follow the instructions, build the thing on the box, and take satisfaction in a job well done. In the case of building a website or engaging in a project of similar scale for a client, you absolutely want to build the product on the box.

And for all of my dreamy weamy Young Lions who will growl and insist that we must be more free thinking, I’ll agree that we can set our own limits and blue sky to our hearts’ content — provided that it is for OUR projects, not our clients’ projects. But in the more sinister and grimy world in which we like to get paid and buy groceries for the goldfish, you want to have a nice clear gameplan for how everything is going to run. Every step is defined, from the beginning to the end, especially framing a payment schedule and your final deliverables (files and assets you turn over on completion).

Establishing Our Process

Let’s follow the example of building a website, a process with which I am very familiar. There are a lot of tasks that have to run smooth and clean, so we need to segment them into clear stages to insure that things do not spiral into endless work and rework:

Describe > Define > Design > Develop > Deploy

Each of these stages is intended to be as distinct and self-contained as possible, and builds on the previous stage (approved description leads to definition, approval there leads to design, etc). Each stage has a clearly defined end goal that leads to the next, final stage resulting in finished fileset.

First, we talk about what it is we are trying to build, make sure it is something that is possible given the resources at hand. This is the domain of the Project Manager, and they make sure that there are enough heads at the table to cover all tasks required for the project. The PM will continue to oversee things and ensure that all deadlines and expectations are being met.

Then, we have definition. There should be a Copywriter and a User Experience (UX) designer in tandem, working through each stage and level of the site experience, collaborating on the roadmap. When the definition is complete, there are no unknowns or “We’re still working through what we’re going to do here in this lil sidebar”. And the term “roadmap” is somewhat literal, the end deliverable here should be a wireframe set that will inform the design and development process.

Next up is design, which is where this thing that started as a conversation-turned-checklist and was finessed out into a set of wires will start to look like something that we can recognize as a website. This world belongs to Designers and Art Directors, and their responsibility is to make sure that there is a cohesive visual language for the project.

The finished design is handed off to the Developer(s) involved so that the various pieces of the site can be constructed. There is basic front end structure, fancy pancy styling, a level of interactive engagement, and another level that handles content, and… a lot of hats to wear. Sometimes something can be small enough where a single dev is enough, larger goals should allow for larger teams. As a front end resource, I am very fond of WordPress for taking care of a lot of those back end and CMS issues.

On the other side of development, we now have the working model, all gather around it to work their spit-polish magic. There might even be a specialized Quality Assurance (QA) resource involved to make sure everything matches a standard. Once this review work is completed, the site is pushed live, deployed. There was a process in place, we followed it, we got it live. No last minute re-writes or “I changed my mind — ADD THE CROSSWORD PUZZLE BACK IN” notes from a client.

At the Factory

The very first team production I was a part of was with an elearning company; we built educational materials for a big-box electronics superstore. Their brightly-shirted employees are constantly updated about various products and technologies, we made template-driven brochures that could be easily snapped together with a few assets. It was a four screen click-through, with the final screen being an interactive game to quiz the user on what they had learned.

There was a Writer/QA, a Designer, a Developer. Tight, neat, efficient team. The library had some variations, so we were able to provide some variety in our end products, and sometimes the Designers & Developers had to “break” the template and make something interesting happen. Most of the time, for my dev role, it meant cloning a template file structure, drop graphic assets into this folder, edit XML to control module content in that folder, do first pass review for any quick catches, submit piece back to QA.

There were teams of these resources, and I was part of a Developer group, one of four. There was a Designer team, another four. The Writer/QAs, another four. And that was one team of two, so every morning at the Developer roundup there were the eight team members, the meeting run by the three senior developers who tackled larger issues. Then a team roundup, where you meet up with the other eleven in your group and go over everything on the big tracking board, all activity was booked out for three months. This was bittersweet in that you could see the end coming, when it finally came.

Down sides to this approach, there were a few. While it was fast simple work, there was a LOT of it, high volume with quick turnarounds. You would have to juggle several projects at once, doing your new module builds in the morning, afternoons were addressing notes from QA.

In the rare occasion that we did have some downtime, we were expected to keep our teeth sharp. The problem there is that it’s hard to switch out of Edit Monkey and into Code Mancer to build exciting new excitement if you are doing a TON of repetitive work. All of the really hard stuff that none of us juniors could crack was kicked over to the mysterious Canh, a true moonlighter who would deliver miracles overnight.

I still have a massive craftcrush on Canh, he’s still doing killer work.

But the overall experience was valuable, I learned how to build webthings in a factory setting: Large Scale Production. Flashbacks to working in a copy shop in Evanston IL, finding myself hand collating and assembling info packs, bookbinding, more than 200 copies and we need them in the AM. Some things don’t change, just the scenery. A large amount of repetitive tasks with great urgency.

Meanwhile, at Korpi…

I found my warm gooey place in smaller scale environments, and one particular team that I like to think of as the Voltron Medusa. This followed the same principle of specific talents to tasks, but there was only one team, The Team. I was one of two Senior Developers, there was another full time junior dev and a dev / designer hybrid. An Art Director / Senior Designer, three junior designers. Team leads were Copy Writer and the AD, and we Senior Devs had our regular roundups with them to make sure all of their starter ideas were feasible in our little web kingdom.

What made this extra awesome was all of the junior talent that we had, the Truth of Voltron Medusa, the five of them worked in different combinations to knock out the daily dogfood AND do fun little screwball projects. We were an odd little department in a much larger organization, most of our antics went unnoticed and underutilized, but we were in much better shape as a team and as individuals. We got the things done that needed done, and had a clear process in place at the house that allowed the extra bandwidth to remain creative.

All of it was possible because we were all clear on the steps and had each others backs if something was trying to break process, break schedule.

It didn’t matter to us that we were essentially invisible inside the organization, we were all inspired by each other. It didn’t matter that the dog food was repetitive and bland, but with process we’d just get it done and do something fun. We were able to take Friday afternoons almost completely off (Seniors always see emails) and it was a cool atmosphere to hang your coat.

In comparison to the other experience, a little more tragic. While I saw the stint on “The Farm” ending well in advance, this one hit me like a gut punch. We had done well, a thriving little creative clutch in the org, and had the blinders that comfort and contentment can bring. I had the right people telling me the right things, the org was going to invest to lock us in, etc etc etc. In the end, my contract was allowed to quietly expire. So it goes.

Fail to plan…

If you’re just starting out in something, you want to make sure that you have a process for what you are trying to do defined, even if only to yourself. There’s an end goal that you are trying to hit, you have the steps that lead up to them charted. Break down specific tasks (writing copy, designing, coding) into specific stages, otherwise you’ll be in the spin cycle forever.

And honestly, back to the point of it all, it’s a lot easier to have a payment schedule figured out once the stages and mile markers are in place. A client will be super comfortable cutting substantial checks if they know *exactly* what the costs are up-front, and when they can expect to see the other side of the finish line.

“If you fail to plan, you are planning to fail.”
– Benjamin Franklin (inventor, politician, marijuana farmer)