Clever Developer Syndrome
It’ll bite you in the ass.
As I type this, I’m taking a break from rewriting much of the code in our product, Minimalytics. We launched a trimmed-down version to a portion of our beta list a few weeks ago — and the feedback has been great overall. But our users have nothing to compare our product to.
Last week, we realized we could be approaching the problem from an entirely new direction that would be so much better.
The core foundation I laid originally is great, but everything our users experience needs to change.
How did we get here? I got clever.
I tried to be creative about how to solve small design problems.
We don’t have/can’t afford a dedicated designer, and over time, my cleverness led to a tower of creative and technical debt.
It started when I made the decision to mirror our interface to that of an email composer. See, our product schedules recurring emails that include your analytics from various apps. So I thought, what better way to communicate that this isn’t a dashboard but rather a recurring email, than to make our app look like the actual email you’ll be receiving!
Now if I stop there, it sounds like a good idea, still.
But what hurt us, are the hundreds of micro-decisions that follow a macro-decision like this one.
Here is an example:
The “To:” form field.
Since we’re modeling an email composer, we need to be able to add our recipients in this format:
John Doe <john@example.com>, sarah@example.com
This is what people already understand when writing an email, so let’s go ahead and do that. All we need to do is parse a string, split it on the commas, and then decide if it’s a name and an email or just an email. Then save that to the database. But then if the name is different from the last time they used that email address, we should probably update the name in the database — but only if they provide a name. We wouldn’t want to delete their name just because the user forgot to include it one time. […] Ok. More complicated than I thought, but whatever, it’s worth it. It supports the email composer direction, so it’ll be good for users. It’ll be familiar.
A couple hundred lines of code + test code later, and I’m ready to move on to the next piece of the interface! Yay! This is all working great :-)
Wrong. So Damn Wrong!
I’m sure you’ve all experienced a feature like this one. A feature that is only present to support another feature. One that you have a hard time imagining how difficult it will be to support, because it is so small.
Every decision, every feature carries technical debt, no matter how invisible it may seem.
We’ve learned our lesson through this process, and will be avoiding clever solutions in the future because:
- It’s confusing to first-run users, their focus is shifted towards your implementation, albeit nice, of something that doesn’t necessarily matter.
- It constrains future options. Every little feature that supports a clever macro-decision, carries with it a bunch of JavaScript and possibly backend/database weight which will slow things down later on.
- If you really think it’s the best possible approach, save it for later. Start with the simplest possible interface, and improve it after people start using it.
For our product, the magic happens when you receive your first email with metrics in it. But we focused all of our energy on the experience around drafting that email.
So Let’s Fast-Forward…
We have decided to move away from the email interface, and move towards a simpler solution that focuses purely on adding metrics to emails, and getting them in your inbox. This is what people have struggled with most in using our product. Behind the pretty veneer of an email composer, there was a 3-stage modal triggered by an Add Metric button. This launched a bloated process which left many confused.
It didn’t receive as much polish because we were focused on the email composer direction, which left us no room for a metric-adding interface…because that isn’t present in email composers. So it was put aside, behind a wall, even though it is so much more important than the actual email itself.
When planning your product, it’s critical that you’re able to spot these macro-decisions, and that you understand the implications of a bad decision.
I’m not promoting moving slowly, or hiring a full-time designer, if you’re unable. I’m simply preaching deep-awareness, something that I temporarily lacked — and something that is now, biting me in the ass.
I’m Matt Goldman. I’m currently working on a couple of products,Minimalytics and HookFeed, with my girlfriend, Joelle. If you have any questions about this article…I’m @SDMattG on Twitter.
