Most of us think the Wright Brothers invented powered flight. But that’s not entirely accurate. There were many experiments in the development of heavier-than-air flying machines, but they all faced one crucial limitation: they couldn’t turn in the air! No one had figured out how to get the aircraft to make a turn, so “flights” in those days were definitely one-way tickets.
New Paradigm
What the Wright Brothers did was see things from a different perspective. Until they came along, the standard paradigm for an airplane was the wagon: four wheels, very stable, and roomy enough to carry the mail and a few passengers. When turning a wagon, the wagon’s body stayed level. And the problem was, no one knew how to get a flying machine to turn and still stay level. But Wilber and Orville weren’t wagon makers. They were bicycle makers. And in their experiments with flight, they used the bicycle paradigm – where making a turn depended on leaning into it, not steering into it. So, by working on changing the wing design – introducing flaps that caused the wing to bank in the air, they came up with a way to get their machine to turn around and complete a round trip flight.
Simply by looking at the problem from another perspective, they succeeded.
Rear view of Wilbur making a right turn in glide from No. 2 Hill, right wing tipped close to the ground. Attributed to Wilbur Wright (1867–1912) and/or Orville Wright (1871–1948). Most likely taken by Orville Wright.
Are we missing something?
Now, this might seem to have nothing whatever to do with the contemporary Human Capital function, or the various recruitment, pay, performance, rewards, benefits, training and development, and engagement programs these departments manage for employees. Yet when many of these programs face problems in participation, in execution, and in results, you’ve got to ask yourself, are we missing something?
Let’s say you’ve decided to introduce a new performance management system—one designed to make the process more efficient, and to address complaints of managers and employees alike who find the current system difficult to navigate and time consuming to enter individual goals and corresponding metrics. So, you develop a new system—one that has easy-to-use “pick lists” to input pre-defined goals and which then automatically populates the corresponding metrics. You conduct extensive user testing to ensure that both employees and managers can quickly and easily complete the goal setting process. The user testing validates your design and after piloting it, you roll it out across the organization.
Great! Problem solved. Except…it’s not. Or, more precisely, you’ve solved one problem and created another. The new system is so automated that employees input their goals and managers accept the goals, without any dialogue between them.
Or, consider this scenario: You’ve introduced a new integrated health care and wellness program—one that requires that participants actively engage in their health throughout the year. In order to maximize their benefits, and minimize their costs, employees must not only complete a health assessment and their biometric screenings, they need to complete activities designed to help them be better consumers of health care and take steps to improve their health (or maintain their healthy status). In order to support this program you seek out new vendor partners, changing everything from the medical plan provider to the administrative systems to the benefits portal.
Data feeds between the systems are established, enrollment systems tested, and the program is launched. Everything works perfectly. So why is the benefits service center being bombarded with calls and emails starting the first week of the new Plan Year? And why are executives beating a path to your door asking why they are hearing so many complaints about the new program… the program you said would be a huge “win” for both employees and the company?
Applying a User Experience Lens to the Programs
Under both of our scenarios—the easy as 1, 2, 3 performance management system and the awesome new benefits program—the end “users” aren’t happy and, soon, engagement levels across the organization plummet.
So what happened?
Like the early aviation pioneers before the Wright Brothers, HR adopted the old command-and-control paradigm as a way to help the program succeed in reducing costs and increasing productivity. (If you’ll forgive the pun, they ‘circled the wagons’.)
If, instead, HR had thought about how the program would actually be used not just “navigated” – had seen it through the lens of the ultimate user, rather than their own lens of “ensuring success” – things would have been different, and very likely far more successful.
[ctt title=”When creating an HR program make sure you can see it through the lens of the end user.” tweet=”When creating an #HR program, make sure you approach it through the lens of the end user http://ctt.ec/G8Fcl+ by @XeroxHRInsights ” coverup=”G8Fcl”]In the case of our new performance management system, employees and managers alike needed to be informed that the system was simply a means to an end—not the end itself. That the various goals should be reviewed, and the ones most meaningful to each individual and her role in the organization, mutually discussed. The associated metrics should be reviewed jointly, too, and if modifications are needed to address the specific circumstances—modifications which the system was designed to support!—these should also be mutually discussed and agreed-upon.
As for the new medical and wellness program? There are all sorts of factors that may have gone wrong. While a thorough provider disruption analysis was done, along with an impact analysis of switching to a new drug formulary, no detailed examination of extreme outliers was conducted. As a result, some employees—admittedly no more than a handful—faced prescription drug costs in the hundreds, in a few cases, thousands of dollars, when they went to pick up their prescription. While the new drug formulary was included in the enrollment materials, there was little communications to individuals most likely to be impacted—the vendor-provided materials were hard to read and lead with the usual “you can save money by switching to generics” that employees were so used to seeing year after year.
In both these cases, just as with the Wright brothers, stepping outside the usual ways of introducing change—considering them through a true “user experience” lens, not just conducting user testing—would have identified how employees would actually interact with the new system and program. Necessary modifications to either what’s been developed or how it will be communicated, would have locked in the hoped-for “wins”.