This is not new!  I’ve been doing such user interface review work for some time, but have now “packaged” it as a service, and sent out the following  news release explaining what I do.

Portland consultant offers “User Interface Review” service

Insight and Clarity, a consulting and coaching firm in Portland Maine, has introduced a new “User Interface Review” service, to help technology developers create products that are easy to use and hard to misuse.

Arthur Fink, owner of Insight and Clarity, explains that, “Most developers intend their products to be ‘user friendly’, but seldom does anybody spend enough time watching users trying to befriend the product”.  Fink sees himself as a cyber-age anthropologist, observing business cultures to see what tasks are being done, what tools are used. how these tools are used, and — perhaps most important — where users encounter stress, frustration, boredom, fear, or angst.  The result of this observation will be a strategy for revision or re-design, or, in some cases, a total blueprint for a new user experience.

In working on the redesign of a point of sale computer system for Subway restaurants, Fink spent many hours shadowing Subway associates at several Maine locations, and he worked for a few hours actually running the computer cash register.  “What appeared to be a fairly simple job turned out to actually be quite complex, and I learned so much about the difficulty of doing that job with inadequate technology,” Fink said.

Fink’s graduate degree in computer science from Harvard, along with studies there in social relations, linguistics, and cognitive psychology all appear to be strong credentials for his current work.  But Fink points to his years of experience visiting factories as a consultant and learning how to ask probing and provocative questions as his most important education.

Fink has been an independent consultant since 1982, working in such diverse areas as improving management structure for telecommuting programs, training system developers in user interface design, actually building database systems for a variety of industries, and helping senior managers improve communications within their organizations.  He’s currently working on the design and implementation of a hospital messaging system, and is writing a book whose working title is, “Asking Great Questions”.

Fink has been a featured speaker at conferences in the U.S., Canada, Holland, Norway, Sweden, and Ireland, and has spoken four times at Pecha Kucha gatherings in Portland, Maine.

Contact Arthur Fink at  arthur@InsightAndClarity.com  or  207.615.5722.

Years ago a client asked me to write a program to help them deal with credit cards that had been declined for pending shipments.  Operators would use this screen to see what had gone wrong, often speak with the customer, perhaps resubmit the credit card or try to process another credit card.  I listened carefully, designed what I thought was a great tool, and tested it with a number of the staff who would be using the system.  Operators could use the up, down, home, or end keys to scroll the list of credit card attempts, and tab into any of the “buttons” on the bottom line of this screen, and take just about any action that might be required.  In testing it all worked beautifully.

temp

But as soon as it was installed, I started getting reports that it was no longer working.  I spent some time watching the users, and saw that they were trying to use the navigation keys to move through the browse of credit card attempts while they were anchored on a button.  That was wrong.

And so I instructed the users to first tab into the browser, and then use the navigation keys.  “It’s about getting the right focus”, I explained.  But the users didn’t get it.  They were confused and upset.

It turns out they were right!  They shouldn’t have need to understand “focus” or any other system term.  It made sense for them to use the navigation keys anywhere, but my program wouldn’t allow that.  And it was the program — not these users — that needed to change.  Pressing a navigation key indicated that an operator wanted to control the browse, and I had to arrange for the program to first get focus there, and then handle the navigation action.

I lecture around the world about user interface design, about listening to users, and about being “user friendly”.  But here I’d violated every principle that I teach — telling the users what they had to do, instead of making the program interpret their very reasonable actions.

This is what user centered design is all about.  Despite our best efforts, we get it wrong much too often.  But no matter . . . watching the users, we can see where they have difficulty or get stuck, and we can design interactions that respond to natural user commands.  And we can learn by watching our own mistakes!

What do your employees do all day?  Why, of course, they answer the phone and take customer orders, or they open mail and post cash receipts, or they respond to customer service inquiries, or whatever.  Why, you might ask, do I bother with this question?

Well, many — perhaps most — employers don’t really know how their employees spend their time.  The order takers may function as fashion counselors, discussing how certain colors match or not, the cash receipts people may do more address maintenance than receipt posting, the customer service people may spend much of their time researching questions whose answers could have been documented.

There may be nothing wrong with this use of time.  One of my clients sold clothes specially designed for nursing mothers.  The order takers there were practically functioning as lactation counselors — and the company felt that was just fine!  The advice offered was a service to their customers, instilled confidence in them, and, it was hoped, led to increased sales of the nursing garments.

But it is a problem when computer systems are designed for one idealized understanding of a work task, and doesn’t support others aspects of the job that are no so well recognized or understood.  Here’s a particularly interesting example that I encountered on a consulting project:

My client created computer systems for collection agencies, and I was visiting one of thier clients.  For several days, I sat next to a debt collector, wearing a phone headset so that I could hear both sides of each conversation, and watching the computer screen to see what information the collector brought up.  Finally, I exclaimed to the collector, “So, it seems that your task is really getting people who owe money to make promises that they will keep”.  He was ecstatic, telling me that nobody had ever expressed it so clearly to him.  Then I continued . . . “so, all that data on the screen, I wonder what you’re doing with it.  Are you just computing how well the past promises have been kept?”  Indeed, that was the case, and at that point the collector was quite precise in telling me what kinds of promise keeping indices would be most helpful.

Although my assignment was officially to review the user interface of the product, it had become clear to me that the real task I was expected to do was to find ways to stuff more data onto an already crowded screen.  In a general way, the debt collection companies that bought this software believed that all that data was useful.  But once my client understood how

the data was being used, and what the collectors were doing with much — perhaps most — of their time, a significant re-design was possible.

Another company found that their order return processors were spending time keying in order numbers, or researching order numbers because customers didn’t return the part of the invoice / packing list that was supposed to be used for returns.  Putting a bar code on that document made it easier to retrieve data with each return, and increased the fraction of returns that did come back with the form.  Evidently customers attached more importance to a form with a bar code on it.

In another case, employees often wouldn’t realize that they may have made a mistake until they were processing the next order.  At that point they’d have to go back to the previous order, see if indeed there was something wrong, and make any corrections necessary.  Providing a simple way to perform that navigation (an “uups” button), speeded up that validation and correction process — even though it didn’t stop mistakes from being made in the first place.

Knowing what tasks your employees are really doing, and how they really spend their time, can help in user interface re-design, work flow re-design, plant or office engineering, and many other areas.

Follow

Get every new post delivered to your Inbox.

Join 4,568 other followers