User adoption and the psychology of names

http://www.flickr.com/photos/rodrigobertolino

"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?

Advertisements

Does your IT salary depend on what makes you different?

"Rational people" think at the margin...

It’s Monday, and that means I take another crack at an economic principle and apply it to software development and IT. (Here is a link to the series so far.)

This week we are on principle #3 which goes something like this:

Rational people think at the margin.

I am going to put aside questions about whether (or which) people are “rational”, or whether I would be qualified to make the assessment in the first place.

Instead, I want to focus on the “margin”. (Perhaps that makes me “rational”, after all.)

In this context, the “margin” relates to an economics principle called “Marginal Utility“.

A summary of the concept (for our purposes, anyway) is that people will value two otherwise equivalent items against each other based on their “marginal” (or incremental) differences, positive or negative.

So we might pay more for one car based on its gas mileage or on its performance characteristics, all other attributes being pretty much the same.

Fundamentally, the market of buyers and sellers converges on a certain price at which a commodity might be bought or sold.

As long as a surplus of buyers or a shortage of supply exists, prices may rise… and the converse also holds.

Designing for marginal utility

Now, if a company wants to sell its products at a premium, you may have heard that it needs to “differentiate” them in the market.

More specifically, the company needs to name, find or design a marginal utility for its offers… an incremental change that drives a disproportionate increase in assessments of value (price).

Don't quit your day job!

My business teacher, Toby, used an analogy like this (the following numbers are illustrative only, and may not be accurate):

  • A “good” college basketball player, scoring 26 points per game, has no chance of becoming a professional…
  • A “great” player, routinely scoring 30 points per game, might get drafted at a league minimum salary…

While…

  • The “elite” player who always scores 34+ points per game might get a starting salary ten times higher (not to mention endorsement deals and other additions to income)

Looking at it that way, you could say that the difference between getting into the pros and not is 2 baskets per game.

You could also say that the elite player gets 90% of their income from the extra 2 baskets they make every game.

Bringing the topic back to IT

Since I thought it would be good to set up what marginal utility is and offer an illustration, it seems to me that we can spend a couple of weeks on this subject. We can speak about designing marginal utility at the individual, team and organizational levels.

So while we have the notion of salaries fresh in our minds, let’s start with you and me, shall we?

First, let me make my intentions really clear: I accept that people say money isn’t everything. People don’t have to slave and toil to get paid more. There is nothing morally ‘right’ or ‘wrong’ about wanting higher pay or not.

Remember that the topic is marginal utility in the domains of software and IT. So I am just speaking of the topic about how much we get paid. That’s all – I have no judgments and am not making any recommendations – “I’m just sayin’.”

I have nothing particularly witty to write this time - this is a piggy bank on a pile of money.

In the basketball analogy, good players don’t become professionals. There is nothing wrong with them – they’re good… just not valued highly enough to get in at that level of competition.

In my career, most of the IT people I’ve met are good.

They get paid what the market bears for their roles, which our industry declares clearly and consistently in job descriptions from one company to the next.

A Java developer is a Java developer, and they make a certain amount of money. They make a little more as a consultant, generally speaking.

A “senior” Java developer wants to get paid more, but the standard for assessing what “senior” means is not well established.

And don’t get me started on what an “architect” really is in all its various derivations… except they also expect to get paid more, and have higher expectations to live up to.

The point is: as long as what defines your capabilities and accomplishments is the same as everyone else, the market sets your rate pretty clearly.

In this situation, your income fluctuates with the market, and you are a commodity, in a sense. A business may see you as replaceable, you may struggle to find your next role and you may feel trapped in roles, feeling underpaid and undervalued.

On the other hand, when you find those strengths that you bring to bear – those things that makes you incrementally more valuable than someone else in your role – that could be marginal utility (your “2 baskets more“) for which you compel other to pay a premium.

Just be careful in thinking that what you value about yourself is what they value, and that you deliver enough that they will feel your premium is worth it.