Think of the Problem, not the Feature

Note: I’d like to point out that this post comes straight out of our design manual. It’s not going to read like a conversational blog post. I figure it’s just better to give you, the reader, the straight skinny.

Always ask “What problem am I trying to solve?” before starting any design.
The first answer you have is at least 90% wrong.
(you’re thinking like a software designer/developer, not a user).

This is the first thing we must ask ourselves before building anything. And, we need to ask this question over and over again at all stages of design, and ask it again after the feature is shipped. Ask yourself, “Is this solving the real problem?” instead of focusing on what the system lacks. There’s a big difference here.

For an example, take our messaging system for rejection letters. Sending rejection letters to candidates is something every company should do, but very few do. In fact, even companies with ATS systems don’t send rejection letters, yet this feature is commonplace. So we ask ourselves, “When designing our rejection letter feature, what problem are we trying to solve?”

The two first-blush answers you might have are:

“The problem is that companies can’t send rejection letters”
Answer: our product lacks this feature OR,

“Sending rejection letters is too time-consuming /people just forget to send them”
Answer: Send them automatically so that they don’t take any time and can’t be forgotten.

But if the above solved the problem, wouldn’t every company with an ATS already send rejection letters? We know that the feature is commonplace, but that they still don’t get sent. Our answer is missing something.

Why don’t rejection letters get sent? There are more answers:

“Sending rejection letters is time consuming and you have to send a lot of them.”
“You don’t want to send the same rejection letter to someone you interviewed 5 times to someone you never interviewed.”
“The perceived benefits (the actual benefits are a different story) of sending a letter are very low, so users will be VERY, VERY, VERY reluctant to spend time doing it.”
“Users don’t trust a system to send rejection letters for their company; they want to read them first.”
“You never want to send a rejection letter accidentally. The risk isn’t worth it.”

So let’s talk about how this feature has been designed and implemented in other software systems. A template is made so that when you pass on a candidate it automatically sends a rejection letter. Does this solve the whole problem? Hardly. This feature only reduces the time it takes to send a letter, but it doesn’t allow for on the fly customization/review, is sends the same letter to everyone, it is generally not trustworthy, and worst of all, it is inherently risky.

To be a complete, helpful, user-centric, REAL FEATURE our system must accomplish all of the following: it must NOT add any steps to the normal workflow; it must customize itself based on candidate status; it must be reviewable before it is sent; sending is optional.

Easy enough, huh? Think of the problem, not the feature.

Intro to Our Design Philosophy

Our Design Philosophy is a set of rules that we apply during our software development process and also to our finished product (which is never truly finished). The goal of creating and codifying our Design Philosophy was to have a set of comprehensive guidelines that are to be followed religiously at all times.

I’ll be posting these mandates individually, and when I get the time I’ll package them up into one web document. I’ll also sandwich in some posts on “Things We Have Learned the Hard Way” which, as you have probably guessed, are things we need to remind ourselves not to repeat.

Disclosure: While my aim behind publishing these is many-fold, I’ll try to keep my disclosure to the point. If I accomplish anything in these posts I’d like you to catch a glimpse of the thought processes that have driven the design of our software. And in doing so, I hope to make it a bit easier for you to appreciate why we believe this thoughtfulness has made Newton the best recruiting software on the planet: the easiest to use, the easiest to start using, and the most productive out of the gate. And we want you to see how our focus on users, not features has enabled us to create a software application that almost anyone can use, from day one, without headaches or hassles, to add time back to their day and cut days from the hiring cycle.

But first, a little background on our design philosophy…

My girlfriend is a Director of Sales at a successful media company (I am not making this up; there is a woman on this planet that can put up with me). Her employer uses a very well-known software application for tracking accounts, customers, leads and opportunities (it’s very likely your company uses it too). Before each and every sales meeting, everyone exports their data to Excel. Why? Because the VP of Sales can’t figure out how to use their sales software.

Does this software need more features?
(BTW, I just broke an edict of Newton’s Design Philosophy by asking a stupid question. Good thing I’m not designing software right now.)

As the person responsible for the design of Newton, I’m always looking at products and asking myself questions like that. My ears are ringing. Your ears might be ringing too.

Where’s the noise coming from?

Feature cacophony.

It’s no small secret that software companies are under tremendous pressure to build more features. It certainly seems logical that if you have the most features, you’ll sell the most software (it also makes those checkbox “Us vs. Them” charts on your website look really long and cool).

Unfortunately, I think a lot of software, and especially ATS software, has lost focus on the most important feature of them all: users.

You say, “Users aren’t a feature, smarty pants.”

Hmmm. If a tree falls in the woods…If no one ever uses a feature, is it a feature?

I ask this because I would bet that if you’ve ever hired someone, you didn’t want to use software to do it. Maybe you were forced to use it and thought of mutiny.

I’ve witnessed this first hand: people in a hiring role hate using software for hiring. But in all my years I never heard someone say the reason the hated the software was a lack of features. Not once. In my case, I’ve used a lot of different recruiting products over the years and I’ve learned they ALL do one thing very well: they make hiring harder for everyone. The software you need to be forced to use makes you less productive. Brilliant.

Obviously when people can’t, don’t, or must be forced to use software you’ve developed you have a problem. The seemingly obvious solution to this particular problem is to build more features-innovations a mile wide, an inch thick.

Problem solved?

This line of thinking brings us to the first rule in our Design Philosophy-

Always ask “What problem am I trying to solve?” before starting any design.

In our industry the problem we’ve identified is that recruiting software doesn’t make it any easier, simpler or faster to hire someone, and most people don’t like using it.

Our solution: Focus on building software that boasts a lot of users, not a lot of features.

The user is a feature.

Enjoy.

PS. Hello World!