“The best time to win customer loyalty is when you make a mistake.”   I heard this from an IBM customer service representative who was speaking at a conference, and one of the best examples of this principle that I can cite is from IBM itself:

My IBM Thinkpad laptop would turn off intermittently.  I sent it in for warranty repair, and it was returned promptly . . . but after a short while I saw that the problem was still there.  I was leaving for Europe in a few days, and needed to take a reliable laptop with me.

I explained the situation to the IBM service rep on the phone, and she offered free expedited service — that should get my laptop back in time.  But I told her I was very nervous — really wanting to have it fixed locally and promptly.  She wasn’t sure what she could do, but offered to look for options.  A few hours later she called back to say that an IBM technician would be on a boat the next day,  coming to the island where I lived and worked. He was in a different division, she told me, but would be prepared to deal with my problem.

Sure enough he arrived the next morning, put his anti-static mat on our kitchen table, opened up the laptop, exclaimed that there was a loose ground wire causing our problem, fixed it, and left.  The problem was solved, and the customer was very happy.

The IBM speaker identified two costs in any customer service transaction — and particularly in one where the company made a mistake:

  1. The transaction cost.  In this case, IBM paid for several hours of a technician’s time — to accomplish a repair that could have been done more economically in their central repair depot.  That might have been a cost of several hundred dollars in this case.
  2. The opportunity cost.  I’ve never bought anything but an IBM laptop since, and whenever clients or friends have asked for my recommendation, I always tell them this story.  IBM has probably received tens or hundreds of thousands of dollars worth of sales as a result of this initiative.

Read the rest of this entry »


Most people are afraid of Pain and gainchange most of the time.  That fear leads us to resist change — even changes that could make our lives simpler, our work  more productive, our struggles with technology more muted.

As a consultant, it’s often my job to plan changes.  How can I minimize that fear, and ease the transitions, as I try to make change as painless and productive as possible?

My short answer is that I can acknowledge that the fear is real, and often well justified.  Change does bring pain — and pain is something most of us want to avoid!

But let’s put this in perspective.  Almost every change follows the pattern shown on the graph above, that shows how productivity goes up and down when a change is introduced.

  • Productivity immediately falls.  In fact, it often falls much more quickly than shown on this graph.  I call the amount of drop the pain. Think about getting a new cell phone.  At first it’s awkward to receive or make a call. Then we may find ourselves even more challenged when trying to enter or update contacts, or generate text messages, etc.
  • It takes a while for productivity to rise back to even the level where it had been.  I call that length of time the perseverance.  In the cell phone example above, that time may be measured in minutes, hours, or perhaps a few days.
  • Ideally, productivity doesn’t stop rising after the perseverance time has passed.  It keeps going up for some time, but then levels off.  The amount of increase over the initial productivity is what I call the gain. (Note that this picture is slightly inaccurate — as the gain  shown is a bit less than it should be).  Following our cell phone example, the increased “productivity” may not be easy to measure, as it may not be just about faster dialing or address book maintainance.

We will have pain, perseverance, and (ideally) some gain with every change. However, the size of these parameters may be very different.

  • Recently, our bank started using new ATM terminals that accept and read individual checks during each deposit, and that can print an image of those checks on the receipt. I stumbled during my first deposit, got it almost right on the second, but by the third time I was delighted to walk away from my quick and easy ATM transaction with a much better receipt than I had been used to getting.  Pain was minimal, perseverance was short, and the gain was visible and real.
  • About a year ago I moved into an office with a programmable thermostat to control heat and air conditioning.  I’m still experiencing pain and confusion working with this device, so evidently the perseverance time is quite long.  The supposed gain — more effortless temperature control on my part, and some energy cost saving for our landlord and for the nation — doesn’t seem to have fully arrived yet.

The thermostat example illustrates an important principle —  the gain itself does not typically ease the pain.  In engineering change, one must anticipate and allow for a “reasonable” amount of pain, and for  an “acceptable” perseverance time.  This is important and true no matter how great the gain.

  • I’ve been involved with the design of a new hospital telephone and messaging system.  Calls pop up automatically on computer screens, and the operators have instant access to a database of patients, medical staff, coverage instructions, etc.  The “gain” here is clear.  But hospitals installing such a system have a minimal threshold for “pain”.  For reasons we could easily understand and accept, a few hours of pain was about the limit — and that only if the productivity drop was minimal.  Emergency calls always need to be handled quickly and accurately — and the presence of a brand new computer system is never an acceptable excuse.  We had clear limits for the amount of pain and the perseverance time that would be allowed.
  • I’ve also worked on the design of sophisticated scheduling software for factories — that helps staff decide when to order their various raw materials or components, and when to schedule each fabrication or assembly step.  Here the threshold for pain was much greater, and perseverance time might be measured in weeks rather than minutes or hours.  Managers and line employees needed time to adapt to the new scheduling processes, and that was okay.

In planning for change, decide how much pain is acceptable and what level of perseverance can be required. Let this understanding guide both the design and development of any new technology, and the training and support to help everybody embrace the changes in the best possible way. The promise of great future gain does not typically ease the current experience of pain.

Shameless self-promotion?

October 6, 2009

Order more than you can eat

I shouldn’t need to “promote” myself here.  The range of content already shows me as a careful listener, as a creative thinker, as  somebody who works collaboratively to solve problems.  I’ve  a strong background in technology, but focus on people more than on the gizzards of complex systems.  And I’m a photographer who uses visual images to tell stories in a vivid and lively way.

What I need to say here is that I’m available to work with you, or with you and your “team”.  Email me at arthur@arthurfink.com or call 207.615.5722.

This is a short summary of a “typical” re-design process, showing some of the steps that led us towards a solution. I had been asked to redesign some of the back office software for a quick serve restaurant chain.  The people who managed all their software were evidently satisfied with the screens used for point of sale touch screen entry (like a cash register).

However, I was alarmed I saw this screen, and did manage to get a contract to develop a new design concept (not a final design). Frankly,  I was amazed later to see how productive staff actually were when using  the original version.

A screen before redesign

Customers in this restaurant walk down a sandwich line, and arrive at the end with their sandwich complete.  A clerk then rings up the sandwich(s), along with drinks, chips, etc. , using the screen at the right.

Although there’s an “icon’ for each sandwich, there really are only two images — one for large, and another for small.  The tiny text carries all the information.  And because there are now so many products (in addition to large and small, many sandwiches are available as child size, party size, salad instead of sandwich, etc) everal screens are needed to handle the full set. It’s a confusing complex web.

Read the rest of this entry »

Why Design Matters

October 4, 2009

“Design Matters because it is the essence of how we move our bodies and souls throughout our lives; the invisible hand that guides us through our day; predicts whether we move effortlessly through our process, or are encumbered by the obstacles.  It is part of us when we live, eat, sleep, work, laugh and cry.  It is the unspoken intimate sparkle, smile and gift of our shared existence; with the beauty of a system, building, artwork, or of nature’s undisturbed serenity.”

Written by Deidre Johnston in response to a query I posted seeking help for an article I plan to write on this subject.

This poem answers the question so beautifully that I post it here (with Deidre’s permission) as a statement by itself.

Which button opens the elevator doors, and which closes them?

Elevator close doors

Elevator open doors

Many people (perhaps most) understand the triangles to be arrows, and see them pointing in to mean “close” and pointing out to mean “open”.  That makes sense in a literal sense.

But I look at the left image and feel a sense of openness, while the right one feels tight and closed up.  So the icons give me the wrong message.  Yes, I can learn that I need to reverse my conclusion, but it’s still a tedious process.  First I look at the buttons, then I when I want to open the doors seek out the one that feels most closed and tight.

What to make of this?  Many icons have problems when used in different cultural contexts.  Perhaps my unusual interpretation of these two buttons is like another cultural difference.

It is important to know that icons don’t always make things simpler, then they can give confusing and misleading messages, and that they need to be used with care.

I’ll be interested in your comments.

The most recent meeting of Maine Interaction Design Association (iDXA) was a group project — generating design ideas for a website to present the work of  artist Adriane Herman.  Here’s how the Maine College of Art (MECA) web site says describes her work:

Adriane Herman references the culture of consumption in the imagery she utilizes and the presentation concepts she has employed to deliver objects ranging from the archival to the edible and in other ways ephemeral. Her 2007 solo exhibition at Center for Maine Contemporary Art monumentalized evidence of human intention toward action as manifested in to do and grocery lists.

Herman collects “to do” lists, and re-constructs them so that these transient documents become archival art objects.  A simple shopping list for a party becomes an introduction to a social experience; the list of tasks preceding a funeral reads as a memorial of love and caring.

Herman’s presentation gave us a striking picture of her passion, her clarity, her professed sense of “disorganization”, and of the patient care that goes into constructing her work. If you ever have a chance to hear her speak — go!

After her talk, we proceeded — individually or in small groups — to map out possible web sites.  Some focused on using well known modules and templates – to promote ease of use.  Others were designed so that the artist (not a “geek”) could maintain the site herself.  I took what I thought was a different path — wanting to create a web site that would model Herman’s world, and would let the user explore that world as viewed by different stakeholders:

  1. Herman’s house or studio, containing all the objects she’s acquired — some of which are already embedded in her art, and others that are waiting for a right place.  Some may be neatly arranged in flat files, while others are just in piles or disorganized boxes.
  2. Museum curator’s view, showing her work arranged by significance, by theme, by era.
  3. Gallery owners view, showing her work as it is for sale, for different uses (e.g. note cards vs framed prints), and at different price points.
  4. Bulletin board view, showing the connections and community that Herman is seeking.
  5. Classroom view, showing the skills,  processes, and methods that Herman can and does teach.
  6. Calender view, showing events, classes, shows, etc.

In order to move through this space, I “created” three new  “tools”:

  1. An envision tool that moves forward from an object to its uses in various art creations.
  2. A remember tool (the opposite of envision), that moves backward from an art object to the objects that comprised or informed it.
  3. An archival trash can, that lets people throw anything out (including objects of their own, not yet on this web site), knowing that nothing thrown out will really disappear.

Clearly, this design is technically challenging.  It represents a web that is not at all linear.  Would this be helpful in showing the complexity of Herman’s artistic life, or is this confusing and hard to use for inquisitive users?  Clearly it’s not “standard based”.

How new is it?  I’m not aware of other such webs, but would be interested to learn that I’ve reinvented something that already exists.

Talk to me!  I’m interested in continuing this conversation.

I heard this story from a speaker at a recent forum on social media.  She told us of working for several hours with a company that creates voice recognition software, and needed help with search engine optimization (SEO) to make sure that their story would get picked up by Google and the like.

As she was leaving, she asked the receptionist, “When people call, do they ask about voice recgnition products?”  “Never!”, replied the receptionist, laughing at the seemingly absurd question. “They ask if we have those computers you can talk to”, she explained.

I find this again and again . . . listening carefully is the key.  And that’s why my business card says “Arthur Fink – Listening to Users”.  In this case, the keywords need to include something like “computers you can talk to”.  Otherwise people will never find this product.

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.

Listen loudly

September 16, 2008

“Hurry up and finish speaking, so that I can tell you why you’re wrong!”

Have you ever found yourself thinking such a thought, instead of really trying to grasp what truth might be said?  Of course, such impatient waiting is not true listening, and rarely serves us.  It leaves us poised for a fight, rather ready for insight, understanding, and growth. Read the rest of this entry »

Users keep me honest

January 31, 2008

Why are so many computer programs hard to use, with misleading or confusing screen prompts, counterintuitive methods to accomplish simple tasks, and lots of options that are rarely used but that clutter the screen and that often slow users down?  There’s no need for me to ask whether this is the case, as friends and colleagues complain to me all the time.  On what appliance other than a personal computer would you press a ‘start’ button to turn the machine off?

At home, these issues may be simply an annoyance.  At work, they represent lost productivity, increased training time, and, often, less accurate data.  Programs that are hard to use cost the company every day.

As a user-interface designer, and a usability consultant, my job is to insure that programs are easy to use, intuitive, friendly, receptive to good data and likely to reject data that doesn’t make sense.  My secret in this work?  I spend lots of time with the users — first learning about the tasks they need to do, then watching how they use their current systems, paying careful attention as they try out our proposed designs in rough prototype form, and remaining attentive during further testing.

Even with my extensive training and — dare I say — vast experience as a computer software designer, I must confess that the users know more than I do!  They live in their subject world, and regularly use their knowledge of that world as they take orders, review insurance claims, schedule manufacturing or repair orders, or whatever.  Not paying attention to their experience is a much too common, and often fatal, mistake.

Here’s the story of one interface design assignment, and how careful listening turned the whole project around.  The project seemed straightforward, if not exciting.  My new client had developed a computer system to help collection agencies in their work, and wanted me to redesign the screens, and to offer some advice about the underlying technologies they were using for development.  That’s what I though, before I arrived at their office.

Actually, their primary agenda was more mundane and problematic.  They wanted me to magically stuff a lot more information on the already crowded screens.  It wasn’t at all clear how this would be helpful, and I knew that it would make their screens uglier and harder to use.  But how could I say this in a polite and helpful way, while steering this client to a more productive agenda?

For me, the first step was quite clear.  My business card says, “Listening to Users”, and that is exactly what I planned to do. After a brief review of the system design, I asked it we could visit their one client who was in the same Midwestern town as their offices.  They agreed, expecting, I believe, that we’d spend an hour or two.  We ended up spending two days, and totally transformed our agenda and their product.

I asked for a “training harness”, so that we could hear the debt collectors conversing with their “clients” as I watched them navigating through the screens of this computer system.  It turned out that most of these “clients” were repeats, who regularly defaulted on medical payments, furniture store bills, checks written pizza parlors, and credit card bills.  The computer system showed all these bills, payments made towards them, and promised payments that were never made.  Typically there were screens and screens full of data.

In between calls, I had time to ask the collectors about their work — how they assessed each situation, when they felt they were getting honest responses, how they decided on a strategy, and what led them to accept the final agreements (or lack thereof).  There were many interesting and complex stories, often filled with amazing complexity.  Along with these details were the feelings of heartache, as more and more of these “clients” were getting caught up in a web of debt that seemed inescapable.

My role was that of the cyber-age anthropologist, noting the debt collectors behavior, and beginning to discern some patterns.  I could see some common themes — almost some rituals — but some aspect of the collectors’ behavior kept eluding me.

Finally, on the second day, I blurted out what might have been obvious from the start:  “So you’re in the business of getting these clients to make promises that they will keep . . .  and it’s the keeping part that is so important!”  The collector I was with almost jumped out of his chair with excitement.  “Wow”, he said.  “Nobody has ever said it so clearly.  Yes — that’s exactly what we do, and the keeping promises part is what it’s all about.”

I ventured another statement, a bit more tentatively:  “And what are you doing with all these screens of data?  Are you computing how often clients have kept their promises (or not?)”  The collector was even more excited.  “Why that’s exactly it”, he said.  “I want to know what promises the client has offered or agreed to, and how well those were kept.”  And he eagerly agreed when I suggested that, “It sounds like we need to display some indexes of promise-keeping”.   When I followed  up with the question, “How would you compute these?” we began an active dialog, with the user taking the lead.  The initial computer screens should show the promise-keeping indexes, with all the data details available to the collector on later screen, but often not needed.

As long users regard me as a priest of technology, they’re hesitant to come forward and play an active role.  Once the discussion shifted to how data is managed in what now felt like their system, however, I became the process consultant, they were the experts.

Unfortunately, users typically are in the back seat as systems are being designed, and yet they are the ones with the most real subject knowledge.  By listening carefully to the users, responding thoughtfully, and  really trying to understand their work process, I could get their active engagement in this design process.  In this case it led to a radical redesign of the whole screen concept, and, I believe, to a much more powerful system.

This is an especially clear example of a scenario that I see constantly — Users who would not have been part of the process of designing the very systems they will use, but whose deep knowledge and understanding is critical to the system’s success.  Typically the users feel technically inferior, and, in fact, they don’t speak the “systems” language that computers consultants are so fond of using.  They absent themselves from the process, and are not invited by anybody else to join in.

In lecturing on the system design process, I explain that my first attempts to design a system are usually reasonably good, but it’s the users who correct me and really take it to a higher level.  Watching them work with rough prototypes I can see where they struggle with my designs, and where they can easily find their way.  And when the users have to struggle to use the proposed system, the problem is almost always that my design is not clear enough — not that the users need more training or experience.

When computer systems are hard to use, most of us blame ourselves and our lack of experience or training.  We don’t consider that usability should be a prime characteristic, or that as reasonably intelligent people we should be able to find our way through.  We also tend to assume that the system is properly designed to give us the benefits we expect.

Often, however, the systems we use today are simply reworks of systems designed earlier, that are themselves reworks, and at some point we can trace back to a system modeled on how people do a task.  Years ago I was asked to work on a system for an organic produce distributor — who wanted me to track exactly what was on-hand of each product in their coolers.  This sounds reasonable enough — until you realize that on-hand quantities were not what this distributor was selling.  They had trucks full of produce coming east from California, and were selling what of those expected arrivals were still available for promise to customers after subtracting what items had already been sold.  That’s a lot of computation for people to do, but not hard at all for a computer.  The computer system had to be rethought so that it could feed its users the necessary available to promise data that were the basis of sales and pricing decisions.  My job was to step back from the detailed operational data, and focus on how users are trying to interpret and understand this data and use it to make critical business decisions.

Information systems will add value when they truly enable users to be more productive, more confident, more correct in communicating with customers, vendors, and with other employees.  Simply using the latest technologies, having the fanciest and most beautiful screens is clearly not enough.  Buzzwords like “real time” or “bus architecture” mean little by themselves.  Here are some guidelines that can help insure that systems are really workable and usable tools, that exemplify best practices, and that really work for  your organization:

1. Include actual system users, at a variety of levels, in the design and review of the system.  Their experience and insight are critical.

2. Start with a clear understanding of the business goals of the system.  Don’t be guided by just a list of data elements to be tracked, or reports to be produced.

3. Watch the users working with the system — whether it is in rough prototype form, or is a production system running with lots of real data.  Learn how the system is really used, and to identify times when it probably should be used but, for whatever reason, is not.

4. Don’t count of your most technical staff to carry these concerns.  Just as you need architects, engineers, and builders to design and construct a new facility (and, in fact, you need lots of subspecialties within this list), so you need people with skills in usability, user testing, analysis, system design, modern programming methodologies, and coding techniques to design and build a new system, or to review and revise an existing system.

5. Insist that the overall system design be written in language that is comprehensible to you and to many of your users.

6. Keep looking at your systems, even after you believe that they are “finished”.  Most systems can be improved, but many never are.