Customers, users, and the technical communication clarity problem
When it comes to selling software, a ‘customer’ is not necessarily the same as a ‘user’. Nor are the two terms particularly insightful to begin with.
For example, a ‘customer’ could refer to an entire brand using your software. Or, it could refer to a specific person or team making the purchase decision. And of course, it could also refer to an individual ‘user’ – even if that user had little to do with the sales transaction.
User, meanwhile, has its own mix of clarity issues. A user could be anyone, and each user could find interest in different aspects of your software.
In terms of generating understanding, then, ‘customers’ and ‘users’ are maddeningly unhelpful. In other words, they represent a problem with technical communication clarity.
The problem
When developing a software product, an early entry on the to-do list is to write user stories. This means thinking about the target audience — the people the software will cater to.
But the problem is that this audience often comprises an array of different professions, skills and workloads. For larger SaaS solutions, for example, your product will likely have more than one use case for more than one industry.
Yet everyone in your user stories holds the title of a ‘user’. True, they all use the software. But they won’t all use it in the same way. Your various users won’t all prioritise the same things. In some cases, they might even see different interfaces of the software.
In short, general discussions around ‘customers’ and ‘users’ are too vague. The terminology is a symptom of a technical communication clarity problem.
Who are you talking about?
Without technical communication clarity, developers can’t accurately understand the people they’re helping. (Or the problems the software needs to solve). When you use the word ‘user’ or ‘customer’, who are you talking about?
For example, if you sell your software to retailers, you could find yourself thinking of users as the consumer in the shop navigating an app window. But what about the sales associates and their version of the client? Or the manager, who operates a different administrator interface? Or are you really programming for the analysts that decide which software to use?
This identification problem could be applied to any industry. So, if you sell to the financial sector, users could be bank tellers, financial advisors, accountants.
In the case of software for healthcare, is the ‘user’ you’re talking about a pharmacist, a patient, a doctor? How would a dermatologist benefit from your software? Or a hospital receptionist?
In B2B sales, you might have users that are marketers, business owners, product leads, or IT specialists. When it comes to customer service software, your users are both the business you sell to, and their customers, too. (Think live chat software, for example, in which the web visitor sees a web chat window while the live chat operator has a feature-rich live chat client.)
And the list continues.
Defining your ‘users’
Your product will bring different benefits to these varied people. While no business caters to everyone, even in a niche, there’s a huge variety of people covered by the term ‘users’. When you write ‘user’ in your user story, you could mean any one of these people.
So, how can you determine who you’re talking about when you write ‘users’ or ‘customers’?
For a start, you’ll want to focus on your target audience. The best practice highlights the importance of specificity. That is, go as deep into the specifics of your target audience as possible.
With software, it’s likely that you have a long value chain. That is, you’ll be thinking about your target audience — what businesses? What professions? You may also need to consider the target audience of your target audience. Say, for instance, if you offer customer-facing software to businesses.
Technical communication clarity
So, what are the benefits of ditching the terms ‘users’ and ‘customers’ and pursuing technical communication clarity?
Having clear, distinct user labels makes it easier for software developers to recognise user differences. (I.e. ‘bank teller’, ‘pharmacist’, ‘customer support rep for a fashion brand’, etc.)
This translates to understanding the varying knowledge and experience that developers need to cater for. It also reminds developers of how their users will have a different understanding of the need for the software.
Technical communication clarity is also a stepping-stone to building empathy with your various ‘users’. With a better understanding of who the software will help, developers can look deeper into how it will help. It creates clarity about the needs, problems and emotions behind the use of the software.
Not to mention, clear technical communication means that teams spend less time and mental energy working out who each brief and user story is talking about.
Varied customers, varied labels
You aren’t generic. Your customers — and your customer’s customers — aren’t generic. So, why use generic labels?
Referring to your customers as non-descript ‘users’ removes reams of valuable information from your development, your planning, and your marketing. It’s too open to interpretation.
When it comes to technical communication, clarity is king.
Useful links
What is a user story and why should you be writing them?
