User adoption and the psychology of names

"The Name" is the name of this Brazilian group, but we couldn't use that for the portal

There’s no clever title today, just a clever first sentence.

Let me dive into this topic with some background. I’m helping a company with an internal portal strategy, and one of our concerns relates to user adoption.

My concerns aren’t only about functionality. They aren’t just about usability. I also have a concern for naming.

You see, this global company has a lot of paper forms, a lot of email, and many subsidiaries acquired over the last decade. Each of these matters to me when I think of how users might feel about this new portal.

We have learned, reflexive and instinctive behaviors, though I suppose you might argue that reflexive and instinctive are either the same or related.

Regardless, adopting new behaviors is costly (in terms of time, energy, money and other opportunities).

Looking deeper into my concerns

So here are just a few of the reasons I care about those factors:

1. Paper forms – moving to a web-based solution requires changing long-established human behaviors
2. A lot of email – what electronic communication exists is largely unstructured and long-established as well
3. Acquired companies – each business unit asserts they do things differently, and we have a lot of overlapping terminology

So in the first case we want people to use an online work order and not paper.

In the second case we want users to share conversations and upload attachments to the online work order and not pass them around in email or create lots of versions on file servers…

…and in the third case it would be great just for everyone to agree what a “work order” is!

It is this third concept I want to talk about today.

Two options, two paths?

Maybe THIS is the inner working of my Archimedles?

On the surface, we have two options: 1) we call a work order a “work order”, or 2) we call it some other thing (the term “Archimedles” [not “Archimedes”] comes to mind if you’ve read my posts closely for long).

Now, I’m speaking of a “work order” because it’s a simple concept of an artifact. I could have chosen a PO, an invoice or some other artifact. In this company’s industry, there are some commonly used documents that aren’t so universal, but end up producing a similar naming crisis anyway.

If we choose to preserve the standard name, we benefit from its history in everyday use, but we sign up for “standardizing” what people think a “work order” is. Establishing standards is expensive, though often worth it, but sometimes results in mis-communication or even minor rebellion for a time.

If we figure out a different name, even a new name, we can’t lean on the history of usefulness people already associate with the concept of a work order… but among other things we change the kind of learning processes our users go through as they work with the new portal.

We are “triggered” psychologically to notice what is different

When people see something as “new” or “different” from what they know, they attempt to figure it out in terms of something familiar, e.g., saying Google+ is “just like Facebook”. Meanwhile, they also invest some time and energy trying to learn it.

By calling something by a new name, we open the possibility for our users that what they are looking at actually isn’t what they already know, that perhaps it has some marginal utility. We can spark curiosity and wonder, and we can engage them in new and different ways.

After all, Google+ might be to Facebook what the iPhone is to the bag phone Michael Douglas carried in “Wall Street”. (Time will tell.)

Meanwhile, if we change the words we use, but our users end up feeling like it really IS just a new spin on the old work order, they could be dissatisfied and rebel against the change there, too. When we claim something is new, we make a promise… which sets up the possibility for building trust, and produces an obligation in us to deliver on the marginal utility we imply or outright promise.

A work order really IS a work order, though

Unfortunately, it often seems like we’ve used all the good names already. So we really can’t change the name of something as common as an invoice, PO or even work order. In this case, I used them mainly to illustrate the place we are in and some alternatives.

Naming is an important part of the design and rollout strategy for this portal initiative. Since we can’t take one approach or the other, we are left with a hybrid, keeping some names and adopting new ones… even inventing some where new metaphors for interaction seem proper.

Where have you considered using new names for innovative changes you develop? Has your product really been different or new? What did you notice in the form of user responses and adoption?

Team players and MVPs

Team players (yes, these two are mine...)

What are the qualities you look for in a “team player”? Respect? Experience? Competence? Levelheadedness? A great personality?

When I hear people use the phrase, I confess I don’t know what they really mean. That is, I know it is a common phrase, but I wonder if people give the jargon any thought.

Sometimes it seems people use the words when they really just wants someone else to change… as in “he/she is not a very good team player”. Yet they offer no (or little) direction on precisely how to become one.

Have you ever met a “team player” you didn’t like to work with? Have you ever seen the term “team player” used in quotes, besides in this post? Ever?

Putting the jargon aside, who do you want on your teams?

Standardization, commonality and best practices

Every project includes some fundamental tasks. Sometimes they are repeatable, even mechanical, and you can train people to do them. You can often anticipate contingencies, and you can teach people to recognize them and act appropriately when they arise.

To that extent, you can train people and substitute them into teams as backups or replacements. So we cross-train on each others’ jobs to provide backup for people to go on vacations. We define standard practices and “best practices” and teach them to people to drop our costs of repeating the same tasks over and again.

Now, the last thing we need is somebody on the team who messes up our routines every day. The person who habitually “breaks the build” or who fails to write unit tests forces his teammates to bear added costs to keep everything running smoothly, until eventually we start to wonder how we can get those people off our team.

So the factors that help us work together in standard practices are one thing that makes us good “team players”.

But that is not the end of the story…

Marginal utility in the team

Not everybody takes the tiller

This post is the fourth in the principles of economics in software development series. We are pausing for a time on the third of Greg Mankiw’s principles, which says “rational people think at the margin“.

Last week I wrote about the implications of this principle on the value of our work (and our salaries). As an illustration, I suggested the difference between the professional basketball player’s income and the amateur’s income might come down to four extra baskets per game.

They’re paid all the extra money because of the incremental points they score.

Now, nobody asked them to score those points in high school or college. Nobody forced them to practice. Nobody read their job description to them.

They did the work. They built their abilities. They found ways to produce value for their teams… and they earned their rewards.

For that, they were not easily replaced. For that, they could compel a little VIP status. For that, they sometimes got out of hand, acted like prima donnas and started producing high costs for their employers (and themselves).

Thinking at the margin doesn’t discriminate

So while there are marginal utilities, which produce marginal value… there are also marginal costs.

“Rational people think at the margin” means nobody worries about what is the same. All “team players” who follow standard practices and never step out of line, but never produce incremental value over their coworkers may feel “safe”… whatever that means to them. But they can never be valued any more than what is commonplace (…and there is nothing wrong with that).

Hire this guy? The most interesting guy in the world...

On the other hand, rational people evaluate the costs associated with picking up those few extra points in a basketball game… with adding that expert to their team, along with any eccentricities they bring. The person who has that unique knowledge of a technology or who can make the database “sing”, but who may not perfectly fit in some other way, might be just what is missing.

They evaluate whether it’s “worth it” – worth the costs in terms of time, energy, money and lost opportunities. And then they willingly make investments to get access to all the difference in the world, if it will help them achieve their tactical, strategic or ultimate objectives.

So let me ask again… who do you want on your teams?