Also available on my blog at ColoradoDesignLabs.com
Companies need smart people — subject matter and technical experts — to design and build things. Smart people are required to solve the hundreds of technical challenges required to bring a product to market. Smart people who are experts in their fields are consulted to design a company’s internal IT applications and business processes.
There’s only one problem with smart people: they tend to design things for people like themselves — for other smart people. But people are not all smart about the same things, nor do they want to be, nor should they be. An expert accountant might design a company’s time and expense reporting system in a way that makes perfect sense to another expert accountant, but most of the people using the system are not expert accountants and find the myriad accounting codes unnecessarily complex. An expert technologist might design a cell phone that has all the latest features and functionality, but the Nobel-Prize-winning chemist who buys the phone has no desire to be an expert in cell phone technology — she just wants to make a phone call. A seasoned human resources manager might design an employee performance management process that makes perfect sense to other human resources experts, but to the managers who have to use the system it is unnecessarily tedious, time-consuming, and complex.
This is the Smart People Paradox: companies need smart people to be successful, yet these smart people often insist on adding complexity to products and operations that can render the company less successful. Because the complexity is routine and second nature to them, these Smart People don’t even see it, or if they do, they insist that everyone needs to understand it.
I once worked with a team of engineers on a new oscilloscope project. The underlying complexity of the technology was surfacing in the proposed user interface design. When I tried to call attention to this, the engineers insisted that users needed to understand the underlying technical architecture of the product and become familiar with terminology that they assumed was commonplace in the industry. “Sure it’s kind of complex,” they would argue, “but our customers are smart people. They’re scientists and engineers. They love this kind of stuff, and after all, it’s not rocket science.”
This was a compelling argument in our engineering-dominated culture until we got the opportunity to visit Los Alamos National Laboratory, one of our major customers. Here our users — rocket scientists all — told us that they had less time to learn how to use their scientific instruments than in the past, and that they needed to be significantly easier to use.
Apparently even rocket scientists don’t want to be experts in oscilloscope technology.