- December 6, 2016
Ditching Precious
- @hoyboy
- CEO / Partner
A philosophy our company has subscribed to over the years is to sweat every detail. It’s a core value of ours, driven by a passion for crafting the most usable, accessible, and beautiful solutions possible for our clients and their audiences.
Our default posture has always been to take sufficient time to toil, tinker, and massage. And while that will always remain a core philosophy of ours, managing to that standard is complicated.
Sometimes, when sweating those details, we fall prey to our own designs. We’ll craft solutions that articulate an ideal state, regardless of whether or not it can actually be pulled off, either by the technology we’re using or our client’s capabilities. Fairly or not, an approved design direction is often perceived as a contract. It’s what will be built, dammit. The burden then falls upon everything else associated with the project to service that expectation. We become beholden it. We hold it precious.
There’s a danger of being obsequious to your design work. It may very well prevent you from delivering what might really be needed for the project you’re working on.
We recently took on a ‘pet’ project so we could work on something outside of our wheelhouse, as an experiment and a learning opportunity. The budget was purposefully tight, and the idea was to staff just a couple of people on it in order to execute efficiently. On paper, it made sense—I had a lot of subject matter expertise with the client, we’d use an unfamiliar publishing platform that didn’t rely on our client’s ability to code (giving us the ability to kick some tires), and we’d streamline our workflow. If all worked to plan, in the end, our client would have a roll-your-own foundation upon which they could spin up microsites to service their marketing campaigns lickety-split, without needing to jimmy CSS.
So what happened? We became too precious about our design work. While our client loved our design (good news, right?) we became fixated on staying 100% true to it. And as we began integrating it, we ended up with issues stemming from the constraints of the publishing platform we chose. It became clear we’d need to sidestep the platform in several ways to maintain the integrity of the original design, which resulted in lots of extra hours spent on custom code. In the end, we scuttled some of the functionality that made the publishing platform a compelling choice in the first place. Raise your hand if you’ve been through this before.
So what should we have done? Perhaps we should have accepted and articulated that while the original design would serve as a benchmark, it could undergo some adjustments during integration. Or, to design within the publishing platform itself from the start, so as not to design beyond it.
Alas, this does not lie on the shoulders of my talented coworkers. They are always working to deliver what the client expects, and nothing less. But my decade-long drum-beating has perhaps contributed to a culture over time that compromise, especially downstream, can be rather un-Cog-like. It’s perhaps always been “stick to your guns and make it work.” To boot, because of my familiarity with this client, I placed myself at the center of this project. We know what happens when the boss gets involved. I surely contributed to the heartburn.
Despite all of that, I truly believe this: in an era where delivering value demands acute understanding of what really moves the needle for your client, it’s quite acceptable to make concessions to satisfy needs. “Concession” isn’t synonymous with “shortcut.” Conceding is often just ditching preciousness by honoring the spirit of an idea, not how it was originally rendered.