What’s More Important: Clarity or Efficiency?
Over the past year and half, as a Product Designer at HubSpot, I’ve noticed a very common source of friction between designers and engineers. Previously, I’ve owned my own company where I worked as a design consultant for close to a decade. Even though I’ve worked with many other designers and engineers throughout the years, I’ve never been in a position where I’ve interacted so closely with a team large enough and over a long enough period of time to see such interesting dynamics play out.
It seems as though designers value clarity over efficiency and engineers value efficiency over clarity.
When left to their own devices, designers tend to add more screens, more design elements, and more words in an effort to make things easier to understand, while engineers tend to combine and consolidate these elements to gain the advantage of speed. Even though these dual goals might seem to be in opposition, it’s a good tension and striking just the right balance makes the software much more satisfying to use.
Designers love clarity (maybe too much)
To a designer, “clarity” seems to be code for “it doesn’t take a lot of heavy mental lifting for the customer to understand how this thing works.” It’s a noble goal, and one that’s totally worth pursuing. Making a customer’s life less complicated will make them happier, more satisfied, and more productive.
From a resource perspective, the less need the software has to explain itself, the less support, training, and documentation it will need. This will help the business scale, serve more customers, and incur less overhead and expense. Clarity is a hugely valuable asset and is all too often underestimated.
Unfortunately, in many cases the drive for clarity can come at the cost of creating more work for the customer. Slowing people down with “procedure” is a great way to turn an effective tool into a nuisance. Also, making people feel as though their hands are being held as they work through your software can come across as patronizing and rude.
Engineers love efficiency (maybe too much)
To an engineer, efficiency is the ultimate goal that’s intended to help customers do two things in the time it typically takes them to do one. When you give people more time, you give them more opportunity to do more things that matter in their lives or in their business. More opportunity equals a greater chance of success. Efficiency rocks.
I think the logic of efficiency is a little easier for people to grasp. When you can help someone do something faster, it’s easy to connect the product to value in their lives. This perception of value is what makes something worth buying. The more efficiency you can offer, the more money you’ll make.
Unfortunately, an unintended consequence of efficiency is that when you combine complex tasks or rely on customer’s domain knowledge, you’re shifting the responsibility of knowledge from the software (scalable) to the customer (not scalable). This introduces all sorts of expectations around training and support, which then puts a burden onto other areas of the company. It can also frustrate the customer when they can’t extract the value out of a system without admitting, even if only to themselves, they don’t really know how it works.
Imbalance gets noticed
When your customer is dealing with a complex problem, a complex solution isn’t going to be a surprise. It’s when they’re on the tenth step of something that shouldn’t require ten steps or looking at one epic interface that takes several minutes to decipher. This imbalance gets noticed and will be interpreted as unnecessary work caused by a clumsy product.
So when your customer feels like she’s jumping through hoops to the point where it becomes repetitive and boring, you’ve introduced too much procedure to compensate for clarity.
And when your customer feels like she’s unsure of what she’s doing or is intimidated, you’ve probably consolidated too many tasks into the same flow to compensate for efficiency.
Learn to love the tension
The right mix of clarity and efficiency is where the magic happens, and that can’t be done without paying attention to your customers and a little bit of healthy tension. So designers and engineers each have something to learn from each other. This isn’t a zero sum game, and both camps can learn something valuable from each other.