The recent high-profile
fiasco of the healthcare.gov website has reminded me of an issue I’ve seen more
and more of lately, and that is: a disregard for customer service.
goes as high up as CEOs making decisions that they think their customers will want. And then it turns out that
they’re wrong (Most
companies fail customer service test—MoneyWatch). As the author of this
piece, Michael Hess, says, companies should be more concerned with the way
their customers feel because technology has made it much easier to praise (or
pan). “Customers now tell 15 people about their good experiences and 24 people
about their bad ones, while nearly half of consumers always tell others about
good customer service experiences.”
But it also
applies to internal customers. I have seen many cases in which the development
of a new tool for end-users is done seemingly without concern for the end-user.
Code is written, deadlines are met, but no one goes to the trouble of anticipating
and empathizing with what the end-user’s experience is going to be like.
everyone starts blowing gaskets, I know that end-users are not the only
shareholders in the equation. I know that you have other masters that are
guiding the outcomes of your projects—other masters who also happen to have
your future employment in their hands. But there are ways to successfully walk
the line between the two groups. There is a way to manage expectations of your
I think IT
has come to expect that end-users ask for on-a-whim features and not really
what they need to get their jobs
done. Since IT personnel won’t be the users of, say, a new cms, they can’t
differentiate between “it would be great if we had this capability…” and “We have to be able to do this.” So, they ignore
most of what they hear when gathering needs requirements—and believe me, being
ignored is one horrible customer experience– and they plod along creating a
product that is technically functional but lacking practical usability.
So what can
IT do to avoid this?
an end-user for an hour.
suggesting that you get up from your chair and walk over to another department.
Sit down by an end-user and watch as he or she goes uses an existing tool to
file a claim or enter some data.
I’m a firm
believer that witnessing a task is a much better way to learn than looking at
rows of a requirements spreadsheet.
a project manager who is neither IT nor in the area where a tool will be used.
What you need
here is someone akin to a U.N. interpreter. This would be someone who can
understand technical details but who isn’t actually in IT; someone who can
understand and translate end-user needs but knows how to weigh and triage
technical requests. And if you find such a person, hold onto him or her for
be afraid of face-to-face meetings.
I think most people fear, I’ve never witnessed a gladiator-type, to-the-death
interaction between IT and the employees of other departments. Google docs and
email might work for interim meet-ups but the occasional group get-together
helps with clarity a lot during a project. And it’s also the place where you
can tell an end-user why his desire for a 3-D button is not at the top of your to-do
list. Explain about priorities, particularly those expressed by upper
management. Given some perspective, end-users might be able to “get it.”
a post mortem/survey with end-user input.
Yes, it could
be painful, but you will also learn some valuable lessons along the way that
you won’t repeat the next time a project comes up. It’s also a time to let
end-users what they could have done to make the project go smoother. [See item
number 2 if you need someone to referee.)
Also, if you
create an end-user survey, make it a good one. So many times, I’ve been the
recipient of surveys whose questions are designed to garner only positive
answers. For example, don’t ask a yes/no question like “Did you at any point during
this project kick an engineer in the throat?” and then expect a No answer to be taken
as relationships with shareholders were good. Enlightenment might sting, but it’s
good for you.