Since it came up in discussion at the recent London UX Bookclub where we were discussing Selling Usability: User Experience Infiltration Tactics by John S. Rhodes, I have been thinking about whether it would be useful to start calling myself a Customer Experience Consultant rather than a User Experience Consultant.

In the book, the author advocates using the term ‘customer’ rather than ‘user’ because your business colleagues will both understand & value a ‘customer’ more than a ‘user’. This is not really the reason that I would consider the change, though. It’s actually more about me and the kind of work I do.

The main reason that I would consider changing to a Customer Experience Consultant is because I’ve found that more and more the scope of ‘experience’ that I need to access and can have an impact on goes well beyond the website. Despite the fact that I have much more expertise in engagement with customers in digitally interactive environments, more and more the holistic experience that the customer has with the business I am designing for is relevant and important in the strategy, recommendations and ultimately design work that we do.

By defining myself as a ‘User Experience Consultant’ I am effectively signaling that my scope, interest and usefulness starts and ends at the digital border (however fuzzy that border may be becoming these days). I don’t think this does anyone any favours.

I’m also on the record as not being a huge fan of the term ‘user’, because there are so many more descriptive and humane alternatives. It would be a nice fringe benefit for me to get the word ‘user’ out of my job title.

Of course, there are downsides to this. ‘Customer’ is also a fairly limiting term, it implies consumer focus, it doesn’t allow for differentiation between the person who is ‘buying’ the product/service and the ultimate end user (who can sometimes be very different people!), and it is often too generic and not descriptive enough for companies we engage with, where ‘customers’ are called ‘members’, or ‘readers’, or ‘subscribers’ for example. (Were I working inhouse I could tailor my title to suit, but as a freelancer this is more challenging!).

Another downside of this change is that it creates yet another definition for us (the IA/UX/IxD and however else we already define ourselves) to argue over, it is another title for clients to learn, and it doesn’t give any clues around ‘usability’ which is still something that a lot of clients look for when they are really looking for user experience (but don’t yet know it exists).

I’m not really one for labouring over definitions of what we do, and I don’t think I’m going to go out and change my business cards tomorrow, but it’s something I’ll be mulling over for a while I think. My gut feel is that there is something important here, but also a bunch of problems. I’d be very interested to get your thoughts on this as well, included suggested alternatives.

Translations:
You can now read this post in Belorussian (thanks to Fatcow for the translation).

I use this study as an example with *so* many projects these days that I thought it might be useful to share the original source with you here. Schwartz is sharing the findings from a series of studies titled ‘When Choice is Demotivating’…

One study was set in a gourmet food store in an upscale community where, on weekends, the owners commonly set up sample tables of new items. When researchers set up a display featuring a line of exotic, high-quality james, customers who came by could taste samples, and they were given a coupon for a dollar off if they bought a jar.

In one condition of the study, 6 varieties of the jam were available for tasting. In another, 24 varieties were available. In either case, the entire set of 24 varieties was available for purchase.

The large array of jams attracted more people to the table than the small array, thought in both cases people tasted about the same amount of jams on average.

When it came to buying however, a huge difference became evident.

Thirty percent of the people exposed to the small array of jams actually bought a jar; only 3% of those exposed to the large array of jams did so

For the detailed answer(s) to ‘why is it so’ you should buy the book (and I strongly recommend it, as I said, I reference it *all* the time). For the short answer – people don’t do well with a lot of choice. Be a good designer and help them by guiding them towards good decisions, even if not the perfect one. A decision made can be remade and refined, which is much better than not seeing your customers for dust.

So, there we were, just starting to work through the workflow for Drupal – we got as far as the login screen when we thought ‘let’s write something nice on this screen’, and, pen poised… we were stumped.

We wanted to write something friendly like Moo would. Or Innocent drinks. We wanted to make it visually interesting like Vimeo do. Or Picnik. But… is that Drupal?

We realised we have no idea what Drupal’s personality is. And it would make our lives much easier, and help make a much better User Experience, if we can work out what it is.

Isn’t this completely touchy-feely and a waste of time?

Well no. One way or another, words will go on screens and a personality will emerge. Or, worse still, a few personalities, or a few dozen personalities. Much better that we spend a little time and give a little thought and see what we can come up with.

So, here’s where you come in:

The Personality Exercise:

Take a minute to v quickly answer the following five questions. Go with your gut reaction, don’t over think it. Try not to read everyone elses’ responses first. Don’t worry about being silly! (This is a kind of silly exercise after all, albeit useful)

• If Drupal was an animal, what would it be?
• If Drupal was a celebrity, who would it be?
• If Drupal was a car, what would it be?
• If Drupal was a profession/career what would it be?

So your answers might look something like this:

Drupal would be a squirrel/Paris Hilton/SS Commodore Ute/Teacher*

Get to it – what do you reckon?

*the opinions expressed above are not those of the author. Except for the SS Commodore one.

The redesign project for Drupal.org will be guided by an experience strategy that will inform our decision making in all aspects of the redesign and which will, we hope, be able to be used as ‘a star to sail our ship by’ (as Jesse James Garrett would say) – as a clear objective to design towards.

What is an experience strategy?

An experience strategy is a clearly articulated touchstone that influences all of the decisions made about technology, features, and interfaces. Whether in the initial design process or as the product develops, such a strategy guides the team and ensures that the customer’s perspective is maintained throughout.

- Subject to Change, Creating great products and services for an uncertain world, Merholz, Schauer, Verba & Wilkens (Adaptive Path) 2008

This is a good example of an experience strategy:

How it worked out for Google Calendar:

(hat tip to Peter Merholz for images)

Experience Strategy for Drupal.org (Work in Progress!)

• Drupal.org is for anyone who is interested in Drupal (not just developers!)
• Drupal.org will make building a site you’re proud of as painfree as possible (from deciding to use Drupal through design, development and deployment)
• Drupal.org is the home of the Drupal community.
• UPDATED: Drupal.org is the project management and release tool for the Drupal software (thanks Robert Douglass)
• Drupal.org will support people and companies from their initial experience of the product and community and as they continue to increase their knowledge and experience with Drupal and become more active in the Drupal community.
• Is a showcase for what can be done with Drupal

What we believe:

1. Drupal.org is as much (if not more) a social site than a content site
2. The Drupal Community is as important (if not more) than the Drupal Product
3. The Drupal product is a market leading CMS solution
4. The ‘end point’ (goal) is not getting more people to download Drupal, the end point is to get more people to have a Drupal site running that they love (with as little pain as possible)
5. Anyone can find out what they need to know about Drupal on or from Drupal.org
6. We must flatten the learning curve – anyone can learn as much as they want to learn about Drupal
7. Modules are easy to find and evaluate and are an obvious asset to Drupal
8. People can see/learn and align themselves with Drupal’s (and Open Source) values…
9. Drupal.org is a living organism and, with the help of the community, will continue to grow and improve.

How this plays out

Drupal.org has two equally important audiences – people who are new to Drupal and people who are already part of the community.

Drupal.org needs to inspire and educate people who are new to Drupal – the end goal being that they become active participants in the Drupal community who have a Drupal site (or sites!) up and running that they are proud of.

Note: getting people to ‘download’ Drupal is not the end point. If anything, it’s just the beginning.

Drupal.org also needs to be a comfortable and safe home for members of the Drupal community, wherein participants are both able to develop their own skills and experience (grow up), as well as help others on their developmental path (help grow others up).

Things we need to do:

• be nicer to ‘outsiders’ (non drupal, non developer)
• encourage people to engage with the community (starting by showing them that it exists!)
• work at flattening the learning curve
• get all the right content on the site and keeping it updated
• show the community in action (without ruining it)
• make things findable (IA)
• communicate drupal/opensource values
• help Drupal users kick ass

Getting past the brick wall

As one person I’ve interviewed described it: ‘I can get Drupal downloaded and installed and get an ugly blog that I don’t want, but then I hit a brick wall’ – Drupal.org’s job is to help people over that brick wall – to help them get the site they want using Drupal.

Helping Users Kick Ass

Bert Boerland pointed me to this great diagram that Dries posted a while back (inspired by Kathy Sierra) which I think really nails a big part of our strategy.

So, that’s what we’re thinking.

Over to you now. What do you think of this as an Experience Strategy for Drupal?
Questions? Comments? Suggestions?

(Remember, there are lots of ways you can point us to things you think are important for d.org)