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?

Building trust with your customer

Trust means we can depend on future action

It is common to speak of building trust within a project team.

We debate ways to build trust, how we break trust and to what extent this “trust notion” is important anyway.

I have written about trust building with regard to noticing the implicit promises we make each other, and how very “real” they are to us in terms of consequences even though we don’t know they exist.

I know some cynics who say that trust does not exist… but I also accept that is how a true cynic might see it, and I move on.

So in this post, I want to talk about the trust we build with our customers… something relevant to every technology leader. (Actually, the core reference for my post above had to do, in part, with a marketer’s perspective of software developers.)

Revisiting components of trust

I have introduced a distinction for trust as:

An assessment of sincerity, reliability and competence to hold our promises for long horizons of time

You might use a different distinction, but I offer this one as the basis for the rest of this post. It is a standard distinction produced and taught by The Aji Network, which you know if you follow me is an educational discourse of business professionals with whom I have learned and grown professionally.

Actually, when I say “long horizons of time”, it is more specific to say “as long as needed”. If you trust me with a promise not to tell about a surprise birthday party… I am off the hook for that promise after the event.

So what is our task?

You can't keep any promises you don't make

Given that distinction for trust, we only build trust with our customers when they assess we are:

  1. Sincere – we mean what we say
  2. Reliable – we recurrently do what we say
  3. Competent – we’re not claiming a skill we don’t have

AND… we have to hold our promises [for as long as needed].

The thing is, if we don’t make any promises, we can’t build trust.

Now, I’ve heard some people adopt this as an intentional strategy – if we don’t make promises, they can’t distrust us. Actually, the opposite is true — if we don’t make promises, our customers WILL grow to trust us — to NOT take care of them.

We can’t hide demand by ignoring it exists (or saying “no” to everything), and we can’t build trust by saying “yes” and failing to deliver. So what is left for us to do?

The natural human planning cycle: 90 days

Here are two examples from domains outside software projects:

These books have at least one thing in common – they both refer to the human psychological implications of 90 days as a powerful window for planning.

Things change a lot in our business lives, and in the business lives of our customers. That is one reason we gravitate toward agile, or at least to short-cycle projects. Here we have two examples of other domains that suggest a familiar theme – give yourself space for feedback and time to adapt… and don’t pretend to know everything.

So let me offer this natural human planning cycle as consistent with a powerful move to build trust with our customers. Don’t delay a release unless something drastic has happened. Communicate clearly and confidently about what will be “in” the release, but don’t miss the ship date.

Over time, your capacity to recurrently hit ship dates (reliability), with solid features (competence) as you have said you would (sincerity), you create the opening to change the moods and attitudes of customers who might have great reasons not to trust due to historical patterns.

One strategic purpose for building trust with customers

There are many reasons to build trust with customers, but I will leave that to another post.

Today, I just want to link back to a past article I wrote about the role of project managers to hold customers to their end of the bargain – that they take receipt of our products. Not every team has this problem because they have their customers’ trust.

Some teams don’t have the problem because they have psychologically strong coaches who can force acceptance on their customers regardless of trust. (I haven’t directly observed this, but I leave open the possibility that it might exist.)

For the rest of us, not having your customer’s trust means they may become over-demanding, asking for more because they know they won’t get it all. They may get beaten down and stop asking for your help. Or I don’t know if this is worse, but they may take their budgets and look elsewhere for help.

They are not “wrong” in acting that way… but you can get ahead of them by investing in building their trust. Find promises you CAN make, if you can’t do everything. (Who can?)

…and deliver on those promises, consistently, competently, sincerely and recurrently… for as long as needed.