Dispelling the myth of "faster horses"
"If I had asked people what they wanted, they would have said faster horses." | ||
| --Henry Ford | ||
If you've been in the corporate world or in technology for any length of time, you have probably heard this quote. It implies, albeit subtly, that engaging users in order to find out what they need or want is not important because, hey, what do they know? Seeing this quote and hearing it used for so long, it always seemed odd that Ford would say such a thing. It was also compelling to find out whether he actually did. Not surprisingly, when you do a little digging, you find rather quickly that something is amiss.
The "faster horses" quote is actually relatively new, first appearing around the year 2001 in a letter sent to the UK publication Marketing Week. Additional research by the Henry Ford Museum found that this quote never appeared in any of Ford's own letters and writings. The museum also claimed that while "Mr. Ford wrote numerous articles for a variety of periodicals and newspapers, the quotes attributed to him were varied and often unsubstantiated."—https://www.quora.com/. Hmmm…so if Ford never said it, why does it persist and why is it attributed to a man who was highly innovative, creative, and effective in the solutions he delivered on a global scale?
This quote originated in a marketing publication. The differences between marketing and UX have always been quite diverse. Marketing tends to view customers from an inside-out perspective evidenced by its strong focus on new customer acquisition and customer retention. UX views its customers from the outside in, working closely with them to understand the problems they face and helping to solve them.
Viewed with a marketing mindset, "faster horses" implies that a designer or an inventor, in the case of Henry Ford, knew better than his customers. Looking from the inside-out, "faster horses" implies that we can make assumptions about our customers/users based on data, usage patterns and thinking that if we did ask customers they would not really know what was best for them. The "faster horses" quote also implies that designers can impact a customer's experience based solely on intuition, instincts, experience and business smarts instead of in-depth research and engagement. The "faster horses" quote does one more thing as well: it makes the role of a UX practitioner much harder.
For starters, "faster horses" thinking diminishes the understanding of what UX does and how its solutions rely on understanding customers and end users. It also undercuts the ability of UX practitioners to engage in customer/user facing projects because those with the "faster horses" mindset can just do it themselves and then just pass along their work to the UX folks to test it for any last minute usability and interaction issues. Is it the best solution? Maybe or maybe not, but so long as end users can do the tasks then that is good enough.
"Faster horses" thinking also discounts the level of research and trial and error required to deliver real solutions, not just for customers but for business success as well. As we will see in later chapter, there is much more to problem solving than assuming we know what customers want. "Faster horses" thinking also implies that great design can be done in a vacuum, where anyone with enough experience can design and deliver a customer-/user-based solution without having to engage users face to face. "Faster horses" thinking also allows designers to avoid the discomfort sometimes associated with creativity; something we will look at in the next chapter. The reality is that ignoring our customers/users and thinking we know best can cause many problems, like project failures, over spending, underperforming and lowering user efficiency, effectiveness and satisfaction. These can have huge implications and unless the mindset of "faster horses" is changed these problems will continue to grow. While going it alone may paint a romantic image of a lone inventor or experienced team delivering what the world needs and making history doing it, realistically it is impossible to do without deep research, customer/user engagement and empathy for the user and stakeholders as well whose goal it is improve business outcomes in a consistently provable and measurable way. The only true approach, therefore, is one that utilizes a truly authentic UX mindset.
The disservice of "faster horses"
Romanticizing lone wolves: people who seemingly go it alone and solve major problems without the help of others, provides us with great stories and legends, but it also does a disservice to the hard work, skill, collaboration, trial and error, problem-solving skills, and the mindset necessary to make it all happen.
There is actually a lot of evidence to support this. It is most readily seen with the amount of projects that fail every year due to teams inadequately addressing customer/user needs. For example, in a video presentation by Dr. Susan Weinschenk of Human Factors International, titled The ROI of User Experience, Dr. Weinschenk stated that the amount of money spent worldwide on projects related to Information Technology (IT) is estimated at $1 trillion per year. The number of projects abandoned because they are hopelessly inadequate is 15 percent. Refer to http://www.humanfactors.com/project/index.asp for more information on human factors and its importance in project success.
This means $150 billion is wasted each year because teams are not utilizing the right mindset when it matters most, that is, before projects go into development; before requirements are defined; after adequate communication with customers, end users, developers and stakeholders has occurred; and that everyone is in agreement. Dr. Weinschenk also pointed out the problem of office politics, where teams often branch off into silos of ownership. Then, when projects fail to deliver blame is placed elsewhere, further dividing teams that should be working together towards a single, company/business focused goal. Dr. Weinschenk further pointed out that in order to solve this problem, teams need to get out in front of these issues using techniques such as business and user research and data and analytics to determine business and customer related metrics, interviewing subject matter experts (SMEs) , customers and users, usability testing, root-cause analysis, prototyping and wireframing. All these techniques play a major role in establishing a UX mindset because we are no longer thinking as separate teams. We are now thinking as a unit with the right focus on effective outcomes and measurable results.
When facts ruin a good story
Let's pretend for a moment that Henry Ford actually did utter those words about "faster horses." How would this story hold up when we look at the reality of the situation? Were people in 1908 really looking for faster horses? Were they truly oblivious to the real problems that horse-powered transportation created by the turn of the century? Also, if people were really interested in faster horses, where were they going in such a hurry? Doing some research on the subject, one quickly discovers that the truth is often much more interesting and also much different than what we are led to believe.
By 1908, there were hundreds of thousand of horses crowding city streets around the world, and this was not a new problem. In fact, the problems with horses were well-known. For example, by 1894:
"London…had 11,000 cabs, all horse-powered…several thousand buses, each of which required 12 horses per day, a total of more than 50,000 horses. In addition, there were countless carts, drays, and wains, all working constantly to deliver the goods needed by the rapidly growing population of what was then the largest city in the world. Similar figures could be produced for any great city of the time." | ||
| --Stephen Davies, The Great Horse-Manure Crisis of 1894 | ||
One can only imagine the impact this had on crowded streets, not to mention the smell. Getting around must have been quite difficult. Getting anywhere faster in the conditions would be better served with flying horses rather than faster ones. In addition, the majority of the population in 1908 were living in cities, most within walking distance of their jobs. Trains and subways existed too too, as did automobiles. Automobiles were only more of a luxury item that the working class could not afford.
In light of all of this evidence, there is no mention of faster horses, not does it sound like anyone would have been asking for one. Now, if this isn't enough evidence, horses in 1908 were also quite dangerous. In fact, by 1916, there were 16.9 horse-related fatalities per 10,000 horse-drawn vehicles, a number said to be seven times that of Chicago's automobile fatality rate in 1997!
"The skittishness of horses added a dangerous level of unpredictability to nineteenth-century transportation. This was particularly true in a bustling urban environment, full of surprises that could shock and spook the animals. Horses often stampeded, but a more common danger came from horses kicking, biting, or trampling bystanders. Children were particularly at risk." | ||
| --Eric Morris, From Horse Power to Horsepower | ||
Don't forget the mortality rate of horses (Warning: This is not for the squeamish).
City dwelling horses often fell on average of once every hundred miles of travel. If the horse (weighing an average of 1,300 pounds), was badly injured it would be shot on the spot and left to die, creating a ghastly obstruction that clogged streets and brought traffic to a halt. Special horse-removal services did exist at the time, but moving such a large carcass was not easy. As a result, street cleaners often waited for the corpses to putrefy so the dead horse could be sawed into pieces and carted off.
Problem solved? Well, there was also the problem of the smell, the flies, the horribleness of dead horses on the street and of course the risk of disease—Eric Morris, From Horse Power to Horsepower.
Source: http://i.imgur.com/U6ZC3ki.jpg
Now, with these conditions in mind, place yourself in 1908 as an inventor/businessman like Henry Ford. As you are researching on these problems and seeing them firsthand, would you be so callous and indifferent to these problems? Does it make sense in light of this history that Henry Ford would have ignored what people were experiencing, himself included, and think they were ignorant enough to simply want faster horses? Of course, not. These problems were impossible to ignore.
In fact, 10 years before Ford's Model-T arrived on the scene, the first ever city-planning meeting convened in New York City to address the problems facing large cities. One major concern was also related to horses, namely the overwhelming amount of horse manure infesting city streets. One reporter wrote in the Times of London that 50 years hence, every street in London would be buried under nine feet of manure.—The Great Horse-Manure Crisis of 1894, Stephen Davies.
Faster horses? Hardly. To solve these major problems would require far more than just guesswork and assumptions. It would require research, ethnography, concept design, trial and error, testing, and so on.
So, what did Ford do in light of these problems? Did he invent the world's largest pooper-scooper, a more efficient way to kill the millions of flies born out of the tons of manure and dead horses? Did he strap rockets on the backs of horses to get them airborne or give everyone oxygen masks to simply deal with the problem? Of course not. He did something much smarter. No, he didn't invent the automobile. That was done a decade earlier by Gottlieb Daimler and Karl Benz, inventors of the high-speed gasoline engine in the 1880s—The Origins, mercedes-benz.com.au
Instead, Ford saw the problems that horses created, the conditions people were living in and the salaries people were making—on average, the living wage in 1908 was 22 cents per hour with the average worker bringing home between $200 and $400 per year—and delivered a solution that solved all of these problems at once. His solution was to invent the world's first assembly line where his inexpensive Model-T automobile could be made cheaply, quickly, and in large numbers. By 1914, just six years after introducing the Model-T, it sold more than all other automakers combined.—Ford Model T, Wikipedia, the free encyclopedia. Quite an accomplishment for someone who supposedly ignored his customers and thought all they really wanted were faster horses.
Regardless of the facts, the "faster horses" myth still persists. It is troubling to consider, but it could very well be a convenient way to rationalize avoiding customer engagement due to the time and money required to do it effectively. It may also be a response to a culture where siloed teams can continue to place blame when things go wrong.
"When problems arise…"the enemy" becomes the players at the other positions, or even the customers…precluding any opportunity to learn from each others' experience." | ||
| --Peter Senge, The Fifth Discipline. | ||
Collaboration is a joke, but nobody is laughing
Consider the following illustration. You may be familiar with it. It's popular with project designers and developers and often found on cubicle walls as an amusing depiction of how technology teams interpret the needs of their customers/users:
The preceding image is amusing because if you work in the world of technology and solution delivery it is something you experience on a regular basis. It is also a stark reminder of what happens when we allow a "faster horses" approach to problem solving. Instead of working through the problems as a collaborative team where diverse skills such as UX should be included, teams are singularly focused, work in silos, develop solutions based on their specific understanding of the problem and are often guided to those conclusions by inadequate business/customer/user requirements that lack the input of a unified, cross-disciplined, cross-collaborative team. In addition, any customer/user solution hypothesis goes untested while business/customer/user related research, if any is done at all, scratches the surface or is so disjointed and disconnected that nothing can get accomplished to truly serve the end user's needs. As we can see in the preceding illustration, when projects fail as a result, it is far easier to place blame elsewhere while continuing to overlook the real problems at hand.
In light of the preceding illustration, some questions come to mind, ones you might want to try and answer. Here are some of them:
- Are teams spending too little time researching and engaging with their customers and users, and instead, rushing to solutions?
- Are teams truly considering the implications of their design decisions or simply subscribing to a just get it done mentality, which distracts from diagnosing the real problems?
- What does "speed" to market really mean? Does it mean surpassing the competition in terms of delivering innovation to customers/users or does it mean delivering products quick enough to be able to say, "Look how fast we can deliver something?"
The answers may be that it is far easier, less uncomfortable and less expensive to stay in silos rather than engage with other skill sets such as UX, that they may not clearly understand. In addition, going it alone has a romantic element to it that allows for successful teams to take all the credit and unsuccessful ones to place blame. As UX practitioners, it may be up to us to solve this problem once and for all and demonstrate through example how the UX mindset brings people together to solve real problems in a measurable way and to learn from our failures in order to improve, not for our own benefit, but for the benefit of those who truly need our help.
Understanding the problem
"The problem is we don't understand the problem" | ||
| --Paul MacCready | ||
In 1977, Paul MacCready, an American aeronautical engineer, won the Kremer prize, "a monetary award…given to pioneers of human-powered flight." MacCready succeeded where for 20 years design teams were unable to. The challenge was how to design an aircraft that could be powered by human muscle and ingenuity alone, and stay aloft long enough to complete "a figure-eight course covering a total of one mile." Year after year design teams built wonderfully crafted, self-powered machines, but all failed to fly the distance, often crashing and needing a year or more to repair the damage and try again.
Think about this problem for a moment and consider how you might go about solving it. Would you change the design by looking for the faults in the flying mechanisms? Would you find a stronger pilot who could pedal longer or faster? Would you spend more time practicing flying a similar course before attempting to win the prize? Or would you try something entirely different?
MacCready thought about this too, but rather than assume he knew the answer, he spent time observing and researching until the answer became clear. Rather than building a plane that could stay in the air longer, fly further or faster, MacCready realized that all of the other aircrafts attempting to win the prize failed, not because of their design, but because of the time it took to rebuild their aircraft after crashing. As a result MacCready and his team designed an aircraft that could still crash, but if it did it could be rebuilt in a matter of days instead of months or years. In other words, MacCready's design allowed him to fail, learn and try again more often than his competition.
"The first airplane didn't work. It was too flimsy. But, because the problem [MacCready] set out to solve was creating a plane he could fix in hours, he was able to quickly iterate…rebuild, retest [and] relearn…from months and years to hours and days." | ||
| --Aza Raskin, You Are Solving The Wrong Problem | ||
Here is an image of MacCready's prize winning aircraft, the Gossamer Albatross:
You can read more about MacCready 's Gossamer Albatross at https://en.wikipedia.org/wiki/MacCready_Gossamer_Albatross.
MacCready's approach to research, observation, learning through failure, iterating, and trying again before putting it in front of the judges, which in our case is our customers and users, is what the UX mindset is all about and is our ultimate goal as UX designers and practitioners. Think of MacCready's approach to problem solving the next time you approach a problem. Here is the recipe:
- Deep, customer-/user-engaged research
- Close observation of your end users
- Identify root causes
- Develop a hypothesis based on your research
- Test your hypothesis through prototyping and wireframes
- Fail and try again
- Improve on your failures
- Test again
- Fail again (perhaps)
- Improve, test, fail, and continuing to repeat these steps
- Execute, compete, and win
There are, of course, many details that make up each of these bullets points and we will continue to establish them through the rest of this book, but hopefully, you get the idea. This is a recipe that prioritizes research, problem solving, root-cause analysis, testing, and iterating between ideas and execution while emphasizing failure as essential in order to learn and make it better before presenting it to the judges. It is also a recipe for bringing project teams together to solve problems. Keep in mind, however, that this is not easy to accomplish. The challenge, as you will discover, involves convincing teams to drop "faster horses" thinking and approach problems differently. This is not an easy thing to do, however, when this way of thinking is so engrained in our culture.
Customers/users are dumb!
There's a classic episode of the Simpsons where Homer's long-lost brother asked him to design a new car for the everyday person. Although the design engineers attempted to ignore Homer, his brother forced the issue and the results were utterly predictable:
By dropping the company's "faster horse" mentality, Homer's new car was designed with customer/user feedback. The design of course is completely absurd and so predictable, coming from someone as empty headed as Homer. The cartoon also drives home another more subtle point: the customer isn't very bright. In the end, Homer's design failed, followed by the automaker going out of business while his long-lost brother was once again estranged from his brother, this time, we can assume, for good.
Somehow have have convinced ourselves that asking people what they want is a recipe for disaster and that listening to customers will create more disasters like Homer's car and less like what people really need. Therefore, the message is to leave designing to the professionals and not in the hands of people who will actually be using it.
"Customers should not be trusted to come up with solutions; they aren't expert or informed enough for that part of the innovation process. That's what your R&D team is for…What form the solutions take should be up to you, and you alone." | ||
| --Anthony W. Ulwick, Turn Customer Input into Innovation | ||
Shut up and listen!
To be absolutely clear, as trained UX designers it is ultimately up to us to fill in the holes and interpret what we are hearing and seeing into educated guesses or hypothesis to be tested by our customers and users to see whether we are correct and that we heard them correctly. Listening to our customers and end users is not detrimental to our success, rather it is integral to it, provided we know how to listen and how to interpret what we are hearing and seeing and turning that into viable design solutions. This takes time, effort, and skill. To go the other route and think that we have to either follow what our customers say and fail or ignore them and succeed is risking failure on a large scale. For example, in an article from the Harvard Business Review by Anthony W. Ulwick, titled Turn Customer Input into Innovation, the author shared an example of how one company, Kawasaki, learned a valuable lesson in not only listening to customers, but more importantly, paying attention and deciphering what is really needed as a result.
"When [Kawasaki] asked users what could be done to improve [their] Jet Ski's ride, customers requested extra padding on the vehicle's sides to make the standing position more comfortable. It never occurred to them to request a seated watercraft. The company focused on giving customers what they asked for, while other manufacturers began to develop seated models that since have bumped Kawasaki—famed for its motorcycles, which are never ridden standing—from its leading market position."
It seems hard to believe that experienced designers would take comments like these so literally, yet the business and product world is full of similar stories. Engaging with our customers and users is a balance. It is not either…or. It is a relationship and an understanding that requires deep engagement informed by experience, design expertise and a little psychology thrown in as well. It requires a UX mindset in order to see what others cannot and to really understand what our customers and users are telling us. It is then up to us to interpret, test and see whether we were correct. If not, try again quickly until it's right. When we fail to interpret customer/user needs correctly, however, it is easier to place blame on the customer and the end user than to acknowledge that it was our design that failed because we didn't really listen. There is even an acronym for this phenomenon: "PICNIC" or problem in chair, not in computer.—http://www.userfocus.co.uk/articles/picnic.html. Here is a quote that drives this point home quite nicely:
"If there is any one secret of success, it lies in the ability to get the other person's point of view and see things from that person's angle as well as from your own." | ||
| --Henry Ford | ||
This is a quote that Henry Ford actually said, verifiably so!—How to Win Friends & Influence People, Dale Carnegie.
