First Few Pages of Navigating the Politics of UX, Volume 2: Operations

This month, I'm heads down writing Volume 2, which should be published early next year. Until then, here are a first few pages of the first draft. I edit my writing at least 10 times before publication, so this is in no way final copy.

Prologue

This is the book I’ve always wanted to write.

I’ve been writing it for over forty years, jotting down ideas and insights and discoveries throughout my career, accumulating over 400,000 words and thousands of presentation slides, but never finding the time to pull it all together into a coherent whole.

For me, understanding how human beings communicate and collaborate with technology to achieve meaningful results is a scientific pursuit and an engineering discipline. In this pursuit, I’ve dived down rabbit holes countless times, seeming to make progress, hitting a wall, and then starting all over again. Throughout I have waged a continual fight against complexity, believing that the theory and practice of user experience research, analysis, design, and development should be as simple as the products and services—i.e., the experiences—we strive to deliver to our users.

This book is my last attempt. I have reached the end of my UX career and am ready to move on to the next phase of my life, but I can’t move on until I get all this UX stuff out of my head. I hope there is some value here, but I acknowledge that what I am about to share with you could be the product of a delusional and obsessive mind, nothing more.

So, distilled down to its simplest form, this is what I think the essence of UX is all about:

1.????Companies want to design and develop successful products and services.

2.????Products and services are successful when they enable customers to achieve promised results.

3.????But…if the product or service requires the customer to do things she doesn’t know how to do and know things she doesn’t already know (i.e., delivers a frustrating experience), the product or service can fail even if the promised result is eventually achieved.

4.????The mission of UX is to simplify the user experience—to understand, measure, and simplify what the customer is required to do and know to achieve the results the company has promised her.

Lest you think this UX mission is easy, I offer as evidence the remainder of this book to convince you that it’s not. But it’s also not as complicated as the proliferation of UX theories and methodologies has made it out to be.

UX requires both the left brain and the right brain, research and development, analysis and synthesis, science and art, structure and creativity, decomposition and design…

…and politics. You can conduct perfect research, perform flawless analysis, develop great insights, and design elegant solutions—and still fail as a UX professional. To succeed, your UX mindsets, models, and methodologies must be understood and embraced by every functional department in your organization.

This does not mean you don’t “drive” the UX practice, but a big part of your job must be to educate, persuade, and inspire your colleagues to appreciate the first principles and governing dynamics of UX. Thus, my goal for this book is not only to offer a pragmatic approach that UX professionals can apply in their practice, but to share strategies for mastering the politics of advancing corporate UX maturity as well.

Introduction to Part 1: Starting Over

What is currently called “UX” has undergone several iterations over the past eighty or so years.

Prior to the dawn of UX, the focus in industry and academia was on inventing new technologies and getting them to work—provided you read the manuals and invested the time required to learn how to use them.

No consideration was given to the human side of the design equation. Engineers designed what was technologically possible and personally rewarding, with a complete disregard for whether anyone could or would want to use it. The UI, if you could call it that, was tacked on at the end of the development cycle, just enough to provide minimal, cryptic access to the functionality underneath.

In the late forties, “human factors” started to gain traction, recognizing that failures of technology could often be attributed to failures of the human beings who were operating the technology. This term persisted through the mid-1980s as companies hired Ph.Ds. in psychology to conduct research and analyze ways that technology needed to be redesigned to reduce human failures.

Around 1985 when I was working at HP’s Workstation Division, the company hired a psychologist as our first human factors engineer. Her job was to perform what would eventually become usability tests on our hardware and software and identify potential human factors issues that we needed to correct.

I worked with her on testing one of our operating systems. After the testing and her psychological analysis, she shared with me the problems she had found. At the end of her presentation, I asked her:

“So how would you recommend we change the design of the OS to correct these problems?”

I can’t remember exactly what she said but it was something to the effect of “I identify human factors problems, but I don’t solve them.”

I was frustrated by this answer. I decided I would take ownership of the problems and try to solve them.

By this time, in the mid-1980s I was starting to hear the terms “user friendly,” “usability,” “user-centered design (UCD),” and “human-computer interaction (HCI).” The Association for Computer Machinery (ACM) has formed a special interest group on computer-human interaction (SIGCHI) and I attended one of their early conferences in San Francisco. Not much had been written on UX at the time, but I devoured Ben Schneiderman’s book User Interface: Strategies for Effective Human-Computer Interaction, published in 1986.

My title at HP was still “Technical Writing Project Manager” but in addition to my documentation responsibilities, I would set up a camera and computer in a remote corner of HP’s warehouse and conduct usability tests on our manuals to see if people could follow the instructions (or whether they would read them at all).

In 1988 I read The Design of Everyday Things by Don Norman and, convinced that HP couldn’t write its way out of a problem it had designed itself into, I began transitioning my tech writing team into a user-centered design team. We started designing and coding graphical user interfaces to layer over command-line interfaces that simplified the use of UNIX. Then shortly after Don Norman coined the term “user experience” at Apple in 1993, I joined HP Corporate Engineering’s newly-formed Design for the User (DFU) team and adopted user experience design as the focus of my mission.

As of this writing, “UX” is still the dominate moniker for the practice of user research and user-centered design, although it has recently splintered into Service Design (SX), Employee Experience Design (EX), Customer Experience Design (CX), Developer Design or Digital Transformation (DX), etc.

I think user experience remains a serviceable umbrella term for the various disciplines of designing products and services with people in mind, which explains why it has persisted for so many decades.

Over the span of the last several decades, the methodologies and practice of UX have proliferated and evolved into a cornucopia of theories, principles, models, tools, and techniques for researching, analyzing, designing, testing, and developing the user experience. I think I’ve employed most of them.

But today, the UX field has become bloated and complex. It’s no wonder that people interested in entering the field are overwhelmed.

So, in this book, I want to start over. Let’s step back a minute, wipe the slate clean. Let’s forget qual and quant and design thinking and personas and empathy maps and user stories and journey maps and wireframes and mockups and prototypes and…all the rest. Rather than approaching UX as a process with sprints and backlogs, patterns and tools, activities and artifacts, let's think of it as a cascade of questions we need to answer.?As we answer these questions one by one, we can rediscover the essence of UX and identify the (hopefully small set) of mindsets, models, tools, and methodologies are essential to its practice.

I know what you’re thinking. Won’t we just be duplicating what UX thought leaders have already invented? Do we really need to start over?

I think we do. To overcome our overwhelm, we must discover the first principles and governing dynamics of UX for ourselves.

Only then can we fully understand them and make them our own.

Only then can we educate and inspire our colleagues with simple logic that they can understand because we deeply understand it ourselves.

Only then can we effectively manage the operations of our UX practice and successfully navigate the politics of UX.

Let’s begin with the first question.