“I’ve only thought about one problem in my life, which is how to improve Coast Guard Search and Rescue.” – Art Allen

Image by Skeez Image by Skeez

A former colleague recently shared this story about former Coast Guard scientist Art Allen with me. Those of you who have been in the UX industry for a decade or more will be able to relate to the challenges Allen faced during the majority of his spectacular, if unknown of, forty-year career.

Allen was a scientist and a person whose work was a critical piece – even if institutionally unrecognized and under supported – to the U.S. Coast Guard’s ability to save lives at sea in emergency search and rescue scenarios. Working in virtually uncharted territory. Being the lone expert. Consulted for answers to difficult questions with scant support or resources to aid his investigations. This is what he endured throughout his career – and what many UX professionals also experience.

“For nearly 40 years, Art Allen had been the lone oceanographer inside the U.S. Coast Guard’s Search and Rescue division. Among other subjects, he had mastered the art of finding things and people lost at sea. At any given moment, all sorts of objects are drifting in the ocean, a surprising number of them Americans.”

Luckily for UX professionals, the number of practitioners in our profession has increased in recent years, so we are no longer the lone experts or alone. Thankfully, we have professional peers who are sympathetic to our challenges, and within reach to confer, collaborate, and exchange ideas with. But when it comes to the dynamics of how UX professionals’ knowledge, skillsets, and work outputs are viewed and utilized by many organizations, things haven’t changed much. Much like Allen, UX professionals are often not afforded the resources, access, or time for meaningful exploration and feedback. This hampers their ability to deliver solutions to the challenges that they are hired and tasked to solve—at least, solutions that UX professionals, or anyone else for that matter, can be certain will hold water.

“For most of human history, lost at sea meant gone for good.”

Allen’s most important work, a labor of love really, was a report he published called the “Review of Leeway”. The information in the 351-page report, which Allen envisioned as a resource to help rescuers locate and save the lives of people in trouble at sea, was based on data from studies and experiments that he conducted, or from the results of studies and experiments published by others. Inputs for the Review of Leeway were the result of primary and secondary research efforts undertaken by Allen on his own personal time. UX professionals that have had to conduct “guerilla usability tests” or other forms of informal inquiry and testing on their work for projects with zero time or budget allocation for primary research or validation will relate to this.

The above may sound all too familiar to some, but it gets worse. It took 15 years for Allen to have the opportunity to find out whether or not his report was helping search-and-rescue professionals as intended. In fact, it was only at the invitation of a commander of a Coast Guard Search and Rescue team in southern Virginia that Allen was able to see how folks in the field worked and what difference or impact the information in his report was making.

Many UX professionals will recognize and be familiar with the lack of access, visibility and feedback to their work outputs (e.g. website navigation or app UI, functionality, and content) in real world contexts, or in “the wild” as many often refer to work output after it has been released. Lack of adequate investment in mechanisms for gathering feedback or monitoring user performance after initial release make it difficult for UX professionals to gain empirical knowledge about what works. This is often the result of a lack of interest and investment in the time, tools, and procedures needed to provide the visibility and feedback loops that UX professionals need to validate and optimize the solutions they deliver. The irony is that in a world that often craves real-world data to inform big, expensive, or critical business undertakings, there is often little interest in investing any time or resources into what could potentially save millions—or tens of millions—of dollars. This is even truer for UX professionals in the consulting world—even as their employers and their clients turn to them more than ever for answers, insights, and solutions to increasingly complex questions and challenges.

On the day Allen visited the Coast Guard field office in southern Virginia, there happened to be a weather event in the Chesapeake Bay that triggered a large number of distress and rescue calls. Here’s what Allen witnessed:

“The search and rescue operator was dispatching helicopters and cutters as fast as he could, and saving one person after another. For help, he had only a crude computer tool and was having to make a lot of calculations by hand. Art was impressed, but after six hours of drama he could see the guy tiring. ‘And after all of this,’ said Art, ‘someone calls in at the end of the day and says, ‘We have an overdue sailboat.”’

“Just how weary the search and rescue guy had become revealed itself when he tried to use a satellite picture to zoom in on the Chesapeake Bay only to realize, after a very long beat, that he was actually staring at the mouth of the Yangtze River in China.

“Art watched what this obviously overwhelmed young man plug crude information into his crude computer tool. He had a fair description of these people’s plans but his program didn’t allow him to input a voyage. Nor could he find good data on the winds over the water — he finally pulled something from an anemometer at a nearby state park. He didn’t even have a good reading of the tides in the bay. On top of all this, he had no drift equations for a swamped skiff, as Art hadn’t studied one. The equations the guy was using came from work on a drifting sailboat done [in a study 40 years before]. “I could see he couldn’t adequately plan the search,’ said Art. ‘The tool he’d been given could not help him do what he needed to do.'”

Any UX professional that has done primary onsite, observational-based research or studies (such as contextual inquiry, follow-along, ethnographic study, or participatory design) will be familiar with what Allen described that day. UX professionals that have experience with that sort of research or approach can probably predict what happened next.

“And so the Coast Guard went looking for something without any real idea of where it was. The helicopters and an 87-foot cutter searched through the night, and found nothing. Not until the following morning did the sailboat appear, upside down, a long way from where the Coast Guard had been searching.”

For those who’d like to find out more about how the events of that day played out, as well as what happened in the years that followed, please read the rest of Michael Lewis’ wonderful account of Allen’s story here.

When circumstances dictate that my teams or I must push through to get the job done, I have often felt it is OK to compromise and leave certain rocks unturned. “At the end of the day, the work isn’t going to determine whether someone lives or dies,” I have often thought or said. But I have done so, especially on business-critical projects, with the assumption that my teams or I will get to revisit things in the future. This sort of compromise has been more common in recent years with the rise of Lean UX, agile, and product-oriented methods where only good enough—not perfection—is required at the initial pass. Nevertheless, my teams and I have never really taken this decision lightly, as we know that unexpected results are often less-than-desirable and can result in mistakes and unpleasant outcomes—even if they are not as lethal or catastrophic as what happened the day Allen visited Coast Guard operation in southern Virginia.

Furthermore, as UX professionals and advocates for people that use our products, we—and others—ought to take seriously the responsibilities that come with designing for the best experiences and outcomes for target audiences and the business we work for. Of course, if my team or I were ever involved with work that has a role in determining life-or-death outcomes, my hope is that I am never asked to compromise, and that there are systems and rules in place to never let that happen.

UX professionals, myself included, would be well-served to take Allen’s story as a cautionary tale and make more of an effort to insist that our work and our professional expertise be taken seriously and valued enough by those who come to us for informed answers to their questions or for help to find meaningful, viable, and rightly aligned solutions to the challenges they need us to help them solve. Although easier said than done, Allen’s story tells us that it is necessary.

Image by Gino Crescoli

According to a recent report published by UX research vendor UserZoom, 70 percent of CEOs view user experience as a key competitive differentiator, and that 29 percent of enterprises had a UX/CX executive leadership role in 2019, up from 21 percent the year before. This is without doubt welcome news and potential cause for celebration.

Given Allen’s story, and my experiences during 20 years as an information architect and UX strategist, UserZoom’s findings raise the following questions: What kind of “UX” do CEOs know about and see as being a “key competitive differentiator?” Is it the kind of UX that focuses on visual and UI oriented outputs with little or no input or feedback from the realities of the “wild?” Or is it a broader, more systematic kind of UX that goes beyond screens to include the rigor of an interdisciplinary approach and processes that seek to understand people and meet their needs in context through research and testing that stories like Allen’s compel us to advocate for and work to build?

I am hoping it is the latter, but I expect it will be a winding and arduous road to get from where UX currently is to what I see as the Promised Land for designing meaningful and successful experiences for people.