Tuesday, May 1, 2007

Please keep the user in mind....Please.....

I've been working at the same company for almost 10 years now - in different capacities, but always in the role of determining how we will communicate with our users. Over the years, I've gotten teams to be better and better about bringing training and writing staff into the development cycle early on. There's nothing worse than coming into a project at the end and being asked to write training material or help systems on a product that couldn't be less user-friendly if you tried. It's too late most times for changes to the system and the trainer/writer is left feeling like they're setting the user up for failure.

Unfortunately, every once and a while, we still get thrown in at the end, as is the case with a project I've recently been assigned. The web-based application that I've been asked to write a help system for is one we got from an outside vendor. I can tell we got this one because it was the cheapest one we could find. This application is supposed to track information about the deals we do (I work for a law firm).

So, I met with the project manager last week to go over what was needed and I found that I had to stop asking questions about why certain things work the way they do because I was entirely frustrated with the answers. It went something like this:
Me: Why do we have some fields that are picklists and some fields that are lookups and some fields that are free form, all on the same screen?
Him: Because the information from this field comes from the authentication file and this one comes from the core database.
Me: Why should a user have to care about that or know about that? Can't we just have them enter information in one way?
Him: No, it doesn't work that way. We tried to get the vendor to change some things, but they won't.
Me: OK, I'll figure the rest of the application out myself - you can go now.

Yes, the user can figure out how to fill out each field, but they shouldn't have to. A designer should have usability in the forefront when designing applications. I realize my involvement earlier on in this particular project wouldn't have helped as we have a vendor who has already sold us a product that they know they don't have to fix....we've already paid, after all....

But, if your designers aren't very good at usability, do your user base a favor and have a few people test it out and give you feedback. It can make a world of difference.

A couple of useful usability links
http://www.usability.gov/
http://www.useit.com/

2 comments:

Anonymous said...

We're at the end of the dev cycle, too. Before they are ready to ship, our engineers are very secretive about the workings of our products. They question us thoroughly and 9 out of 10 times, they won't let us see a product ahead of time. Then they send a version over to us to look at for one day before it ships and expect us to produce a fully developed service and parts manual.The problem is that engineers don't seem to care if any documentation goes with the product at all. Once it gets out the door, it's our problem, not theirs. No sense of user-centered design, either. Product if finished and you have customers going, "How do you turn this on?" Turns out the switch is in a hidden panel that is not apparent from the front of the product. While that's neat, it does new users no good whatsoever.

Catherine R. said...

bean - I hear ya. It's pretty hard to convince people who are "in charge" that there is more to manage in a technical implementation than just the technical aspects....I feel like I'm the only one who "drank the kool-aid" in the room when I talk about building in time in the project plan for documentation and training development. Instead, the people who actually have to use the system are an afterthought and "success" is measured by whether or not they got the system "working."