This is going to sound crazy to the old guard enterprise software enthusiasts out there. Ready? It’s not about more features anymore. The game has changed. The features arms race is dead. More features is increasingly taking a backseat to better functionality, a close relative of usability. This is where user adoption comes into play, a concept that’s become the focal point of the business software industry. The less features an application has, the less confusing it is and consequently, more people are willing to use it. There’s a concept – people actually using a business application and not just finding ways to work around it.
What we’ve learned is that when software achieves something valuable without being distracting or requiring hours of training, only then will it live up to its potential (those enterprise guys call this concept “return on investment”). Let’s face it: it’s usually harder to do simple things exceedingly well, than to just pile up features. The 80/20 rule applies here too: do well what 80 percent of your users do all the time, and you’ll create a good user experience that promotes user adoption. That’s the goal isn’t it?
Here are some tips that we put together regarding promoting adoption for applicant tracking software. These concepts can be applied to just about any technology. Say goodbye to the age of killer features. Say hello to the age of the killer usability.
Effective user adoption is the absolute best predictor of a successful applicant tracking software purchase. You can have the most expensive software in the world, with the biggest name and the most features – but if people don’t use it, it isn’t going to add value. Today, the recruiting software industry is rife with vendors that continue to add frivolous features to their platforms to keep up with the Jones’ and to woo unsuspecting customers into impulsive buying decisions (this in turn makes their software more clunky and complicated so I’m glad they do it personally).
We’re marching to a different drummer at Newton. Adoption is everything. When users like hiring managers effectively adopt a corporate recruiting tool, productivity, collaboration, and efficiency skyrocket. Isn’t this the goal? We think so and we’re not alone. The Sandhill Group, a strategic management, investment and marketing group specializing in the SaaS industry, conducted a study and found that the most critical factor (70% listed it as number 1) for software success and return-on-investment is effective user adoption.
No software platform is magic. Some users will love it. Some users won’t. We design Newton to increase your chances of getting more users which ultimately leads to a more productive recruiting program and a significant return on investment. There are other benefits as well. The more users you get, the better off you’ll be as you’ll capture critical information that you’ll use to diagnose and solve problems (it’s nice to be a little proactive once in a while). You’ll also capture critical compliance information easier. When you have high adoption rates your recruiting platform will become the hardest working part of your solution.
Presently, the adoption rate for Newton is above 90%. We put together a short video to explain how we make this possible.
Our daily lives on the web have become more complex. People are looking for ways to incorporate simplicity into their jobs. But finding simplicity in the workplace is becoming increasingly harder every day. To make matters worse, many people still shy away from simple because they associate simple with a lack of power. Most software vendors still play to this fear. Their guiding principal is “features are power, add as many as possible”. This is especially true amongst applicant tracking software vendors.
There’s a misunderstanding of what it means to be simple. Many professionals associate simplicity with weakness or that which ignores complexities. At Newton, we look at simplicity as being synonymous with intuitiveness, clarity, and essentialness. Sure, we design features to add power but not if they risk simplicity. Features, first and foremost, must simplify tasks.
Our focus on simplicity from day one is our competitive advantage. We are ruthless in our efforts to simplify – not dumb down – applicant tracking software. We don’t just focus on design for aesthetic impact (it helps). We’re interested in the simplification of process. Others may add some window dressing from time to time but their beauty is only skin deep – slick. If you don’t start with simple it’s impossible to end up with simple. That’s the goal isn’t it?
Make everything as simple as possible but no simpler.
-Albert Einstein
“Please contact support.” Makes you cringe, doesn’t it? At Newton we encourage people to contact support—by email or phone. No, I’m not kidding.
We call it “Support Driven Design”. I’ll explain this concept in just a bit, but first I’d like to give you some background on how we came to believe that free technical support results in better recruiting software: it makes it easier to use, faster to deploy, and paradoxically, makes supporting your customers cost less (which in our case means we can sell our hiring software for less money).
In the beginning providing free technical support, like we do at Newton, appeared to be purely a business decision: giving away support makes the buying decision easier for people. We also didn’t have the time to build a big FAQ on our site, so we were pretty much required to do this personally anyway. On top of this, we also don’t like paying for support, or reading online help, and felt that we shouldn’t make our clients do something we don’t like to do. Today we think it was a good business decision, and an even better product one.
Of course we were warned. The “old-school” software folks, whose advice we openly take and whose success we jealously admire, told us that providing free technical support was a bad idea. “You’re going to have to charge for it sooner or later because it will eat your margins,” “support is a profit center,” they’d say. We’ve always had a problem with authority…
Design the Question Out of the System
One of the first things we tell any customer at Newton is, “If you don’t understand something, no matter how small, it’s our fault, not yours. Let us know.” We ENCOURAGE technical support emails and phone calls. Again yes, I am being serious.
As a result, and contrary to what you might think, we are hardly ever asked to provide support. The net result of Support Driven Design has been that today we get less than 1 support question per year per customer, or about .01 questions for each user per year, a group of business users can be trained in 5 minutes, and a recruiter in a mind-numbing 30.
In the beginning, and still today, our product managers, i.e. the people responsible for designing Newton’s applicant tracking software, did all the walkthroughs, customer training, and provided all support. Without knowing it, we had started a “Support Driven” design shop. When we’d get a question from someone, we didn’t add it to the user manual, we’d think about how we could redesign Newton in such a way so that we didn’t have to answer the question again.
I think this has been more than a modest breakthrough for us. Instead of teaching people how to conform to our recruiting software, instead of an online hiring FAQ, we take each question and “design the question out of the system”.
For example, early on we had this bad “More Info” button that people overlooked. Since all support email came through my desk, as it does today, I answered the same question three times in one week, “Where do I find this <something>?” One of our customers actually apologized for asking me a “silly question”! Have we come this far? Do software users really think that it’s their fault for not understanding something? Clearly, it didn’t look like a button, and clearly it was our fault. That week spelled the end of that button. Support questions: 0. Easier to use: 1.
The Tail Wags the Dog
Since we’ve never charged for support we’ve learned to appreciate that if we design a confusing feature we’re going to pay for it later. Since we don’t force people to an FAQ page, we know immediately when something isn’t working. The tail of support wags the dog of design: if you can’t charge for it, you better make it work right out of the box.
As a result, we often design a feature and say to ourselves, “we can’t do this, it will create support tickets.” This approach is not for everyone (especially for companies that get paid for making confusing software). It puts tremendous strain on our design process, and is the single greatest reason why it takes us 4 times longer to design (i.e. mockup, whiteboard, wireframe, etc.) a new feature than it does for our development team to build it.
The output of this also means that we can provide free training. We don’t like losing money any more than anyone else and if it took us 4 hours to train our customers, or 40 emails to answer their questions, we’d never be profitable. Free support: design the question out of the system + design rigor = easy training.
Maybe paid support is why one of the more common questions asked in an RFP is if we have an online FAQ. Think about that. Buyers are actually asking if you have a way NOT to help them. Our answer is simple, “just call us.” You might counter with, “well, I would like to just figure it out myself, without contacting support.” Tail wags the dog: you need an FAQ because the software is confusing, it is confusing because instead of designing your question out of the software, it was built into a support guide.
I think it is worth noting that people aren’t accustomed to this business model. People actually apologize for “bothering me”. One of the things we try hard for at Newton is to change this behavior, to “re-train” people (in 5 minutes or less, 30 minutes for recruiters <wink>) into believing that we aren’t doing them a favor for answering their questions, they’re doing us a favor by asking one. I think it speaks to just how far software has moved away from the user, and how far it has yet to go towards providing real productivity.
So the net result is that free support has led to less support. Like I mentioned before, we get about 1 support email per year, per client. I can’t imagine that Newton will ever have a technical support department that’s not run by our design team. Unfortunately, it’s gotten rather lonely over here in the support department. Can someone please contact support? Have I mentioned it’s free?
"We were not able to identify your contact e-mail address. Your login e-mail address will be used as your contact e-mail address instead. Please be aware that this contact e-mail address will be used to contact you."
The message above was sent to a prospective candidate from an applicant tracking system -not ours. This system is managing a fortune 500 company’s careers site. Yikes! It can hardly be debated that enterprise software is way too complicated and for the most part, pretty thoughtless when it comes to user experience. The message above is a perfect example. The expensive applications that businesses use to run their human resources are some of the least friendly, most difficult systems ever committed to code. If you work at a company that uses buinsess software or you’ve ever had to do something that should be simple, like apply to a job — or, heck, even look at a job on a corporate careers site — then you’ve probably encountered some really annoying user experiences.
How did we get here? Part of the problem may be that the people using enterprise software just don’t demand anything better. They think all business software has to be complicated – it’s all they’ve ever known. People have just been dealing with poorly-designed technology for so long that they internalize the flaws. Maybe it’s that a lot of these systems, applicant tracking software particularly, are built for “power” users so thoughtful, consumer-like, usability concerns are sacrificed for massive amounts of options that ultimately “sell” the technology. In the end, buyers do compare features and typically the software with the most features wins. But, the question that constantly nags us is – Does the user win? We think not.
Clearly, the real topic here, the usability of enterprise software, is a huge can of worms and I’m only scratching the surface of an increasingly incendiary topic. I can tell you this though; the “error” message above actually encourages us. It’s evident that a majority of our peers that develop recruiting software ignore design / usability. We don’t. It’s also clear that buyers of software are increasingly eager to find well designed software that improves usability and ultimately makes their lives easier. We like this trend, it plays to our strengths.
Finally, we want to make a public promise. We will NEVER send another human a message that doesn’t make any sense. It’s the least we can do.
Recently, I received a request from an industry analyst to outline our history. Unknowingly, she made a joke about how it shouldn’t take too long to put something together because we just started the company in January 2009. Little did she know. But, how would she know? No one here has really sat down and tried to chronicle the genesis of Newton. Frankly, we have been a little busy. There is, in fact, quite a bit of history though – almost 5 years. So, over the past week or so, I have been bugging our product managers, Steve and John, for their best recollections and even found some old screen shots. I tried to turn nearly 5 years of history into less than 2 pages of text – a long blog post. So, here it goes.
Newton is the brainchild of former recruitment outsourcers (that’s us) that began developing the product in 2004 after becoming frustrated with existing commercial recruiting technology. Having run corporate recruiting programs for nearly 10 years prior with paper resumes, email, spreadsheets and legacy software, we wanted to leverage the benefits of internet technology to help us provide a better service to our clients: we wanted something that would make rolling out, ramping up, managing, and improving hiring programs easier for us; we wanted something that offered a more collaborative recruiting experience for all users; and we needed something that was simple and easy-to-use for all users. After demoing a lot of recruiting products and even trying some, they all fell short in at least one area or another and ultimately didn’t meet our needs. We realized that they would have to build this system if we were truly serious about providing better recruiting services.
So, we designed Newton to address two areas where we thought the existing recruiting technology in the marketplace fell short. One, it needed to help people make hires so easily that our client users would actually want to use our recruiting system. We wanted to give our customers a login, conduct a short walk-through and have the user start contributing to the process immediately – no hassles.
Secondly, like many other recruiting systems, Newton also needed robust reporting capabilities, but we wanted it to be able to surface and report information in real time, so we could help companies continuously improve hiring programs on the fly. We knew if we solved the first major problem of most recruiting systems, user adoption, we could build a real-time reporting platform at some point that would actually have useful data in it (since most users preferred Newton over traditional resources, like email). Over the years, we focused on refining Newton’s usability and workflow to address ease of use eventually deploying it to users in mid-2005.
By early 2006, Newton was the recruiting platform for one of the country’s largest recruiting programs with hundreds of concurrent jobs, thousands of users and tens of thousands of active applicants. Newton had quickly become mission critical to dozens of companies, which gave our product team the unique advantage of being able to test and tune our application in complex, high-volume, and demanding commercial environments. With the addition of a full-time development team and a couple of product managers, Newton evolved even faster and became even more popular.
In 2007, still coupled with services offered by our parent company’s recruitment outsourcing division, we moved Newton to the Adobe Flex platform – making Newton the first rich internet application for recruiting. This move accelerated development cycles and improved performance and usability. By the end of the year, Newton was deployed to users at some of the largest technology companies in the world, like Dell and Microsoft, often supplementing legacy applicant tracking systems.
Formal inquiries to buy Newton as a standalone product started to increase in by early 2008. Many companies began to feel the pinch of the retracting economy and were seeking ways to bring recruiting in-house. As the year wore on, more and more companies were asking to use Newton to run their recruiting programs. With the writing on the wall, Newton’s parent company, prepared to launch Newton Software, despite the already crowded applicant tracking marketplace, creating a separate company to manage the day-today business operations and to take the product to new markets.
Newton Software was officially launched on January 5th 2009. As the first product offered by this newly formed, autonomous company, Newton, our first product, had the advantage of having been tested, and refined in real-world recruiting situations since late 2004. Unlike most start-ups, we had a mature product to start with, something customers could buy, and a product that was proven. We will be the first to admit that starting a company that offers hiring software during a recession was at first daunting. But, Newton was greeted kindly by industry analysts and customers alike because of its innovative, process driven, easy-to-use approach to an old problem. And we have been steadily growing our customer base since our inception.
This is nowhere close to the end.
Check out our background page to see more screenshots of the evolution of Newton.
I really like this next axiom in our Design Philosophy for a couple of reasons: as a user it’s really a quite common annoyance in software of all kinds, across all industries; and, we have first-hand experience learning this lesson the hard way.
While this tenet has been in our style guide for quite some time, it was only recently promoted to “Philosophy” status. I promoted it when we almost broke this rule a second time. While I was talking with one of the other Product Managers, we both had one of those “oh duh” moments when we realized we were about to screw up on something big and repeat a past mistake.
So, here we go. In summary, this part of our Design Philosophy recommends that you take great care in naming page elements. Exciting stuff. Cheers.
Be really (really) careful how you name things. And, NEVER use the same word to describe two different things.
Sloppy naming can lead to minor frustrations, or it can lead to some really big problems for your users. The road to sloppy naming is paved by the careless use of synonyms or by naming two different things with the same word or phrase.
First of all, let’s look at synonyms (the more obvious of the two naming blunders). When considering a naming framework for your software, it’s important to remember that your name choices actually constitute a set of instructions to the user whether you, or they, actively realize it or not. Put a different way, what you name something is an implied instruction.
Synonyms are especially painful in Navigation. For example, don’t name one of your navigation elements “Reports” and the other “Metrics”. While it is entirely possible that they serve completely different functions in your software, their names mean pretty much the same thing to a lot of people. As a result you’re going to confuse the heck out of your users.
Since this is so important yet easy to avoid, I’d like to illustrate this point with a few real-world examples from two existing software applications. There’s a certain (very popular) sales software application that has one tab for “Leads” and another for “Opportunities”. What’s the difference between a lead and an opportunity to a salesperson? If I call you up and say I want to demo Newton, which tab would you click in your sales application? Another more baffling example I saw the other day was in a competing recruiting software application: it has a tab for Jobs, and another for Requisitions. What’s the difference between a Job and a Requisition? Should you have to ask?
Having used this very popular sales application for quite some time, we were keen to avoid the synonym booby-trap. But we’ve fallen victim to the siren song of its sister: inadvertently naming two different things with the same word or phrase. Be careful, because you can easily do this on accident, and it will completely screw things up for you.
We learned this particular lesson the hard way. A while back we had a User Type, “Hiring Manager”. Jobs also had Hiring Managers too. A Hiring Manager User and a Hiring Manager assigned to a job had nothing in common (confused yet?). This seemingly minor oversight meant that I had to explain user rights over and over again: “if you are a Hiring Manager user then you can be a Hiring Manager on a job, but not all Hiring Manager Users will be Hiring Managers on jobs” (I should add that one of our Design Principles also states that if you need to explain something it’s probably poorly designed). Once I smartened-up and removed the dual-naming from Newton the problem solved itself immediately, no training required.
While we’ll probably all agree that synonyms help make our language more colorful and interesting, and that word-efficiency can shorten/simplify content at times, nothing is more important to a user than clarity.
This next installment in our Design Philosophy is going to sound a little counter-intuitive. At Newton, we think that the people who use our software the most aren’t necessarily the people that are critical to its success. Our “Critical User” is the person that uses Newton intermittently, every now and then, once a day, once a week, or maybe even less.
Up to this point, companies have designed business software almost entirely for what we might call a “Power User”, i.e. people that are going to use it day in and day out. If you have ever trained a new hire on one of your company’s programs, you may have noticed this before. Your new co-worker is impressed, perhaps even amazed, at your vast software knowledge because you are able to navigate complexity with relative ease.
For a business process like recruiting where 90% of the users don’t hire all of the time and therefore don’t use recruiting software day in and day out, this design focus leads to 10% user adoption. Casual users don’t have the time or usage frequencies that foster retention of complex features.
This is why at Newton we put a great deal of emphasis on casual users. In fact, we build our application in direct contradiction to the software design zeitgeist: our software design starts with casual users, and then trickles up to power users.
Our goal has always been that when a client deploys Newton to their team the person buying the software is proud of their decision because everyone likes it. We want their co-workers to say, “Wow, this is really simple and easy. Thanks for making my day better.” We think this happens with Newton because we care a great deal about all of the people using the software, not just the power users.
And this leads us to the next installment of our Design Philosophy…enjoy.
Ignore power users when designing features.
I.E. Keep it simple.
Keep in mind that software applications aren’t bicycles. You don’t learn them once and remember them forever.
One axis of the learning curve is time. The majority of the people using Newton to hire have other job responsibilities and don’t have time to learn our software, and they’ll forget a lot of what they’ve learned between logins. They are going to get an opening, use Newton for a few weeks, fill the job and then not use Newton until they are hiring again. Here’s what the learning curve might look like for our users:
A crude rendition of how we remember things.
So be very careful when you design a feature or a page. If someone other than a power user is going to need to use it, it better be really simple. Simply put, features for non-power users must almost always be one click and done. Every page should have an obvious intention. If something requires training or explanation people will become frustrated and won’t use it. As below:
Avoid the "Ugh" zone.
How to Test Your Designs Always test your design by mocking it up, and then afterward ask someone that knows absolutely nothing about Newton to take a look at it. Your only question should be, “What do you need to do here?” If the answer is predicated by “Hmmm…,” you should probably go back to the drawing board. If your page or your feature can stand by itself without explanation, you’ve done a good job and have avoided the Ugh zone.
In summary,
If you need to explain how something works, it probably won’t.
This was one of the first Design Philosophies at Newton. Once we got our Home page to where we liked it, to where it was “training-lite”, we made a rule that we couldn’t add anything more to it. The rule was, “Before you can add a button you’ve got to remove one.” This rule has caused great consternation over the years, and for the Home page it has been broken once, and might get broken one more time.
The impetus for the rule evolved from the years we were designing and using other recruiting software systems. Eventually these systems were “improved” into perplexity: at some point so many features were added that the only people who could log in without getting freaked out were people that had used the software for years. Over time, I watched systems like this devolve into rather expensive places to store resumes, and witnessed eye-rolling during training seminars. Call me crazy, but I didn’t feel like walking down that well-worn road anymore.
So here goes, straight from the style guide, another dictum in our Design Philosphy….enjoy.
Before Adding a Feature or Button, try to Remove One.
Understand that the more options you give someone the longer it takes them to make a decision, and the longer it takes for them to learn our software. Instead of adding a new feature, try to see if first you can use it to remove an existing one.
As a designer, you look at the same screens every single day, so you automatically know where everything is and what everything does. Watch a new user login, if they move their mouse around frantically, it means you’ve probably reached overload. Realize this: every button, tab, link, menu, drop-down etc is a de facto question asking the user, “Do you want to interact with me?” And the user must ponder “yes, no, maybe,” for each element.
It seems almost counter-intuitive: fewer choices = faster. Perhaps this is why many software applications have gazillions of things you can do on every page. Problematically, systems like this take a lot of training, and each new feature serves to make New Users more frustrated. If you don’t believe me, try using Photoshop for the first time, without a manual.
Additionally, be watchful of putting power-user features in a prominent location on common pages. Prominency is great for Power Users (who would find them anyway), but New Users won’t know how to use them, so you’ll just flatten this person’s learning curve (or just erase the learning curve altogether).
As a bonus, keeping this rule in mind means that you’ll have more time to perfect existing features, and Development gets to spend more time making our product even more reliable.
There are few things more rewarding than when no one notices you removed a 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.
Our daily lives on the web have become more complex. People are looking for ways to incorporate simplicity into their jobs. But finding simplicity in the workplace is becoming increasingly harder every day. To make matters worse, many people still shy away from simple because they associate simple with a lack of power. Most software vendors still play to this fear. Their guiding principal is “features are power, add as many as possible”. This is especially true amongst applicant tracking software vendors.
“Please contact support.” Makes you cringe, doesn’t it? At Newton we encourage people to contact support—by email or phone. No, I’m not kidding.
