I know this place has been quiet lately, but there is good reason for it. For the last month or so my fellow LABOV co-worker Lauren De La Cruz and I have been putting the finishing touches on our in-house web process. It has been over two years in the making, but we now have a comprehensive method for us to efficiently and intelligently develop websites where we work, LABOV. It guides us through everything from the first client call all the way to launch day and beyond.
Getting to the finish line was a long journey. The first major obstacle was the collecting, organizing, and distilling of all the concepts and ideas swirling in our heads. Just getting that all in one place felt like a huge accomplishment. Then, we had to the sift through all the techniques, practices, and tools we had noted, bookmarked, and tabbed over the years.
When we first started, I thought we’d be creating the type of process I read about online and in books, and had heard about at conferences. One that would revolutionize and modernize how we worked; it would pull us out of the stone age, so to speak, and transform us into a lean, top-tier web development team.
Then reality set in. The more I got into it the more I realized we had neither the number of people, long spans of time, large budgets, or types of clients to become the next Mule, Clearleft, or Happy Cog. The final process is not exactly what I had initially envisioned, but it is exactly what we, our agency, needs. Getting there required me to take a hard look at the realities of our situation. In the end, our team at LABOV, the type of clients we work for, our other internal processes, and a host of other factors became what shaped the process, not what stood in the way of it happening.
We named this process Clarity. In part, because its goal is to give our clients clarity when tackling a web project, but the name is also a nod to what it took to design it. I had to clear my head of those grandiose preconceptions and let the pieces that were already in place reveal the type of process we would develop. I guess that’s lesson number one for anyone else on this same path: Design your process around what you have.
Obviously, Lauren and I are pretty proud of Clarity and I think there are a lot of people like us who can benefit from knowing what Clarity encompasses and how it works. In all my research for this project, I read very little about integrating modern development practices into companies without teams of web development specialists already in place.
If I had to hazard a guess, I would say there are more of us out there learning as we tackle large projects than effortlessly gliding through another project with our team of highly specialized experts. We do not have the luxury of focusing on just one project, and “Web Developer” is probably just one of many hats we wear. With that in mind, I made the decision to do a series of posts that outline the entire Clarity process in detail. I want to show people like me that establishing, or modernizing your company’s web development process is possible.
In creating Clarity, I’ve learned that the sharing of what we’ve created is as essential as creating it. I have a deep respect for the open web, web standards, and the general spirit of “share what you’ve learned” in the web development community. Jeffrey Zeldman, Eric Meyer, Mike Monteiro, Jeremy Kieth, Brad Frost, Chris Coyier, Karen McGrane, and Ethan Marcotte (just to name a few) have taught me everything I know. I certainly didn’t invent any of the concepts in Clarity. If they had not shared what they had learned, Clarity never would have happened. My hope in sharing what I’ve learned is that more of not in the mainstream of web development can establish our own processes and build better websites.