Categories
Learn

Top-10 Application-Design Mistakes

It’s hard to write a general article about application design mistakes because the very worst mistakes are domain-specific and idiosyncratic. Usually, applications fail because they (a) solve the wrong problem, (b) have the wrong features for the right problem, or (c) make the right features too complicated for users to understand.

Any of these three mistakes will doom your app, and yet I still can’t
tell you what to do. What’s the right problem? What are the right
features? What complicating curlicues can safely be cut from those
features? For each domain and user category, these questions have
specific and very different answers.

The only generalizable advice is this: rather than rely on your own best guesses, base your decisions on user research:

  • Conduct field studies and task analysis before deciding what your app should do.
  • Paper prototype
    your initial ideas before doing any detailed design — and
    definitely before wasting resources implementing something you’d have
    to change as soon as you get user feedback.
  • Design iteratively, conducting many rounds of quick user testing as you refine your features.

Of course, people don’t want to hear me say that they need to test
their UI. And they definitely don’t want to hear that they have to
actually move their precious butts to a customer location to watch real
people do the work the application is supposed to support.

The general idea seems to be that real programmers can’t be let out
of their cages. My view is just the opposite: no one should be allowed
to work on an application unless they’ve spent a day observing a few
end users.

(Whatever you do, at least promise me this: Don’t just
implement feature requests from “user representatives” or “business
analysts.” The most common way to get usability wrong is to listen to what users say rather than actually watching what they do. Requirement specifications are always wrong. You must prototype the requirements quickly and show users something concrete to find out what they really need.)

All that said, there are still plenty of general guidelines for
application UIs — so many, in fact, that we have a hard time
cramming the most important into our two-day course.
Here’s my list of 10 usability violations that are both particularly
egregious and often seen in a wide variety of applications.

1. Non-Standard GUI Controls

Basic GUI widgets — command links and buttons, radio buttons and checkboxes, scrollbars, close boxes, and so on — are the lexical units that form dialog design’s vocabulary.
If you change the appearance or behavior of these units, it’s like
suddenly injecting foreign words into a natural-language communication.
Det vil gøre læserne forvirrede (or, to revert to English:
Doing so will confuse readers).

For some reason, homemade design’s most common victims are scrollbars. For years, we’ve encountered non-standard scrollbars in our studies, and they almost always cause users to overlook some of their options. We’re seeing this again this year, in the studies we’re conducting to update our course on Fundamental Guidelines for Web Usability. (The linked article includes screenshots of offending scroll controls.)

Some of the world’s best interaction designers have refined the
standard look-and-feel of GUI controls over 30 years, supported by
thousands of user-testing hours. It’s unlikely that you’ll invent a
better button over the weekend.

But even if your homemade design, seen in isolation, were hypothetically better than the standard, it’s never seen in isolation in the real world. Your dialog controls will be used by people with years of experience operating standard GUIs.

If Jakob’s Law is “users spend most of their time on other websites,” then Jakob’s Second Law
is even more critical: “Users have several thousand times more
experience with standard GUI controls than with any individual new
design.”

Users will most likely fail if you deviate from expectations on
something as basic as the controls to operate a UI. And, even if they
don’t fail, they’ll expend substantial brainpower trying to operate
something that shouldn’t require a second thought. Users’ cognitive
resources are better spent understanding how your application’s
features can help them achieve their goals.

1.a. Looking Like a GUI Control Without Being One

The
opposite problem — having something that looks like a GUI control
when it isn’t one — can reduce usability even more. We often see
text and headlines that look like links (by being colored or underlined,
for example) but aren’t clickable. When users click these look-alikes
and nothing happens, they think the site is broken. (So please comply
with guidelines for visualizing links.)

A similar problem occurs when something looks like a button but doesn’t initiate an action, or looks like a radio button but isn’t a choice. We found an example of this in our current round of studies.

To design a custom-tailored shirt on Liste Rouge Paris, you must
provide your measurements. As the following screenshot shows, there are
two different paths through the application here, depending on whether
your measurements are already on file with the tailor.

Partial screenshot of ordering process for custom-tailored shirts at www.listerouge-paris.com

Our test user clicked incessantly on the New Customer
button to indicate that he was indeed a new customer. Unfortunately,
this screen element was not a button at all, but rather a non-clickable
heading.

He was the only user to test this site because he encountered
it during a task in which users could choose a site to visit (usually
from a search listing). In this case, the user eventually overcame the
confusion and proceeded to enter his measurements. If we had tested
more users, a small percentage would have likely failed at this point.
Each small error in dialog design reduces usage only by a small amount,
but most UIs contain bundles of errors, and the number of lost customers adds up.

As an aside, this screen also uses radio buttons incorrectly. In
theory, all five choices are mutually exclusive, which does call for
radio buttons. But in the user’s mental model of the workflow, there
are actually two issues
here: (a) new vs. old customers, and (b) how to provide the
measurements for your situation. You should use a single set of radio
buttons only when users will choose between options for a single issue.

So, in the case above, a better design would first ask users to
decide the new/existing customer question, and then reveal the relevant
radio buttons for the option they choose.

2. Inconsistency

Non-standard GUI controls are a special case of the general problem of inconsistent design.

Confusion results when applications use different words or commands
for the same thing, or when they use the same word for multiple
concepts in different parts of the application. Similarly, users are
confused when things move around, violating display inertia.

Using the same name for the same thing in the same place makes things easy.

Remember the double-D rule: differences are difficult.

Another example from our current study: Expedia pops up a two-month
calendar view when users specify the departure or return date for a
trip. The composite screenshot below was taken in February and shows
what happens when you want to book a trip that starts on March 10 and
ends on March 15.

Two screenshots of date-selection widget (calendar) at Expedia.com

In the second pop-up, the month of March has moved to the left,
leaving room for April to appear on the right. This may seem like a
convenient shortcut, since there’s no way the user would want a
February return date when traveling out in March.

In reality, however, the user is looking for March 15 in the
same spot where it appeared in the first pop-up calendar: in the
right-most column.

In our testing, the inconsistent placement of the months in the
second pop-up caused confusion and delays, but users ultimately figured
it out. We tested only a few users with this site, but if you observe
this kind of almost-miss error in user testing, it’s usually a sign that a few users will make the mistake for real during actual use.

Booking the wrong return date can have disastrous consequences —
customers could arrive at the airport without a ticket for their
expected flight. If a site has good confirmation emails,
users might discover the problem before departure, but even that will
cause aggravation and expensive customer support calls to resolve the
situation.

Even if people eventually use the calendar correctly, it takes more time to ponder the inconsistent design than the time users save by not having to click the next-month button for April departures.

The shortcut that moves the months around saves time only for
very frequent users who learn how to efficiently operate this part of
the UI. So, an application for professional travel agents should
probably use Expedia’s calendar design. A site targeting average
consumers should not.

3. No Perceived Affordance

“Affordance” means what you can do to an object. For example, a
checkbox affords turning on and off, and a slider affords moving up or
down. “Perceived affordances” are actions you understand just by looking
at the object, before you start using it (or feeling it, if it’s a
physical device rather than an on-screen UI element). All of this is
discussed in Don Norman’s book The Design of Everyday Things.

Perceived affordances are especially important in UI design,
because all screen pixels afford clicking — even though nothing
usually happens if you click. There are so many visible things on a
computer screen that users don’t have time for a mine sweeping game, clicking around hoping to find something actionable. (Exception: small children sometimes like to explore screens by clicking around.)

Drag-and-drop designs are often the worst offenders
when it’s not apparent that something can be dragged or where something
can be dropped. (Or what will happen if you do drag or drop.) In
contrast, simple checkboxes and command buttons usually make it
painfully obvious what you can click.

Common symptoms of the lack of perceived affordances are:

  • Users say, “What do I do here?”
  • Users don’t go near a feature that would help them.
  • A profusion of screen text tries to overcome these two
    problems. (Even worse are verbose, multi-stage instructions that
    disappear after you perform the first of several actions.)

When I tested some of the first Macintosh applications in
the mid-1980s, users were often stumped by the empty screen that
appeared when they launched, say, MacWrite. What do I do here,
indeed. The first step was supposed to be to create a new document, but
that command was not shown anywhere in the otherwise highly visible
Macintosh UI unless you happened to pull down the File menu.
Later application releases opened up with a blank document on the
screen, complete with an inviting, blinking insertion point that
provided the perceived affordance for “start typing.”

3.a. Tiny Click Targets

An associated problem here is click
targets that are so small that users miss and click outside the active
area. Even if they originally perceived the associated affordance
correctly, users often change their mind and start believing that
something isn’t actionable because they think they clicked it and
nothing happened.

(Small click zones are a particular problem for old users and users with motor skill disabilities.)

4. No Feedback

One of the most basic guidelines for improving a dialog’s usability is to provide feedback:

  • Show users the system’s current state.
  • Tell users how their commands have been interpreted.
  • Tell users what’s happening.

Sites that keep quiet leave users guessing. Often, they guess wrong.

(For an example of the problems with poor feedback, see the screenshot of VW’s car configurator toward the bottom of my recent article reporting on our current round of testing: Because users couldn’t tell which tire was selected, they had trouble designing their preferred car.)

4.a. Out to Lunch Without a Progress Indicator

A variant on
lack of feedback is when a system fails to notify users that it’s
taking a long time to complete an action. Users often think that the
application is broken, or they start clicking on new actions.

If you can’t meet the recommended response time limits, say so, and keep users informed about what’s going on:

  • If a command takes more than 1 second, show the “busy” cursor. This tells users to hold their horses and not click on anything else until the normal cursor returns.
  • If a command takes more than 10 seconds, put up an explicit progress bar, preferably as a percent-done indicator (unless you truly can’t predict how much work is left until the operation is done).

5. Bad Error Messages

Error messages are a special form of feedback: they tell users that something has gone wrong. We’ve known the guidelines for error messages for almost 30 years, and yet many applications still violate them.

The most common guideline violation is when an error message simply says something is wrong, without explaining why and how the user can fix the problem. Such messages leave users stranded.

Informative error messages not only help users fix their current problems, they can also serve as a teachable moment.
Typically, users won’t invest time in reading and learning about
features, but they will spend the time to understand an error situation
if you explain it clearly, because they want to overcome the error.

On the Web, there’s a second common problem with error
messages: people overlook them on most Web pages because they’re buried
in masses of junk. Obviously, having simpler pages is one way to
alleviate this problem, but it’s also necessary to make error messages more prominent in Web-based UIs.

6. Asking for the Same Info Twice

Users shouldn’t have to enter the same information more than once.
After all, computers are pretty good at remembering data. The only
reason users have to repeat themselves is because programmers get lazy
and don’t transfer the answers from one part of the app to another.

7. No Default Values

Defaults help users in many ways. Most importantly, defaults can:

  • speed up the interaction by freeing users from having to specify a value if the default is acceptable;
  • teach, by example, the type of answer that is appropriate for the question; and
  • direct novice users toward a safe or common outcome, by letting them accept the default if they don’t know what else to do.

Because I used Liste Rouge Paris as a bad example under
Mistake #1a, I thought I’d play nice and use them as a good example
here. The tailor offers 15 different collar styles (among many other
options) for people ordering custom-designed shirts. Luckily, they also
provide good defaults for each of the many choices. In testing, this
proved helpful to our first-time user, because the defaults steered him
toward the most common or appropriate options when he didn’t have a
particular preference.

Partial screenshot of customization screen in the shirt design application on www.listerouge-paris.com

Dialog to specify your shirt’s collar on www.listerouge-paris.com (3 of 15 styles shown).

8. Dumping Users into the App

Most Web-based applications are ephemeral applications
that users encounter as a by-product of their surfing. Even if users
deliberately seek out a new app, they often approach it without a conceptual model
of how it works. People don’t know the workflow or the steps, they
don’t know the expected outcome, and they don’t know the basic concepts
that they’ll be manipulating.

For traditional applications, this is less of a problem. Even if
someone has never used PowerPoint, they’ve probably seen a slide
presentation. Thus, a new PowerPoint user will typically have at least
a bare-bones understanding of the application before double-clicking
the icon for the first time.

For mission-critical applications, you can often assume that
most users have tried the app many times before. You can also often
assume that new users will get some training before seeing the UI on
their own. At the minimum, they’ll usually have nearby colleagues who
can give them a few pointers on the basics. And a good boss will give
new hires some background info as to why they’re being asked to use the application and what they’re supposed to accomplish with it.

Sadly, none of these aides to understanding apply for most Web-based applications. They don’t even apply for many ephemeral intranet applications.

Usability suffers when users are dumped directly into an application’s
guts without any set-up to give them an idea of what’s going to happen.
Unfortunately, most users won’t read
a lot of upfront instructions, so you might have to offer them in a
short bulleted list or through a single image that lets them grok the
application’s main point in one view.

As an example, our test user who was trying to order a
custom-tailored shirt was highly confused when the first screen in
Hamilton Shirts’ “Create Your Shirt” process displayed a fully designed
shirt with an “Add to Bag” button. This screen mixed two metaphors: a
configurator and an e-commerce product screen.

Screenshot of the upper part of the screen for the first step of Hamilton's shirt-design application

This is a case where a default value isn’t helpful: people who want
to design their own shirt are unlikely to want to buy a pre-designed
shirt on the first screen.

(This screen also suffers from Mistake #1: non-standard GUI
controls. In addition to its non-standard drop-down selection menus in
a tabbed dialog that doesn’t look enough like tabs,
the screen has a non-standard way of paging through additional fabric
swatches. Users are less likely to understand how to select fabrics
when the controls are presented in this manner.)

Our test user never understood the process of designing his own shirt on this site and ultimately took his business elsewhere.

9. Not Indicating How Info Will Be Used

The worst instance
of forcing users through a workflow without making the outcome clear is
worth singling out as a separate mistake: Asking users to enter
information without telling them what you’ll use it for.

A classic example is the “nickname” field in the registration
process for a bulletin board application. Many users don’t realize the
nickname will be used to identify them in their postings for the rest
of eternity — so they often enter something inappropriate.

As another example, we once tested an e-commerce site that
smacked users with a demand for their ZIP code before they could view
product pages. This was a big turn-off and many users left the site due
to privacy concerns. People hate snoopy sites. An alternative design
worked much better: It explained that the site needed to know the
user’s location so it could state shipping charges for the very heavy
products in question.

10. System-Centric Features

Too many applications expose
their dirty laundry, offering features that reflect the system’s
internal view of the data rather than users’ understanding of the
problem space.

In our current study, one user wanted to reallocate her retirement
savings among various investments offered by her company’s plan (for
example, to invest more in bonds and less in stocks). She thought she
did this correctly, but in fact she had changed only the allocation of future additions to her retirement account. Her existing investments remained unchanged.

As far as the mutual funds company is concerned, new investments and
current investments are treated differently. Reallocating future
additions means changing the funds they’ll buy when the employer
transfers money into the account. Reallocating current investments
means selling some of the holdings in existing mutual funds and using
the proceeds to buy into other funds.

The key insights here?

  • Our test user didn’t have this distinction between new and old
    money; she simply wanted her retirement savings allocated according to
    her revised investment strategy.
  • Even users who understand the distinction between new and old
    money might prefer to treat their retirement savings as a single unit
    rather than make separate decisions (and issue separate commands) for
    the new and old money.

It would probably be better to offer a prominent feature for changing the entire account’s allocation, and use progressive disclosure to reveal expert settings for users who want to make the more detailed distinction between the two classes of money.

Bonus Mistake: Reset Button on Web Forms

This mistake relates to Web forms, but because so many applications are rich in forms, I’ll mention it here: It’s almost always wrong to have a Reset button on a Web form.

The reset button clears the user’s entire input and returns the form
to its pristine state. Users would want that only if they’re repeatedly
completing the same form with completely different data, which almost
never happens on websites. (Call center operators are a different
matter.)

Making it easy for users to destroy their work in a single click
violates one of the most basic usability principles, which is to
respect and protect the user’s work at almost any cost. (That’s why you
need confirmation dialogs for the most destructive actions.)

http://www.useit.com/alertbox/application-mistakes.html

Powered by ScribeFire.

Categories
Learn

EXPLORATION OF CULTURAL DIFFERENCES IN CONSUMER SEGMENTATION

We’ve known for (Internet) ages that there are basically early
adopters, cautious lurkers and nay-sayers. The interesting part of the
study is how these groups distribute within the three countries that
they studied: Germany, France, and the US.

Most of the open-minded shoppers (45%) were from the US. In contrast,
most of the risk-averse doubters are French (66%). Germans are very
open to online shopping, but tend toward using the Web for research and
comparison. The relative distribution of the three types of Internet
shoppers within each country is shown in a graph on our site:
http://www.humanfactors.com/downloads/feb08.asp

Little facts like this always make great conversation starters. But
they also provide critical input for designers creating multi-national
e-commerce sites. The design elements that elicit trust for the typical
open-minded American Internet shopper will not be the right ones to
engage and persuade a French consumer. One site does not fit all.

Powered by ScribeFire.

Categories
Learn

YOUR WEBSITE: JUST WORDS?

Words are the building blocks of every website. But then, words
are the building blocks of modern civilization.

Presidential candidate, Barack Obama, was recently accused of
being all words and no action, of being lots of rhetoric and
little substance. Here’s how he replied:

“Don’t tell me words don’t matter. ‘I have a dream.’ Just words?
‘We hold these truths to be self-evident, that all men are
created equal.’ Just words? ‘We have nothing to fear but fear
itself’ -just words? Just speeches?’ (Obama plagiarized his
friend, Deval Patrick, for these lines, but that’s not the topic
of this piece.)


Words matter. They always have. They always will. On the Web,


words matter even more. The right words.

The problem is that there are lots and lots of words. For your
website, there are a small set of words that really matter, and
then there are an awful lot of words that don’t.

How do you judge if a particular word matters or not? You don’t.
It’s not for you to judge. It’s for your customers to judge.
Customers are highly impatient. They search and scan a page
quickly, looking for their right words.

You might want to communicate about “climate change”, but if
customers are searching for “global warming”, you’re out of
luck. You may have “tight” jeans for sale but if customers
prefer “skinny” jeans, you’re out of luck. You might have great
“low fares” but if customers want “cheap flights”, you’re out of
luck.

If you want to design a new website, the first thing you should
decide on is the words. Not the graphical design, not the
software. No. The words must come first. Once you get the words
right, you are half-way there.

But the words don’t come first, do they? Most websites are
driven from a technical or graphical design perspective. The
words are hardly even considered. The people who wrote the words
were brought in late on in the process and asked to fill in an
already agreed-upon structure and design with some words.

Words are simply not respected. Does it really matter if it’s:
“Buy” or “Buy Now”
“More information” or “Request a demo”
“Find a dealer” or “Buy: shop locator”
“Login” or “Logon”
“Fleet” or “Vehicles”

It does. It really does matter. It matters hugely. It matters
enormously. I have seen situations where sales have been doubled
by changing a couple of words. (Nothing else on the website was
changed.)

In most web teams people who work with words get very little
respect. But if you work with words, you are literally sitting
on a goldmine. The problem is you are selling it like a
coalmine.

Most web writers think that their job is about writing articles.
But it must be much broader and deeper than that. What is the

navigation of the website made up of? Words. What are the links


on the website made up of? Words. What are the applications on


the website made up of? Words.

Nothing can work on the Web without written words. No page. No
link. No classification, navigation or menu. No application or
software. Nothing.

www.gerrymcgovern.com

Categories
Learn

Top 10 Twitter Hacks

With Twitter gaining momentum everywhere from on the field to in the classroom, I thought some tips might prove helpful.

Call it link bait, call it hypocritical, just don’t call it a comeback.

1) Be a Good Twitter Citizen
If you have a
primary ID, name or handle that you use for email or social networks,
use the same one on Twitter so you’ll be easily recognized. And
in your profile be sure to link back to your Web site, blog or socnet
page so folks know who’s following them. The more context you can
provide the better – especially if you’re like me and
don’t update every single day.

And remember that, while it offers the immediacy of SMS texting, Twitter offers the permanence of blogging. What you say on Twitter stays on Twitter.

2) Send Direct Messages Faster
Sending private
messages directly from Twitter’s web interface can be a pain if
you have to scroll through a long list of mutual followers. Pressing
the first letter of the person’s ID while you are in the DM
dropdown allows you to page through names quickly and easily. If you
want to spam, er, DM a group of people at once, check out Twitter Groups.
Just use it sparingly as we all know how it feels when to get too many
group messages. For folks using Twitter via IM, there are even more
helpful commands.

3) Twitter Karma
The simplicity of Twitter’s interface can sometimes be its curse. To figure out who’s following whom, check out Twitter Karma. Twitter Karma makes it easy to see your overall follow status and add folks as desired.

4) Gauge Topic Traction
Want to see if the Twitter community is chatting up or linking to a certain topic? You should check out any combination of Twitterverse, Twitterbuzz, Twitstat, and/or Tweetscan.

5) Visualize, Data Mine
There are a couple of ways to quickly visualize your Twitter information. Twitter Blocks allows you to visually navigate your Twitter community of friends and followers. Tweetstats is like Twitter CSI. In a few seconds, it makes it easy to assume that Robert Scoble probably used Twitter via the Web to send a note to Eric Rice early on a Sunday morning in November. Or does that read like the game Clue?

Much like Google, Twitter is always tinkering with its platform so be sure to follow their blog to keep up with the latest tweaks.

6) Fun with Twitter
Most of these
“twicks” are thanks to Twitter’s API. Some of them
seem to be created purely for the (nerdy) fun of it. Twittertale and Tweetspeak are perfect examples of this. Then there’s the guilty pleasure of Twitter Confessions. Or check out Twitterholic and Tweeterboard to see if you know some folks that might need a Twittervention. Yep, two jokes in one hack. Not my first (or best) attempts at Twitter humor.

More productive fun can be had on Twitter, using it to hone your writing skills.

7) What Does Twitter Look Like?
A Flickr search shows a ton results for Twitter and there is also a Twitter Group on the site. But Photophlow takes this a step further and mashes the two sites together.

8) Save the World
Twitter has potential in
helping people get targeted information at a point of need. The
Department of Health and Human Services’ Office on Women’s
Health uses Twitter to broadcast health messages (via Canuckflack).

The American Red Cross has established Safe and Well through the efforts of Ike Pigott. Safe and Well uses Twitter to notify friends and family of your status in the aftermath of a disaster.

A Reuters
article points out that “these technologies all have a possible
role to play in the aftermath of a natural disaster or human attack,
when the danger is over, but not before. Why should anyone trust their
lives and those of their families and friends, to systems which they
cannot and do not trust even their credit card details to?”

9) Know the News. First
You can subscribe to plenty of news sources on Twitter, including Reuters, The New York Times, Google News and CNN Breaking News.
Twitter tends to be an early warning system when it comes to breaking
news and you’ll see many stories there before you will on
mainstream sites. Reporters are seeing benefits to this.

10) Take Twitter with You
You can push your Twitterstream to Facebook to replace your update and serve it up on your blog as well. This is good as folks are seeing Twitter cut into the volume of blog posts out there.

Twitter by the Ton
There are a metric ton of good Twitter tips, tools and hacks, with new ones being published almost daily. These are just a sample as folks see new uses for Twitter. If you’re on Twitter let me know what your favorite tip is and I’ll add some to this list.

http://prblog.typepad.com/strategic_public_relation/2008/02/top-10-twitter.html

Categories
Learn

The Nonprofit Twitter Pack: Are you listed?

Flickr photo by Beth

A few weeks ago I was doing a workshop and demoing some of the tools
of social media.  I took the above photo with my camera phone and
uploaded to flickr.  When I got to showing Twitter, I was met with
the usual skepticism.   So, I twittered about it as part of
the demo and asked my network to leave some comments on the flickr
photo.

Within in about 5-10 minutes, we had over 100 comments (plus lots of annotations
on the photo using the notes feature on Flickr).  This is always
powerful to demonstrate the rapid spread of information and the
networked effect – and can help open the possiblities.

Chris Brogan started a project called “Twitter Packs” which is a simple list of people who use twitter organized by interests or locations.  The Nonprofit Twitter Pack is here
(are you following everyone?).   I think that if we the
nonprofit people organize and find each other we can have a richer
experience on Twitter.   

The list below is from the Nonprofit Twitter Pack section — Not on the nonprofit list?  Add yourself here.

http://beth.typepad.com/beths_blog/2008/02/the-nonprofit-t.html

Categories
Learn

SOME CUSTOMERS ARE NOT WORTH CARING ABOUT

Website success has as much to do with figuring out who is NOT
your customer, and the information you will NOT provide, as
anything else.

Some customers are not worth the effort. They say that the
customer is king, but on the Web the customer is dictator. The
customer is impatient and demanding, with their finger always on
the Back button.

If there is one central flaw in web teams it is their lack of
ability (or willingness) to make difficult decisions. Deciding
to put more content on a website is an easy decision. Adding
more links, expanding classifications and adding more features
are easy decisions.

Easy decisions involve deciding that there’s an incredibly wide
range of customers. That’s easy. And it’s a cop out. Why?

Because when everybody is the customer, then nobody is. And when
every piece of content is useful then nothing is. And when
everything is put up on a website, the website is out of
control, unmanaged, and sliding down the slippery slope of
uselessness.

Who are you not going to serve? For those customers that you do
want to serve, what are the things you’re not going to give
them? In what areas are you going to make things difficult for
them? You can’t make everything easy. Making one thing easier
invariably makes another thing more complicated. What are you
going to leave complicated?

Web teams often become obsessed by the trivial and exceptional.
There are really crucial (and boring) things the website should
do but these get ignored. And the focus is put on the esoteric;
the minor task.

The world of the Web is a small screen and an impatient eye.
Nobody has time.

In the last issue, I wrote about how Ryanair went from a tiny
regional airline to one of the largest low cost airlines in the
world. It did this by relentlessly focusing on price. And it
works.

Ryanair shows you no mercy if you’re late. That’s terrible for
you. But is it so terrible for the 200 people on the plane who
were on time? If Ryanair waited for you, they’d make you very
happy. But there’d be 200 people who’d be somewhat unhappy.

Everything we do or don’t do on our websites has a price. If we
try to solve one issue then in all sorts of (often subtle) ways
we will negatively impact other problems. If we try to serve one
type of customer, then we affect the speed and simplicity with
which another type of customer can serve themselves.

Some customers are simply not worth the effort. Other customers
only become worth the effort when we serve a narrow range of
their needs. The Web is not a nirvana.

Practically every response I received about the Ryanair piece I
did last issue was negative. Yet Ryanair flew 12.5 million
passengers in the last quarter, and has $3 billion in cash
reserves.

The Web is an endless space accessed through a small window.
Success is down to focus. Who really is your customer? And what
do they really need to do? Everything else just gets in the
way.

Gerry McGovern
www.gerrymcgovern.com

Categories
Learn

Building Internal Support for a Corporate Blog


If most corporate communications professionals recognize the value of
corporate blogs, why have so few large companies implemented one?

Many obstacles stand in the way. Concerns over ROI, time restraints and
fear come to mind. In formulating a corporate blogging strategy, we
tend to place a great deal of emphasis on our external audiences. But
building internal support is equally challenging. I don’t just
mean CEO buy-in. I mean reaching out to various stakeholders within the
organization.

A successful blog requires understanding an organization’s dynamics and sensitivity to the needs of the principals.

No doubt this is common sense advice, but where do you begin? From
experience, I appreciate the need for thought leaders to articulate the
vision, evangelists to spread the word, mediators to build consensus
and believers to make it happen. But corporate communications can be a
catalyst and a key agent for managing the process.

Key Questions in Facilitating Change

As change agents, it may be useful for us to consider the following questions:

  • Who should own the blog and drive its content? PR, marketing, product (services) Development or a mix?
  • How will reader feedback be used?
  • What role do HR and the legal department play in setting boundaries?
  • Where does customer support fit in? How will it absorb questions that involve billing or require technical assistance?
  • How can the sales team take advantage of reader feedback?
  • How active should
    the marketing group be in preserving the brand, but respecting the need
    to avoid “marketing speak?”
  • How do you solicit IT to license the right software and to make sure it is scalable and secure?
  • How do you engage product or service development teams to ensure their consistent participation as advisors and contributors?
  • How do you enlist the support of employees to contribute or create their own personal or product blogs?

When I was helping
implement EarthLink’s social media strategy, I sat down with
executives and a wide cross section of the company to understand their
needs and concerns. I developed surveys to assess their appreciation of
social media and their usage patterns. I worked with the legal
department to define parameters. I met with IT engineers to understand
what was feasible and of course sought senior management buy-in.

It may be helpful to view your efforts as a campaign and consider the following steps:

  1. Assess what your competition is doing
  2. Monitor the conversation about your company
  3. Define your message (why you need a blog)
  4. Set expectations and key metrics
  5. Identify your key internal stakeholders
  6. Enlist allies to help spread the word
  7. Reach out to skeptics and address their concerns

Taking these steps will put you in a good position to make the case to senior management.

But as the weight
loss ads always say, your individual results may vary. Implementing
these guidelines won’t guarantee final approval for a blog, but
ignoring them will ensure failure and represent a lost opportunity for
corporate communications to take a leadership role in formulating a
company’s new media strategy.

http://bernaisesource.blog.com/2625138/