Ben Guttmann
When I was in fifth grade, our classroom got a tank full of hermit crabs. I’m sure we had some science-related lesson that involved them, but I really can’t remember anything besides how cool it was to have these little alien creatures on our desk – and that, somehow, the teacher let us each take one of the crabs home to keep after the unit was over.
I was obsessed with my new pet. I even begged my parents to take me to the pet store and get him a friend. Suddenly, there were two crustaceans in the Guttmann household.
So, when the time came to pick a project for my final assignment that year, I decided to do mine on hermit crabs. And since my other momentary obsession was playing around with a piece of somewhat-janky software called The Print Shop, which let me make brochures and flyers, but also had a funky little website builder, I chose to build a website as the project’s format.
I was ten years old, and I didn’t know a lick of code. But I wrestled with that software, my first Hotmail email address, and a GeoCities account long enough to get something on the web.
More than a quarter-century later, that site, like those hermit crabs, is long gone. But the moment, even as early as it was, signaled a shift.
A generation ago, it took a lot of technical know-how to build a website. So, the people that built and managed them were technical people. And, despite a parade of advances in the years between, things just kind of stayed that way.
Through my years in the pixel trenches, I’ve seen the same problem happen again and again.
Clients feel that if they want to be taken seriously (and not taken advantage of), they must dump an alphabet soup of jargon into their RFPs. They need to specify a specific version of WordPress, to name a hosting provider, and to spout off something about HTML5 or PHP 8.3.11.
But the truth is, for most brands, none of that stuff matters.
Let’s say you’re a non-profit. You might need a site with a blog, a few pages about your programs, a list of staff members, and a contact form. These are all solved technical problems. You don’t need a team of Stanford computer scientists to make that happen.
Indeed, a team of Stanford computer scientists will likely make you a terrible website.
What you do need to focus on is making sure all those things get your point across. You need those pages and elements to inform and persuade. That’s a messaging problem, not a technical one.
A few years back, I wrote about my enthusiasm for Webflow and other no-code tools. These platforms are so important not because of the things they enable, but rather because of the people they empower.
By removing code from the equation, now your organization’s website can be pried away from your technical team and handed to your marketing one. Considering it’s often your biggest single piece of owned media, that’s where it belongs.
You don’t tell your printing press to design your catalog or your television network to shoot your commercial. We used to – but then those platforms matured, and designers and directors were empowered to do what they do best. These creative professionals deal with the message and let other professionals deal with the technical details.
If you’re building some giant e-commerce operation or an intricate SAAS product, then you can pretty much ignore all of this. But if you’re almost anybody else, here’s your permission to stop sweating about code. Don’t worry about the paint, pay attention to the painting.
