By the end of the 1990s, the conceptual foundations of UX were well established. Thought leaders at UX HQ like Don Norman had defined many of the aims, concepts, and methods of this field. But in business project teams, awareness of UX was … er … uneven, and the task evangelizing UX fell to many uncredited pioneers. Part of their legacy is amusing stories, some which are compiled here.

Whether you were one of these pioneers, or whether you joined the field more recently, these stories provide the opportunity to reflect on where we’ve come from, and where our field might be headed.

I guess I’ll call this a win

Delivering a great user experience (or even an adequate one) was not a widely accepted goal of project teams in the 1990s. Projects focused instead on delivering more functionality with the latest technology, and this was seen as equivalent to delivering a great UX. So, UX pioneers often gained lots of experience being assertive and wily advocates for aims and methods of UX. In that culture, it was important to cherish each small win to maintain morale.

I was working for a company where programming priorities usually trumped UX considerations — a typical culture for the time. But on one occasion I was able to use this to my advantage.

One day an executive asked me to join his key project to leverage my programming skills. This was an offer I did not wish to accept. So, knowing he would refuse, I said disingenuously, “Fine, but only if I get a healthy budget for UX design, and carte blanche for how to use it.”

After a moment of consideration he said, “Deal”. So… I guess I’d call this a win?

As the first usability specialist on a project, I usually encountered a fair amount of pushback. But people eventually came around, at least to some degree.

However, one technical lead was exceptionally obstructive. He would not make any allowance for any UX activity in his project plan and would reject any usability input.

After the final project meeting, he came up to me and said something out of character: With the benefit of hindsight, he now saw the value of what I was advocating for, apologized, and vowed to be more receptive to usability and UX in his next project.

Questions for reflection

While there’s more acceptance of UX today, UX leads still need to champion UX as a project goal and priority.

• What is the right balance between improving the UX and adding more functionality in a project’s priorities and resource allocation?
• How can UX success be articulated in project goals and metrics?
• Making UX a priority often hinges on the support of a key decision maker like an executive project sponsor or technical lead. How can these people be won over?

Agile UX — 90s style

In the 1990s, when an organization got onboard with the idea of UX, a common next step was hiring some UX staff and setting them loose to “do UX.” These UX pioneers were faced with working out the logistical details of adapting to, or changing, project practices to create a space for “doing UX”. While most pioneers faced a tough trail, some had the good fortune to co-create practices that would still be considered exemplary today.

I once worked on a project team that was exemplary in how it integrated UX and Agile practices — but this was in 1993! (about 10 years before most people had even heard the term “Agile.”)

The full team of six people met every Monday to plan the goals for the week, then we met each morning to coordinate our work for that day. I was the UX designer but many others contributed to the design, and I contributed to other other activities like writing QA test cases. Since then, I’ve worked on many Agile teams — some as good, but none better.

In the early 1990s, I worked in a usability lab that scheduled a full day of usability sessions for a single project. When it was a project team’s “day at the usability lab”, we required the attendance of every project role — product manager, developer, writer, business sponsor — you name it. (There was no “UX designer” role in our company back then).

During the lunch break, the team would revise their prototype based on what they learned in the morning sessions, and test their revised design in the afternoon. It doesn’t get much more Agile than that.”

Questions for reflection

Today, there’s much published guidance available on fitting UX into a project’s work practices. But UX leads still need to iron out the details to address the unique circumstances of each project team.

• What is the right balance between changing team practices to accommodate UX practices vs. adapting UX practices to fit the existing team practices?
• Some project teams have low-quality Agile practices which poses a limiting factor on UX success. To what extent should UX leads expend effort on improving overall project practices vs. focusing on better adoption of UX?

“Move fast and break things” reconsidered

In the 1990s, when UXers were not busy evangelizing to executives or integrating with project teams, they got out of the office to speak with users. UX textbooks had led UXers to believe that users would greet them with open arms. But this was not always the case, as these stories show:

I was given access to some back office staff to interview for a project to enhance an internal system they used. There’s one user interview I still remember decades later. A fire plug of a woman sits down for the interview and says, “My boss told me to come to this meeting, but he didn’t say what it was about.”

Earnestly, I explained that we wanted her input on some enhancements to the software she used. Then she said, “My input is that I don’t want you to change anything. Every time you people change our system, we can no longer do our work the way we’re used to. So, that’s my input: don’t change the system.”

Then she stood up and left the room.

I was working on a project for the Air Force of a certain European country to modernize a staff management reporting system. When I sought access to the intended users, I was repeatedly stymied. Eventually, someone took me aside to explain the reason.

The existing process was mind bogglingly inefficient for a good reason: it provided jobs for lots of people doing their mandatory National Service. These people had lucked into this office role that avoided the typical experience of marching in the mud and being yelled at by NCOs. Their primary goal was to get to complete their two-year commitment without jeopardizing their position.

Questions for reflection

While the details of these stories might be dated, their lesson is not: People don’t appreciate having their ways of working “disrupted” by technologists.

• When generating and evaluating “big ideas” for improving the current state, do UXers adequately consider possible negative reactions to change?
• When conducting user research, do UXers give adequate attention to understanding how the new UX will require the user to adapt, and how they feel about that?

Conclusion

In the 1990s, the conceptual foundations of the UX discipline were well established, but innovation and stamina were still required to achieve their adoption in the field. This work fell to countless uncredited pioneers in many companies, some of whose stories have been shared here.

This pioneering work involved several constituencies:

• Project sponsors and leaders: To align on the aims and priority of UX.
• Project team members: To determine how to integrate UX activities into day-to-day project work.
• Users: To remind ourselves that we’re designing for real people who might have mixed feelings about having their current experience “improved.”

How are things compared to the 1990s? Certainly, today’s typical project team is more enlightened. However, as the saying goes, the future does not arrive everywhere at the same time. In the early 1990s, one could find teams with UX practices that were just as enlightened as the best teams of today. Conversely, today there remain teams that seem still stuck in the 1990s. So there’s still more pioneering work to be done.

Share your stories! There’s lots more great stories from the 1990s. Share yours in the comments.