Practical UX Design

4.4 (8 reviews total)
By Scott Faranello
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

Written in an easy-to-read style, this book provides real-world examples, a historical perspective, and a holistic approach to design that will ground you in the fundamental essentials of interactive design, allow you to make more informed design decisions, and increase your understanding of UX in order to reach the highest levels of UX maturity. As you will see, UX is more than just delighting customers and users. It is also about thinking like a UX practitioner, making time for creativity, recognizing good design when you see it, understanding Information Architecture as more than just organizing and labeling websites, using design patterns to influence user behavior and decision making, approaching UX from a business perspective, transforming your client’s and company’s fundamental understanding of UX and its true value, and so much more.

This book is an invaluable resource of knowledge, perspective, and inspiration for those seeking to become better UX designers, increase their confidence, become more mature design leaders, and deliver solutions that provide measurable value to stakeholders, customers, and users regardless of project type, size, and delivery method.

Publication date:
April 2016
Publisher
Packt
Pages
232
ISBN
9781785880896

 

Chapter 1. The User Experience Mindset

 

"Silicon Valley is a mindset, not a location."

 
 --Reid Hoffman

Let's begin by introducing the first topic that every User Experience (UX) practitioner, and business stakeholder needs to understand about UX: The mindset of UX and what it means to think like a UX practitioner. However, before we do that, let's understand something about UX itself.

UX is a skill. It's a practice. It's about where to place a button on a website and how to organize content. It's about how to improve screen and interface design. It's about wireframes, focus groups, and usability studies. These are the things we know about UX, but what else should we know?

UX is also about collaboration. It's about solving problems and finding solutions. UX is about looking at the world with a unique perspective and a unique mindset. UX is also about focusing on the right people at the right time, including customers, end users and also stakeholders whose business goals and objectives are directly related to UX decisions. As you will see, however, UX is harder to get across than you might think. Good design may seem like a no brainer, but, it is not that simple.

In this chapter we will look at:

  • The myths about mindset

  • Solving problems effectively

  • Examples of using the UX mindset

  • The perils of ignoring UX

Let's begin with a story, a myth if you will, that needs to be dispelled if we expect to deliver better design though UX, better solutions and help those who need our help to understand our true value.

 

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.

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.

 

Data-driven design


One of the things we talked about in this chapter is getting to root causes, which is a key element of the UX mindset. Root causes are found when you pull back all the layers of a problem until you can no longer ask why and are ready to ask how are you going to solve the problem. This requires asking the right questions that will not only solve customer/user problems, but will solve stakeholder needs as well.

For example, asking stakeholders:

  • What is the current business problem?

  • How do you know it's a problem?

  • What are the measurable business goals and objectives, otherwise known as key performance indicators (KPIs)?

  • How will we know we are successful?

  • What business areas/systems/applications are impacted?

  • What are the risks to the company, our customers and our users if we don't solve it?

These are hard questions, but important ones because they challenge stakeholders to think about why we are solving a problem and how to do it. It also gets stakeholders engaged in the process. Without this approach there is no way to know what is broken and by how much. Every problem worth solving must be evidenced based using the current version of a system, if possible, to understand what is in need of repair.

Despite the importance of data and its proven value, many companies still do not track it with regards to translating metrics into good design, something we will talk about in depth in a later chapter. Without knowing what you are trying to measure and what the current baseline to measure against is, you are essentially designing blind; the equivalent of throwing darts hoping to hit the bullseye. The problem is you will be throwing them while blindfolded and at a moving target.

Asking hard question will provide real numbers that you can design against and test to see whether your assumptions are correct. You can then track these numbers later when the product launches to make sure your improvements are effective, from a customer/user and business perspective.

 

"The process of innovation begins with identifying the outcomes customers want to achieve; it ends in the creation of items they will buy…When desired outcomes become the focus of customer research, innovation is no longer a matter of wish fulfillment or serendipity; it is instead a manageable, predictable discipline."

 
 --Anthony W. Ulwick, Turn Customer Input into Innovation
 

The meme that just won't die


By now, we've dispelled the "faster horse" myth once and for all. No longer will we utter this quote, nor will we allow others to do so in our presence, without sharing with them why it's short sighted and wrong. We are also in a better position to correct them because we are thinking with a UX mindset that will guide us to better solutions, right? There is, however, one problem. As I stated earlier, Ford's supposed "faster horse" quote is not the only one of its kind.

 

"We built [the Mac] for ourselves. We were the group of people who were going to judge whether it was great or not. We weren't going to go out and do market research."

 
 --Steve Jobs

Oh no. Here we go again! Let's put a stop to it right now with this: Steve Jobs did not ignore his customers! In fact, Jobs listened intensely to them.

 

"Really great products come from melding two points of view—the technology point of view and the customer point of view. You need both…It takes a long time to pull out of customers what they really want, and it takes a long time to pull out of technology what it can really give."

 
 --An interview with Steven Jobs, Inc.'s Entrepreneur of the Decade, by Bo Burlingham.

As we mentioned earlier, listening is key, and interpreting what is said is even more important. To put it another way, don't provide your customers with a more comfortable way of standing when sitting is preferred, and don't provide them with a faster horse when an affordable automobile makes more sense. Good design is not about assuming the truth. Good design is about knowing is the truth based on research, testing and more testing to validate your assumptions and then to compare the data. Only then will you prove that your design truly makes a difference.

 

Design thinking: an idea worth investing in


When you are ready to start designing solutions based on all the pre-work you've done: understanding your stakeholders/customers/users, the technology available, the long-term return on investment and of course the human aspect, that is, will people like and use what you give them, you will then want to begin working on a solution with a team. Henry Ford and Steve Jobs did not work alone and neither should you. One way to do this is using a technique called Design Thinking.

Design thinking originated at The School of Engineering at California's Stanford University with a course designed to prepare a generation of innovators to tackle complex challenges. Design thinking challenges participants to solve problems by first defining them and then iterating as a collaborative team focused on developing an unexpected range of possible solutions…to take back out into the field and test with real people.—http://dschool.stanford.edu/our-point-of-view/.

Designing thinking follows a very simple approach to problem solving that introduces the UX mindset to those who may not have experienced it before. Here are the steps:

We can break this down even further, taking into consideration three of the most important areas of focus: technology, business, and human values, as shown here:

  • Technology (feasibility): This is the "how "of product design. It refers to how we make it happen with what we have at our disposal, such as, technology, budgetary constraints, stakeholder goals, user/customer problems, and so on.

  • Business (viability): This refers to long-term return on investment (ROI) and how long it will take to reach those goals.

  • Human values (usability, desirability): This refers to the reactions from customers/users. Will people like our solution and use it? Will they be excited about it? Is it unique and easy to use? Does it solve an identifiable problem that we have observed through research and observation?

 

"You realize that you aren't going to solve the problem sitting in an office, you need to get out and talk to the people who are actually dealing with it, whether that's your customers or your front-line employees."

 
 --Design Thinking graduate.

In 2006, the design thinking program at Standford, also known as d.School, launched a week-long education program for managers and executives called Customer-Focused Innovation (CFI), where participants from across industries approached problems in a collaborative setting and from the customers' point of view. As of this writing, admission to CFI is approx $15,000 for one week of training, teamwork, creativity, and innovation. That's quite an investment and a positive development in dispelling the "faster horses" myth once and for all.

 

One more thing


 

"There is nothing in a caterpillar that tells you it's going to be a butterfly."

 
 --Richard Buckminster "Bucky" Fuller

There is a cemetery in Watertown, MA with a grave marker that reads, "Call me trim tab. Bucky." This is the final resting place of Richard Buckminster "Bucky" Fuller, an American architect, author, designer and inventor. He is perhaps best known for developing the structural mathematics of the geodesic dome, an example of which can be seen in the following image, otherwise known as Spaceship Earth from Disney World's Epcot Center theme park.

Fuller was a problem solver and a big thinker who took on very challenging problems, concepts and ideas with passion and a perspective very reminiscent of the UX mindset.

 

"If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday's fortuitous contriving's as constituting the only means for solving a given problem."

 
 --R. Buckminster Fuller

Fuller understood that solving problems and reaching conclusions meant challenging what we think we know and learning more about what we don't in order that we might find what Fuller referred to as the non-obvious and thus far better solutions:

 

"Everything you've learned in school as obvious becomes less and less obvious as you begin to study the universe. For example, there are no solids in the universe. There's not even a suggestion of a solid. There are no absolute continuums. There are no surfaces. There are no straight lines."

 
 --R. Buckminster Fuller

To better explain this type of problem solving mindset, Fuller used the metaphor of a "trim tab," a small rudder connected to a larger rudder found on ships and airplanes. Here is an example of a trimtab:

A trim tab is used to turn a very large object with minimal effort, as Wikipedia explains:

 

"The use of trim tabs significantly reduces a pilot's workload during continuous maneuvers…allowing them to focus their attention on other tasks such as traffic avoidance or communication with air traffic control."

 
 --Trim tab, From Wikipedia, the free encyclopedia

Another reason for Fuller's interest in the trim tab was its small size compared to the larger whole. Based on its relative size compared to the rest of the ship or plane, the trim tab can easily go unnoticed even though it is integral to the overall solution. If we look at the trim tab from a perspective of project design and problem solving, we see how easy it can be to miss the most important aspect of a design solution if we are not looking in the right places. As a result, siloed teams that turn hard problems into quick, low cost solutions while excluding UX can never truly design the best solutions because the best solutions are often the most non-obvious. To find them requires observation, collaboration, creativity and a creative, open mindset that allows good design solutions to happen.

 

"[Get] rid of a little nonsense, [get] rid of things that don't work and aren't true until you start to get that trim tab motion. It works every time. That's the grand strategy you're going for."

 
 --R. Buckminster Fuller

It is not much of a leap to suggest that the UX mindset is our trim tab, an approach that significantly reduces workload, improves efficiency and increases effectiveness. The trim tab may also be the mechanism for turning large, siloed teams into collaborative partners helping to turn large problems into viable solutions that are more efficient, effective and satisfying. This, Fuller said, is the grand strategy we are going for.

 

In closing, a cautionary tale


 

"Socrates said, "Know thyself." I say, "Know thy users." and guess what? They don't think like you do."

 
 --Josh Brewer, Principal Designer at Twitter

In this final section, I want to share a cautionary tale, a case study of sorts, about what happens when the UX mindset is ignored and "faster horses" wins out. Unfortunately, this is an all too common scenario that can have serious repercussions.

The story: A pilot purchased an experimental, homemade aircraft and decided to take her up for a short flight. The plane was small, with very little space for the pilot to move around. Here is a photo of a similar plane:

The plane had one previous owner, another pilot who built the plane himself. It was a sparse design that included two gas tanks, one in each wing and a fuel selector valve behind the pilots head to switch between them when one tank was low on fuel.

The cockpit provided very little legroom and no room at all to move around during flight. Because of such tight quarters and to avoid the possibility of a rupturing a fuel line in the event of a belly landing, the plane's builder chose to put the fuel lines behind the pilots head, a change from the original design that called for them to be placed along the cockpit floor. Another change in design was the location of the fuel selector valve. Rather than in front of the pilot, it was placed behind the head and over the left shoulder.

Prior to this particular flight, the pilot and his technician talked about the inaccessibility of the fuel selector valve and its resistance to being turned, at one point using a pair of vice grips and a small mirror as a workaround to avoid having to turn and look at it during flight. In retrospect, the plane's original builder was thinking about safety by changing the location of the fuel lines, but in doing so he created a number of critical design flaws. First was the location of the fuel selector and another was not considering an inexperienced in this type of aircraft. The the third was having to interact with a custom-placed fuel selector valve that, by all accounts, was hard to use. Unfortunately, it wasn't long before these flaws made themselves apparent.

As the investigators attempted to recreate the conditions leading up to the crash that took the pilot's life, it didn't take long to figure out what went wrong. The fuel selector valve, a non-obvious problem that the plane's builder never noticed, caused the pilot to extend right foot against the right rudder pedal in order to support body as turned the valve. This put the plane in an unrecoverable spin straight into the Pacific. It was over before the pilot knew what happened.

The aftermath: To call this a mishap a "PICNIC", problem in chair, not in computer, would be incorrect. Those not using a UX mindset might fail to understand that the user will work with what they are given, regardless of the challenges. They may try to compensate with a workaround, but it is the designer who is ultimately responsible for the outcome. Failure to design deliverables with a UX mindset—one's that have been thoroughly tested—can lead to disastrous effects. Now, I am not suggesting that the work of a UX practitioner is life and death, but without a UX mindset it certainly can be when we consider the range of industries in which we can work, such as aviation, hospital emergency room equipment and military technology. In those industries, good design is crucial and can literally be a matter of life and death if we get it wrong.

The user should never notice an interaction or have to think much about it at all. To put it in the simplest of terms, stuff should just work! It should do what the user expects it to do without distraction. Anything less risks failure. Unlike the pilot in this story, we have the opportunity to learn from failure and try again to make it better. Our customers/users rely on that. To ignore them and miss the non-obvious as a result will not be their fault. It is entirely ours. The UX mindset is a muscle that requires attention and usage to get the most out of it and to dispel the myths of "faster horse" thinking for good.

 

Summary


This chapter introduced the UX mindset, one of the most important concepts you will learn as a UX designer and practitioner and one we will refer back to again and again. We also talked about the myth that listening to our customers/users derails good design and dispelled it using many examples. UX is more than a set of tools, skills, tips and tricks. If we want to be better UX designers and more practical in our approach we first have to acquire the mindset to make it so. UX is a way of viewing the world around you and using it to solve even the most complex and challenging problems, something we will see in later chapters.

Now, let's move on to Chapter 2, Creative UX, where we will explore how the UX mindset goes about creating good design.

About the Author

  • Scott Faranello

    Scott Faranello has been a dedicated and passionate UX professional for well more than a decade now, working with many companies in very diverse organizational cultures. His experience includes intensive customer, user, and business research, conceptual wireframes, designing information architecture, conducting user and usability tests, measuring the ROI of usability, creating visual design, and staying abreast of the current UX technology trends. Scott is also the author of Balsamiq Wireframes Quickstart Guide (2012) and Practical UX Design (2016), Packt Publishing.

    Browse publications by this author

Latest Reviews

(8 reviews total)
The writing kind of goes on tangents, but the message is still good and useful
Really gets you thinking on how to tackle projects. It covers a few corners of UX. It has a really nice section on how to effectively test UX and how best to present it. Some good references to other books to take your reading further. Recommended.
This book offers a different approach and it is a great complement to other titles on the subject. I'm not sure if the title describes adequately its content, it focuses on important core concepts of UX however, it does elaborate on how to incorporate UX practice as part of a company's structure. Sometimes the author struggles to keep his examples on the realm of UX but with a bit of imagination readers can come up with examples of their own.
Practical UX Design
Unlock this book and the full library FREE for 7 days
Start now