The Ultimate Guide to Managing your design projects – Part 2: The history of Proof Lab

I’ve always had a strange combination of passions – art and business. I don’t think these two areas of interest are typically held by one person. But for me, they are. So, it was no surprise that when I started Go Media I was consistently thinking about the business systems side of being a graphic designer. How do we keep track of our projects? How do we track our time? How do we deliver proofs to our clients? I was anxious to start building these systems for Go Media.

The Zip Line

The first real attempt at building a project management system for our design firm was a zip-line. At the time (2002), our firm was just two guys operating out of the first floor of a beat-up old house. The zip-line was, literally, a metal cable that I strung across the dining room where we had our desks. From this zip-line, I hung clear plastic envelopes that held copies of invoices that I had typed up in Quickbooks. The details of the project would be on both the invoice, and a sheet of paper that I had at our meetings. Any client documents that needed to stay with the project were also placed in the envelope.

This seemed like a fairly simple and effective project management system. The problem was that this system was overkill for a firm comprised of two designers. I was spending a ton of time taking notes, typing everything up, printing it out and hanging it on the line. About 50% of the time, I was the one doing the work – there was no point in me documenting everything. I already knew what I had to do! And the other 50% of the time, I could have simply spun around in my chair and told Wilson directly what work he had to do. Essentially, it was a system larger than our firm. We learned then that company systems must grow with your firm. When you’re small, you won’t need many policies, procedures and systems to manage your design services. But as you grow, and get bigger – you’ll slowly need to add more and more. So, we took the zip-line down and went back to our previous project management system – talking.

The client problem

Simultaneous to this project management system failure, we realized that we WERE having problems delivering proofs to our clients. For whatever reason, I still can’t understand why, our clients were having a hard time receiving and opening .jpeg proofs from us through e-mail. Perhaps their ISP’s thought our attachments were viruses. Perhaps they had malware laden computers that wouldn’t let them open .jpegs. I can only imagine. Whatever the reason, we had a problem that we needed to fix. The first solution was that we started posting images to the internet, then sending a link. This worked much better, but we were posting all these images manually. I’m not even talking about using a service like Flickr or Facebook. I mean, we literally built a web page for every single proof and posted them online.

Prooflab, v1

It wasn’t long before we realized how ridiculous this was, so – we built the original Prooflab. It was a very simple online tool. We would fill out a form and select our proofs. Prooflab would build a web page with our proofs on it and send us a link. We would then forward that link over to our client. From there, the feedback loop was just as if we had e-mailed the proofs. The client would either e-mail us or call us with feedback.
go media website v1
As we grew and changed over the next three years, it was becoming apparent that we would once again need to develop a system for managing our projects. Our staff had grown from two to six. We had switched from flat-rate billing to hourly billing. We were landing larger projects and we were gaining a large number of out-of-state clients. All of these things presented us with challenges that we thought we could solve with some web-based software.

The hunt for pre-built software

Our very first thought was to build our own web based system that would allow everyone within Go Media, and our clients to log into a central website where they could review their projects, proofs, communicate, log time, etc. etc. But then we realized how much time and money it would take to build our ideal solution. So, we scrapped that idea and decided there surely must be some web-based software already built for running a design firm. We probably spent about three months doing research on what software was available for running a design firm. There were indeed a variety of solutions out there. Today there is probably three times as many options.

Unfortunately, nothing we found worked the way that we ran Go Media. And had we decided to use one of these other project management solutions, it would have fundamentally changed who Go Media was. At the end of the day, a business is its systems. Despite the many hours and expenses involved in building a system like this – we knew we had to do it. There was no other way to capture our unique corporate culture. We believe strongly in legendary customer service, transparency, infusing the design process with fun, and open communications between designer and client.

Prooflab, v2

It took us about a year and a half to build Prooflab version 2. It was a major leap forward in functionality from Prooflab 1. There was nothing earth-shattering about the functionality, but it was structured and functioned exactly as we ran Go Media. So, in that regard, it was special.
prooflab v2 login page
The basic structure of the site was as follows – both the client and the designers would log-in through the web. Once logged into the system, they would see a projects queue (a list) of all their projects. The list would include things like project number, title, client (or designer), status and deadline. You would click on a project to see the project details. The details of the project included items like: general description, project specs, hours logged, correspondence, proofs and design team. From there, the user could post/review proofs, send an e-mail or edit/request changes to the project. Oh, we also had a file repository. But that part of the system was so poorly designed and so buggy, that I don’t think we ever really used it. The system also sent out standard e-mail notifications. These covered general alerts like: “You’ve got Proofs,” “You’ve been assigned a new project,” and “You’ve got mail.”
prooflab v2 project queue
Prooflab V2 was far from perfect. It was horribly buggy, parts were poorly designed and we found that we simply didn’t use some parts. But, despite its many warts, it was a huge success. It was much like a slow and buggy computer. On one hand it could frustrate the heck out of you. But on the other hand, you couldn’t live without it. Assigning projects, organizing specs, logging time and posting proofs became an organized and efficient process within the company. And, to my surprise, our clients loved it. They went out of their way to tell us how much better their design experience was now that we had the Prooflab. Some clients even asked how they might be able to use Prooflab for their own company. It seemed there was a need in many industries for project management software.

The Prooflab version two hasn’t changed much in the last five years. We fixed a few small bugs and turned off some capabilities that we never used. We realized early on that the next generation of Prooflab would require a complete overhaul. So, we kind of stopped trying to fix and improve it. However, we did continue to take notes on how we could improve it.

Prooflab, v3

About two and a half years ago we really started serious work on Prooflab V3. For about a year I would get a third of the way through the redesign then realize it could be better. I would scrap what I had been working on and start over. Finally, on about the third go at it – things started to click. Of the utmost importance to the version 3 upgrades was the fundamental structure with which Prooflab handled the organization of the information. Additionally, we were constantly asking ourselves how we could keep the interface as simple and ergonomic as possible. The system had to be so simple and intuitive that a baby could use it. And yet, it had to manage very complex projects and piles of information. With this in mind, we tried to build intuitive layers of information; giving the user only what they need at any given moment with a clear path to more information.

As of today (June 16, 2011) we estimate that we are about ready to start internal beta testing of the new prooflab. Assuming all goes well, perhaps we hit the market two months after that (maybe in August some time?).