Corvus Consulting

The annual cycle for Corvus Consulting seems to put me in front of new clients in the summer months. Even after seven years this kind of surprises me: isn’t this when people would take it easy on new work? From that it follows that it’s also the time of year where I find myself explaining what I do.

Two topics come up regularly in these conversations: why I call what I do “experience design” over “user experience design,” and the struggle for a succinct definition of just what experience design is.

The answers seem ripe for not one but two blog posts, and this is the first: why I shy from “user experience” (or user-anything for that matter).

For an industry often struggling to keep human needs and limits at the centre of it’s product-making processes, isn’t it strange that we so tightly cling to such a radically homogenizing term as “user”?

Someone once quipped to me that are are only two industries that refer to their customers as “users,” and the other one has a major PR problem. It might seem academic, but if you believe that the words we use matter because they are the shape of thinking and communication about interaction problems, then you likely agree that it’s worth trying to do better.

To that end I avoid the term user as much as possible. When laying out the audience for products I work on, I’m careful to find words that segment along lines of real-world behaviours, relationships and roles. Some examples

• Visitor or Guest to describe a non-registered person and Member for a registered person on a public-accessible website
• Manager, Supervisor and Customer to describe the people involved in a retail sales system.
• Agent and Traveller to delineate the people using a booking system.

Going User-Less

It takes extra research and thought up-front. It takes extra keystrokes to write these terms in every scenario, use case and diagram. It takes extra effort to recall and air to speak each different term. But the benefits outweigh the costs.

1. Scenarios and use cases become much more elegant.

Writing about who is doing what becomes much easier when we use words that naturally differentiate those people. In earlier days, I used to write use cases that identified actors and stakeholders by User 1, User 2, and so on. By replacing those with real-world terms drawn from the product’s domain, scenarios and use cases are more natural to both write and read.

2. Needs and constraints are kept in the forefront of the design process.
It’s hard to forget that customers are customers when we keep calling them customers, and the same goes for any role that people using technology might be playing in that use.

These words might be everyday vocabulary but they encode a lot of knowledge about the world; they unfold into relationships of power, responsibility, access and need that, in turn, inform the experiences we set out to design for them. Why should we exchange that rich knowledge for the generic and start from scratch each time?

It’s hard to move the needle on entrenched vocabularies, and it’s not like me to try and get a whole team to buy into changing the way they speak wholesale. But little by little, project by project, I try to make this way of thinking a new, more expressive and more humane norm of the design process.