In our personal lives, words can send our hearts leaping with joy. Words can clarify a serious misunderstanding. Lyrics to favorite songs are treasured; phrases from movies are quoted; political speeches are critiqued. Words have meaning and power and are remembered long after they are uttered. In our world of UX, words can have more than one meaning and often have been borrowed from other professions. This complexity makes the selection of words to describe our work challenging. In practicing UX work, I have often made word choices to save face and placate business partners.
The Obscure
UX jargon is difficult to parse and tough for non-UX folk to understand. How many of us have repeatedly explained to family members what we do (hopefully fewer each year)? Hiding our jargon from clients and colleagues is often the smart and thoughtful/prudent thing to do. By camouflaging our activities in common wording, UX becomes more accessible and understandable to others. For example, we might call a heuristic evaluation an expert review. This use of an alternative title improves understanding and often makes our goals clearer to non-UX professionals.
However, these seemingly harmless phrase changes can cause a variety of problems. If usability testing (UT) is renamed user acceptance testing (UAT), it might lead to confusion. UAT is understood in the industry to be an approval activity, and UT is commonly understood to be a discovery activity. Newer team members, unaware of the project-specific naming convention might adjust their work activities to be more in line with traditional UAT and not UT. For example, early in my career, I was working for a large consulting company and picked up work that had been specified by other practitioners. The people who wrote the original work proposal had moved onto other projects and were no longer available, so I needed to parse the proposal and execute it based on my own experience and the details in the proposal. Being less experienced, I did what seemed to be indicated by the proposal, but I will never know if that is what the writers of the proposal had in mind. I might have inadvertently compromised the work and thereby the UX due to the way I interpreted the proposal.
The RFP
As a consultant, I often adjust the terms I use to address the needs identified in a client-specific request for proposal (RFP). When I work with clients who are new to UX, reducing the use of jargon immediately improves communication and enables me to get to work more quickly. Setting clear expectations allows me to better meet my client’s needs. In some cases, I have learned that my use of plain language with clients can be the deciding factor for winning their work. This type of rephrasing must be carefully undertaken as it is not without risk, particularly in situations where you do not have an opportunity to clarify the RFP as I already mentioned. Misunderstandings and unforeseen consequences can result from poorly translated RFPs. For example, if an RFP calls for a focus group but team leadership refers to the activity as a usability study, then UX team members who were not involved in the RFP process might not have a clear understanding of the client’s requirements. This misunderstanding could potentially result in the application of an incorrect methodology. Additionally, a later comparison of the RFP to the resulting work might expose those inconsistencies and lead to significant issues and client dissatisfaction.
The Politics
In organizations with teams that have (or can have) overlapping responsibilities, one team might be assigned sole responsibility for a specific activity. This is done ostensibly to avoid conflict, but it can become an issue when another team needs to conduct that activity. In some cases, the political turmoil can be avoided by careful selection of alternative words. For example, I provided consulting services for a large insurance agency. The marketing department at this company was responsible for research and surveys, which included focus groups. Therefore, the UX team, due to internal politics, was required to change the name of common UX methods to avoid conflicts with the marketing department. When they needed to conduct a focus group, they referred to the activity as a joint application design (JAD) session. Unfortunately, this relabeling caused additional problems when it came time to conduct an actual JAD session. They now needed a new term for the JAD session to ensure that it was not confused with the previous focus groups. Despite these frustrations around office politics, the UX team continued to provide the company with value.
In another case, I planned the redesign of a major website for a client. I produced the initial design and then worked with a team to produce a high-fidelity prototype. Because this team owned the creation of the wireframes within the client’s organization, I was able to negotiate with them freely, and I made the recommendation that I also produce the initial wireframes. Because they owned the process of wireframe creation, we came to an agreement that what I created would be referred to as “pictorial representations” to avoid confusion. In this case, working closely with the team streamlined the process.
Politics can get particularly complicated when marketing methods are conflated with UX methods. While a focus group can be extremely useful to a seasoned and talented marketing professional, it can bring chaos to a design team’s direction for improving the user experience. When I’ve worked on UX teams within a larger marketing organization, there has been a reduction in the quality of the user experience in lieu of the marketing team’s needs. The first issue is related to different audiences because the marketing team is responsible for selling products to a buyer and the buyer is typically not the product’s end user. For example, a mid-sized corporation often relies on a purchasing department to negotiate with software vendors. The software that is selected and purchased might be used by a department in a different building or even a different city. If the software was designed by a UX team for the purchasing department and not the actual users, the software will likely fail. Conflating the two (the buyer and the user) can easily lead your team on a path to bad product design and reduced influence within the organization.
The Deliverables
I find that defining deliverables is often an exercise in reducing confusion and misunderstanding and then realigning expectations. When I initially worked in UX, the reports I created were not only long, but they needed to be printed out when provided to the client. There was an expected weight (both in content and actual physicality) to these documents. Clients who are used to getting reports that are sized in proportion to the contract (higher cost, resulting in longer, heavier reports) are often surprised at what modern UX teams create. With the pressure to deliver quick recommendations that can be acted upon immediately, we can no longer produce indigestible documents (nor should we have in the past). Calling an email or a one-page document a “report” results in cognitive dissonance for our clients. I can almost hear the higher-ups thinking, “reports are meant to be shown as a physical measure of work and displayed on a shelf. What am I supposed to do with this?”
Adding to the misunderstandings and mismatch with expectations is the UX industry’s paltry supply of deliverable examples (wireframes, prototypes, reports, and the like). This is due to a variety of reasons, ranging from embarrassment and imposter syndrome (not believing yourself to be adequate for the job at hand, despite experience and knowledge) to practical concerns about proprietary work. These reasons inhibit us from providing examples or comparators of deliverables to our stakeholders. The result is a continued mismatch between stakeholder expectations and what a UX team provides. Additionally, it becomes very difficult for a client to determine the quality of the work they have received when there is no standard to compare.
There are artifacts that we (the UX community) cannot agree on, such as personas. What is the difference between a persona, a proto-persona, and a profile? Which is the correct term to use? Which should I use to communicate to other UX professionals the amount and type of research I’ve conducted to create the document? The politics within the UX industry regarding terms such as this can be infuriating, but are also important discussions. If we cannot align on our terminology, how can we expect our stakeholders to understand what we’re delivering?
The Burden
All of this creates the burden of going through what sometimes feels like a charade. Why can’t we use our own words? Why must we always concede to the common language? The goal of building relationships and improving communications is important; however, over time these near-invisible micro-concessions can compound on UX teams in terrible ways and create heavy personal burdens. Having an outlet for teams to express their frustrations and openly discuss them is important and vital to the health of the organization. Is it worth it then to sell out and label our work marketing? While frustrating, it is definitely worth it. By making the effort to clarify, and in some cases, change the language we use, we create more understanding and trust with our partners. The team must still keep ownership of the work, avoid issues with other teams, and get the work done. Once the work is won, the evangelism can begin. I’ve had the success (and luck) to repeat work across departments in large organizations because I gained the trust of partners. Once hired, I introduce UX language to talk about the work and to educate those involved, and I recommend you do the same.
