This post was written back when Adelie was openly accepting new inquiries and projects.
In 2005, psychologist Barry Schwartz took the stage at TEDGlobal in Oxford and proposed an idea: that “more is less.” You can watch the full video here, but the core idea is simple. To quote Schwartz, “With so many options to choose from, people find it very difficult to choose at all.” He tells a simple anecdote to that effect: many years ago, when he walked into a clothing store, there were only a few pairs of jeans to choose from. Other than size, there wasn’t much variation.
The modern denim landscape, he laments, is not so simple. There’s boot cut, straight cut, skinny, acid-washed, “raw denim,” low-rider…it goes on. A hundred variations and a thousand brands to choose from. Faced with so many options, Schwartz is left to wonder: “which?”
For the trendsetters and the fashionistas, and for those who simply like to explore their options, an abundance of choice is a wonderful thing. It’s certainly preferable to the past. But there are those who share Schwartz’s lament: sometimes, you just want a new goddamn pair of pants.
Both of these people deserve to be fulfilled. But the mechanisms required to accommodate them are a bit contradictory:lots of choice vs very few choices. What’s a clothing manufacturer (or web developer, in my case) to do?
Schwartz offers a pithy summary of this dilemma, although it’s more of a resignation than a prescription:
“There’s no question that some choice is better than none_, but it doesn’t follow from that that_ more choice is better than some choice. There’s some magical amount. I don’t know what it is. “ — Barry Schwartz
Okay — so how does that relate to web development, and to business overall?
Yeah…? Yeah.
I’m a web developer. I make websites. Some time ago, you’d write some HTML and open it in a browser. Bam, done, you’ve got a web page. It was basic, but it worked, and it worked well [NSFW: Language].
Then came CSS, a shiny new tech that allowed us to style web pages. Ooh, shnazzy!
The notion of skillfully designing a web page — as opposed to just making or writing one — became a thing. Form and style were introduced to what was mostly a mechanical, functional task. (You make toast, you design wedding cakes.) Then came Javascript. Now we could make our buttons dance and flash and stuff! Sick. Then came PHP. User accounts! Forms! Validation!
(I’m over-simplifying and omitting a ton of details, but you get the point.)
To list every web tech thingy would take hours, and new stuff comes out every month.
In short: dozens of shiny new technologies began to stack on top of each other, giving websites new life and functionality. But with the influx of technology came an influx of choice. And we loop back to echoing Schwartz simple plea: “which?”
There are now hundreds of ways to make a site. I’m not exaggerating. And since we, as web developers (although this applies to mostly any business offering a service), are the ones who inform clients of their possible options, we are the ones faced with the dilemma: how many choices do I present to my client?” And more abstractly, how much decision-making power does each party have?
If I was a terrible web developer (and just a terrible communicator in general), this is how I would talk to my clients:
So what’ll it be?
Imagine that bull? To be fair, spitting out a laundry list of names like this (a form of “name dropping”) is tempting for a couple of reasons:
But again, none of these are valid reasons, and they have drawbacks. Laundry-listing is an inefficient and vaguely pretentious way to communicate; it stagnates meaningful progress, and it should be left to die in the internet forums of 2003.
Consider these alternatives:
Much better. With these alternatives, I don’t bombard clients with a nondescript list of options. I respectfully offer my recommendations (and the reasoning behind them) to the client. This gives them a starting point, a basic schema to start really understanding what their options are. If I’m unable to make a singular recommendation, I narrow it down to 2 or 3, then open the way to a more nuanced discussion.
Regardless of your industry. My examples and subtler points may cater to web development, but regardless of industry: too much choice seems to have a paralytic effect. It turns your client or customer into Barry Schwartz at the clothing store, unsure and frustrated about how to proceed. In my case, laundry-listing options underutilizes my knowledge and places the burden of choice on the client, who is presumably less informed. It’s a disservice to everyone involved.
If you go to the doctor with an ache, it’s not his or her job to exhaustively enumerate the fifty-some-odd conditions you may have; it’s their job to diagnose you and then offer their educated prescription.
If you go to a tailor to get a dress fitted, it’s not their job to detail every possible alteration; it’s their job to take your measurements and, in accordance with modern trends and accepted best practices, make the best cut.
If you tell me you need a blog, it’s my responsibility to analyze your needs, consider your circumstances and then offer my informed suggestion: that your best bet is with X, as opposed to Y or Z.
To some (or, I fear, to most) this is an obvious idea: “Obviously, the professional should be the one making the recommendations.” If you simplify it, that’s what this entire article boils down to. (Hey, I don’t claim to be breaking new ground in regards to business operations & ethics!)
But there is a small asterisk to this idea. A simple, practical realization that was new to me, one that I wanted to share.
This model of interaction (where the developer guides the decision-making process) is inherently cooperative. It requires trust. Particularly, trust in the developer’s ability to do their job.
(Contrast that to the “laundry-listing method,” which requires neither trust nor cooperation — the client is making all the decisions.)
Without trust, this process fails. Some doubt from the client is wholly expected and justified. But sometimes, there will be clients who will literally peer over your shoulder as you work.
And here’s the realization that I wanted to share: when this happens, it’s okay to assert yourself. Officially, and on behalf of the business. Or to walk away. In fact, you could do both of those things, in that order.
Respectfully, of course. As a professional, unconditional respect is a must, but don’t fall into the trap of “unconditional courtesy.”
If a client wants to make a suboptimal (or terrible) choice, I will:
But if it’s the latter — leaving the project — I no longer feel guilty. And you shouldn’t either. Your job is to help your client, to offer them great service at a reasonable rate, and to be respectful — but that doesn’t mean entangling yourself (and your business) in a project destined for failure (or mediocrity).
If a patient wants to amputate his leg in order to fix a tooth ache, it’s a doctor’s job to dissuade them. If they insist, then it can’t be helped — but that doesn’t mean he has to be the one to perform the surgery. If a prospective client of mine wants to build “the next Facebook” using Tumblr and some “proprietary algorithm” that he scribbled on a napkin, it’s my job to dissuade him. But if he insists, I’m walking away.
And a bit overdramatic. The vast majority of clients and customers are wonderful people who aren’t trying to build “the next Facebook” for $100. Jobs go swimmingly, and everyone’s happy.
But this is an important point that’s often forgotten: that we, as professionals providing a service, are not here to spit out an exhaustive list of possible options. Part of our worth as web developers lies in our ability to produce code, yes. But the other part — I’d argue, the more valuable part — lies in our intangible knowledge and experience. In our ability to guide decisions, solve problems, and make recommendations.
Whether you’re a web developer writing code, a graphic designer designing an infographic, or a sales associate for a hat manufacturer, I urge you to remember that always: we are more than just the things we make.
By Kevin Oh on January 22, 2016.
View All Posts