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.

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:

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!

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

Source: http://gottliebdaimler.blogspot.com/

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.

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:

Source: http://www.businessballs.com/images/treeswing/tree-swing-s-hogh.jpg

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:

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.

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.

Here is an image of MacCready's prize winning aircraft, the Gossamer Albatross:

Source: https://en.wikipedia.org/wiki/MacCready_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:

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.

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:

Source: http://www.geek.com/wp-content/uploads/2015/09/thehomer.jpg

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.

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.

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:

This is a quote that Henry Ford actually said, verifiably so!—How to Win Friends & Influence People, Dale Carnegie.