Naming conventions /terminology for different types of users?

Question

Let's start with the most basic example:

an UX company creates a website for a client (user). The website will be ran by a staff (users). This staff is divided in admin/tech staff (users) and content creation (users). Of course, this website is aiming to be seen by as many users as possible.

As you can see, this is an incredibly common situation, just a website with some staffing has many different types of users, let alone complex system configurations.

At first, I thought about ROLES, which is related. But I quickly realized it doesn't cover all cases. Or in any case, a ROLE would be a subset of an user type.

So, my question is: is there a commonly accepted terminology for the different types of users in UX?

Answer 1

The language of use cases uses the term Actor and Cockburn describes them below (with more detail at the link).

An actor might be a person, a company or organization, a computer program, or a computer system—hardware, software, or both.

Having said that, traditional use cases (as in Cockburns 'Writing effective Use Cases') do tend to make for rather dry reading though, and speaking about Actors doesn't come naturally to me at least. So whenever I've needed to create formal use cases in this way, I also try to focus on the human actors and their goals. That's when I change the language to talk about Roles and Goals.

Roles and Goals don't only rhyme nicely - they do tell it how it is. A role is like a mindset. A single person may switch roles.

Considering roles let you chunk up the usage into manageable associated groups of tasks and actions. A 2D matrix of roles vs goals lets you spot common and unique patterns of behaviours.

A set of roles should in fact cover all cases, even if it means that your roles include internal things like developer, tester, qa, management, marketing etc.

If some cases aren't covered, then extend the set of roles. Start catering for the non-human Actors by additional roles, as necessary. For example, if some functionality is accessible via an API then introduce an external API developer or consumer role.

That a role is a subset of a user type is not a problem. You can group roles (e.g. in the 2D roles/goals matrix) under a broader user type, and still overlap roles across different user types.

Answer 2

An organisational ontology seems to define the different types of users as you specify them, and roles is one of the levels that the ontologies defined here specify:

http://www.epimorphics.com/web/wiki/organization-ontology-survey

In UX you may describe different types of users by doing some ethnographic research and describing them as personas, e.g. http://uxmastery.com/create-ux-personas/ but this is more of a way of capturing the essence of a user and understanding their needs rather than a classification of role.

Answer 3

OK, I thought this would be an easy to answer question, but it seems there's not a common terminology for this (time to make it????), so I'll try something that more than an answer should be taken as an introduction to an answer.

I think Roger Atrill's answer is very close, but still limited by the boundaries of specific environments, and not common to other people. Hence, the logical path to create such ontologies (thank you Jonny!) has to be explained every time, something common in Agile environments and the likes, but really cumbersome when you have lots of stakeholders in different locations.

So, my take on this is that there's clearly a group of users that can be qualified and even quantified, which is the group related to the production side. From here, it's easy to define roles and goals, just like Roger says. For the purposes of this answer, let's call this type the "builders group"

There could be an additional type added to the above group, which is the stakeholders that are more involved into the business side, including investors, marketers, administrative staff and such. This is clearly a type of its own, let's call it "financial group", which works and interacts with the builders

Then we have users that really have no involvement with the project, but interact with it in deep ways. For example: government, technology providers, tax office, market regulators, etc. Let's call this type the "external control group": they interact, they have influence, yet they're not part of the company, hence they have no defined roles.

Now, let's go with the user by antonomasia: the consumer, the one that pays the bills, the end user if you like . While some elements of this subset could belong to any of the types above at a certain point, we can say most elements of this group are NOT related to the organization. Hence, there's not a defined role (but there'll be goals for sure). In my simple case, this would be

someone that checks the website that the finance group financed, the builder group built and the external control group allowed.

For the purposes of this answer, let's simplify this type as "end user".

And now we could be happy, right? But.... there are different types of end users as well! Back to this simple example, one end user could be a member of the site, another could be someone that is looking for something specific coming from a SERP, therefore having a dual state until he engages (or not). Another one is just someone coming from hyperlinking, totally uninterested and which we could call a "bouncer". Someone could be doing a trial, someone could be paying, someone could be testing. Someone could be logged into the system, someone could be logged via social media. So more than goals, we're looking at levels of engagement that could include goals or not

And then, we have.... machine users! Spiders, crawlers, AI, scanners, bots and so on. Someone could say "ok, users are humans so machines are not users", which would make no sense every time we put some much effort to please or fight against these machines in order to make a project successful

Please note one thing: they all are present in the simplest example, so it's clear that we all talk about these groups and types in most projects, yet we have to define their names by their roles and goals, by their organizational title, by personas... And I would also add by their level of engagement or whether they're humans or machines.

In short, it seems there's not a general consensus for something that is at the core of any project (I did search for this answer and asked many UX professionals before asking here), which is particularly strange, specially on a discipline like UX that loves to create names for everything. I propose something along the lines of Influence Types, which could be measured in a relatively easy way, where goals, roles, engagement levels, etc are variables that will define the user more accurately (more or less a process like when in Agile you define points)

Answer 4

I would customize the names/terms to match your client's existing business hierarchy. But you'll also want to create a matrix of roles, functions, and authority levels.

First, basic roles and functions could include:

IT - web site maintenance, upgrades

Administrative - internal content only

Marketing - internal and external content

Sales - external content

Here, internal content might be accounting and HR information only seen in executive dashboards. While external content could include emails to clients and content that sales and marketing staff share across social media platforms.

Second, within each role-function level, you could have 3 authority levels:

Contributor - can add content or code, but cannot change what others add or publish anything

Editor - can contribute AND change what other contributors add but cannot publish

Publisher - can contribute, edit, and publish. This is the top authority level, the only person who can click the go-live button.

Third, from here you could have a 4x3 matrix and assign a name for each role/function-authority classification.

Ex. IT Contributor, IT Editor, IT Publisher... Marketing Contributor, Marketing Editor, Marketing Publisher... OR you might only have one Sales-Marketing Publisher, Admin Publisher, etc.

Again, adapt the terms to match the client's position titles. You might also need sub-roles depending on the client's business and marketing model.

Answer 5

The most common terminologies that I* have seen in use in software user interfaces you already mentioned in the question: user types and user roles.

As of today, each one has 8.3 an 5.5 billions search results respectively and their interest over time stat seems pretty balanced world-wide.

I've only used actors at software development phases – meaning I've never seen it explicitly represented on the GUI.

* about me