Why ignoring the end-user makes you seem incompetent

IT product developers who don't try to understand the needs of end-users are doomed to fail.

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.

Now, this 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.

Now before 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 end-users.

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?

1.  Be an end-user for an hour.

Yes, I’m 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.

2.  Install 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 dear life.

3.  Don’t be afraid of face-to-face meetings.

Despite what 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.”

4.  Do 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.