Customer-driven content design: A real-life example

By Antonia Blume and Erica Jorgensen 

Photo credit: iStock

Small business owners take on many diverse tasks to keep their business running. While they may have become entrepreneurs because they like to bake, or teach, or design tattoos, they also by necessity wear many hats to keep their business running– bookkeeper, customer service agent, procurement specialist, sales manager, social media planner, HR manager, and IT specialist, just to name a few. 

Our UX content writing team wanted to understand how very small business (VSB) customers approach their IT tasks, specifically those in Microsoft 365 admin center (MAC). (VSBs are classified as organizations with fewer than 10 users.) The admin center is a portal for anyone who’s managing a Microsoft 365 subscription for their organization. It’s important that all users of the admin center achieve their business goals (for example, adding a new user) as productively as possible. The language within the user experience (UX) is key to supporting that. We also want users to feel confident as they’re using the admin center. This confidence is essential in supporting our team’s objectives, including Net Promoter Score (NPS) and overall customer satisfaction (SAT).  

Our hypothesis was that the IT terminology would largely be unfamiliar to VSB admins, impeding their ability to complete tasks efficiently and reducing their confidence and satisfaction in using the admin center. We wanted to thoroughly test that hypothesis, check our biases, understand which specific terms were not intuitive, and identify what alternatives would work better for them. 

User research can be a valuable tool in understanding the language preferences of a particular group of customers. My colleagues and I explained our approach to this research in this previous blog post. One aspect of that post is worth revisiting here, as these were the driving principles behind the VSB research: 

Five things language can do as part of UX design 

• Support ease of use. Consistent terminology, style, and content patterns create a user interface (UI) that‘s scannable and predictable. 
• Add clarity and readability. Plain, descriptive language makes what we’re saying clear and easy to read. Plain language means using words that are in most people’s common vocabulary or that are in the vernacular for your audience. It means not making up a new term for a feature or functionality if we can use a common word to identify it and a description to clarify what it does or means. 
• Create an information scent that supports wayfinding. Language guides customers with structure (such as grouping and ordering information), and labeling that matches how customers think about a task or activity. 
• Build trust. When we describe features from the perspective of how they benefit customers and what will happen when customers take a specific action, we help build trust and confidence. 
• Support and convey our brand. Language that reflects the brand voice feels consistent and reassures the customer. Conversely, off-brand language or inconsistent terminology creates dissonance and erodes trust and the customer’s confidence level and can even make users feel unsure or anxious. When customers trust us, they tend to be more loyal to our brand and products, and more likely to recommend Microsoft to others.  

We used a combination of research techniques, such as card sorting, tree testing, surveys, benchmark studies, 1:1 interviews, and focus groups. By combining these methods, we gained better understanding of these users’ mental models, information categorization patterns, and language preferences in relation to top tasks within the Settings and Billing sections of the admin center. 

Testing for true understanding 

Interestingly, while the majority of the VSB participants claimed they understood the terms in question, some of the definitions they provided lacked clarity or specificity. This made it hard to assess whether these participants truly understood the terms. These will merit further study.  

For example, we hypothesized that test participants would not understand the term “domain.” “Domain” has been a term of special concern across our design and product management team, as we know there’s drop-off in domain-related task steps. Testers surprised us by stating they’re familiar with and have a solid grasp of the concept. However, when we asked participants to define the term, many were imprecise and not entirely accurate. This signals to us that, even though they have some knowledge about domains, it may not be enough to give them confidence when completing domain-related tasks in the admin center. Therefore, in the UX, we need to provide examples of what a domain looks like, define the term in a tooltip, and ensure the visual and content design in the admin center do all they can to boost user confidence as they complete domain-related tasks, such as creating their username.   

Conversely, a term that was unfamiliar to most participants was “seats,” a term we have used to denote the number of people who are licensed to use a product. Notably, its synonym “licenses” was a term that most participants said they understood, but several commented that they believed a license was required for each device; when in reality, each user gets a license that they can use on multiple devices. Based on that, the product should use the term “license” instead of “seat” in product sign-ups and other experiences targeting VSB customers, and we should also clearly explain that one license is needed for each user, and that each user can use the app on as many devices as they wish. 

Finding an appropriate term for the purchasing space within the admin center was another area we examined. We found that participants preferred the term “Marketplace” over “Purchase services” (the current name), Purchasing, or Shopping. “Marketplace” was favored almost 5 times more than the next-most popular option, which was surprising to our feature team. We’ve run additional testing showing that some users think that you only need one license for your whole organization. So, there’s lots of confusion about how licenses are assigned. Terminology testing has provided us several customer insights that should help improve customer satisfaction!  

Example of how we posed one question about language choices.

Where the research made the most difference 

Sometimes, different stakeholders have opposing views of what to name a feature or group of features in a product. In this case, the entry point for managing third–party app settings had been the subject of some debate. The parties that were disagreeing collaborated on a list of naming options which my team then tested with users. The name “integrated apps” was the clear winner, resolving the conflict and providing a naming option that we knew would resonate with our audience.  

In another example, the team updating the billing interface wanted to use the term “Inventory” for the area of the admin center where customers manage the apps they have. Our research revealed that this was the single most confusing term tested. What term did customers prefer? “My products.” 

We used the recommendations from the information architecture (IA) study to inform our navigation naming principles and help drive customer-informed discussions about navigation naming. 

The Microsoft 365 admin center has many facets, and we’ll need more research to uncover whether  our users are truly as familiar with the terms as they claimed to be, or if there are other areas where changes in word choice and clarifications can help avoid confusion. We’ll continue to partner with our design, product management, and engineering stakeholders to provide recommendations on optimizing the language to improve the customer experience.  

Did this article give you ideas on how language can improve your customers’ experience? What tools have you used to understand your customers’ language preferences? Tweet us your thoughts @MicrosoftRI or follow us on Facebook and join the conversation.