Newton is the simple, smart, safe recruiting platform designed by recruiting professionals to help you hire.

Request a Demo

Newton Design Philosophy: 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 the messaging system for rejection letters found within Newton. 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.

About Andy Chan