« Critical Incentive Pay Lesson from a Jeopardy Champion | Main | When Virtual Reality Meets Plan Design »



Feed You can follow this conversation by subscribing to the comment feed for this post.

Thank you, Jacque!

There has been quite a bit of discussion in recent years centered around the differences between things which are complicated and those which are complex. A new Toyota automobile is complicated; managing employees is complex. (The distinction is not just one of semantics, but also of tools, methodologies, etc. for addressing them.)

But, to the matter at hand, there are several ways to approach simplicity - and not all of them are effective. In the new Toyota automobile, the designers did not choose to simplify the car, per se, they simplified the manner in which the user interacts with the car (User Experience, UX). Through the design of the dashboard, operator alerts, safety sensors, and more, the designers took an incredibly complicated machine and made it seemingly simple for the user. The car itself collects, monitors, and records thousands of datapoints and probably conducts hundreds of thousands of computations almost all of which will be utterly transparent to the user.

All too often, when people approach the idea of simplicity they approach simplicity as an end unto itself.

In many cases, people attempt to simplify by changing the car itself, not the UX. They remove the blind-spot monitoring, they remove the cruise control, they remove the electronically-controlled transmission, and on and on. In their quest for simplicity, they turn the automobile into a donkey-pulled hay wagon. It's simpler, but its no longer an automobile.

So, to my mind, the trick is to have clear focus on what you're trying to simplify and why you're trying to simplify it. If the goal is to create a better UX, than counter-intuitively, I would argue that you often have to make things more complicated (on the backend) to create a more pleasant experience for the user (on the front end). [And isn't that sort of the whole value proposition of ServiceNow?]

As an example of creating simplicity by making something more complicated, consider a humble HR procedure. A simple version of an HR procedure can be written by any competent HR specialist. But no one other than HR may understand a word of the policy or how to effectively apply it. In that case, will anyone use that procedure? On the other hand, when you buy a new appliance, you get an Installer's Guide, a User's Manual, and a Quick Start Guide; you never see the Technician's Guide, but it will exist. What if you wanted to write HR procedures like that? You would write a version for HR (Installer's Guide), a version for managers (User's Manual), jobaids (Quick-Start), etc. And, like with your appliance manuals, you'd want to include pictures, example operations, and maintenance and troubleshooting tips. Would such an expanded set of guides be simpler than the single document written in HR-ese? HR might say. "No way; such a procedural portfolio is much more complicated!" But, for the user, the answer would likely be a resounding "Yes!"

But, that's my take. What's yours?

Great explanation Joe. Thanks!

The comments to this entry are closed.