Listening to Users / Designing Usable Systems
March 5, 2010
Users have a special knowledge, and an intimate familiarity with data and process. Listening to them informs us. Watching how users work with our prototype system design lets us refine the design, so that it is clearer, more intuitive, easier to use, and harder to miss-use.
Listening is an attentive and active process that that requires focus and energy. Too many system design projects are based on untested assumptions — when listening to and watching users could have created a much better result.
Design is not cleaning up the mess, or adding ornamentation at the end. It’s a process of thinking, organizing, trying, testing, reworking, creating anew, refining, honing, and more. Successful systems work because they are well conceived, and responsive to user needs, styles, wishes, and habits. They continue to work because they are well structured, and can be easily maintained and enhanced.
A successful user interface design defines a process by which users interact with many elements of their work world. It’s much more than just a pretty set of screens.
Designers don’t follow trends
November 13, 2009
“Designers don’t follow trends — we make them”.
Quote from Brook DeLorme, clothing designer, as she spoke before a business networking group, and was asked how much she follows and responds to fashion trends. Her web site is www.Brookthere.com, and her store / workspace is located at 37b Wharf Street in Portland, Maine.
Judge computer systems by usability
November 10, 2009
Your computer system can be easy to use – and to utilize.
Want to turn off your PC? Just press the “start” button, and navigate to “shutdown.” Does this make sense? Perhaps to a system designer (who understands that it’s about starting the shutdown process), but not to most of us.
How many times have I been told by a clerk taking my order, or in some other way trying to serve me, “the computer won’t let us do that.” Well, the computer should.
With all the advances in computer technology, unusable systems are still with us. Perhaps more problematic are the systems that appear to work just fine, but that really don’t provide the assist that is needed.
What can you do as a manager who wants technology to serve your organization, to assist your staff in performing their jobs, and to make it easier for your customers to interact with your organization during every order, fulfillment and customer service functions? Read the rest of this entry »
Do we believe that the brown pot is decaf?
October 23, 2009
It seemed odd to me — a brown coffee pot, with a sign that said “Decaf”, while all the other coffee was in orange or red pots. Decaf usually goes in an orange pot, so this was confusing to me. “Great subject for a blog” post, I thought to myself, but drinking some of the coffee and reading the morning news felt more important at that hour.
But then an other guest walked into the hotel breakfast room, and asked me if we could trust the “decaf” sign. Evidently I was not the only one confused!
We are accustomed to various conventions, color codes, configurations, etc. Decaf goes in an orange pot, oxygen in a green cylinder, stop signs are red, and (at least in Europe) the cold water faucet has blue markings. Violate these, and we leave users confused and anxious.
Database Anesthesiologist, or Database Psychiatrist?
October 21, 2009
When people learn that I had been working with the database product “Progress” since it was first introduced (more than twenty five years ago!), they put me in the “technical” box. Indeed, with my graduate degree in computer science, they might assume that I have a full grasp of this product.
Ten or fifteen years ago, they might have been right. I could design and build systems, install Progress and my application, tune the whole system for great performance, work with staff to ensure that the system is well utilized, and enhance it so that it better serves its purpose.
But the world now is more complex. Now I do only some of these things — particularly those focusing on interface, usability, and integration into the creative organization. Meanwhile, some of my colleagues focus just on the technical performance issues — everything from configuring the right disk drives and data paths, to stitching together databases that have somehow become corrupted. I refer to these friends as my “database anesthesiologists” — doctors who carefully monitor the vital signs, and keep the patient alive.
I don’t know why they dislike this name. It’s a sign of respect to me. In fact, I’ve an allergy to general anesthesia that could easily be fatal if an incident occurs. I know that I’m putting my life in the hands of anesthesiologists every time I go into the hospital for elective or emergency surgery! (The condition is called “malignant hyperthermia”, and I’ve already had one episode).
In this paradigm, I call myself a “database psychiatrist”. My job is to keep systems communicating effectively and efficiently, and functioning as part of a social team with people and with other technology. Systems need to be easy to use, hard to mis-use, and they need to do right things with the data they handle. They also need to come with realistic and helpful expectations. For example, systems designed to help forecast or plan may be invaluable tools to help staff understand the implications of a model, and of the data that fed into it. But where the assumptions of the model break down, or where the data is not realistic, the validity of its projections need to be questioned. I call work in this area “computer assertiveness training”. It’s about learning when to (figuratively) turn the computer off, or put it in its place.
Today I’m much more than the “database psychiatrist” described above. Much of my time is spent listening to other kinds of management issues — typically involving such things as communication and values within organizations, marketing strategy, management of creativity, and general problem solving. I also spend time “coaching” (I prefer to call it “clarifying”"), where I’m offering a helpful process, and not a solution. But one thing I’m not — the database anesthesiologist!
Uups! I forget this was “user centered design”!
October 20, 2009
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.
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!
Dreaming: An effortless conversion to Gui
October 16, 2009
The following query appeared on a technical programming e-mail list to which I subscribe. My response, which I’ve printed below, is really a discussion about the importance of dance, and about the design process.
We are testing out a product which sits over our character product and give it a GUI [Graphic User Interface] look and feel as well as most of the important GUI functionality. Has anybody had experience in doing this and , if so, what are the pitfalls I should be looking for.
So far the results are phenomenal. With very little change to our character code we have been able to generate a gui application that does not kill the network resources. Instead of looking at one – two years of development to get our software . . . we are looking at one – two months. . . .
Tell me I’m dreaming!!
You are dreaming. Definitely.
You can certainly get products that will put GUI objects on the screen. People may take a quick look, and say that you’ve a “GUI” application. But conversion to GUI is much more than just GUI objects! It means enabling different kinds of work flows, allowing users to move through the screens in different ways. It means providing parallel tracks, so that most applications can be run either by mouse or by keystroke commands. It means conforming to well accepted GUI standards, so that users accustomed to products like Microsoft Word and Excel will find themselves at home in your application. The result should include more efficient use, easier training, higher accuracy, less user stress.
Also, the process of moving to GUI can be a time of re-thinking how your product enables users to do their jobs better, and to re-think some of the core functionality. A plug in product that transforms the visual appearance of screens does not invite that important re-design step.
So dream on … or invest in a constructive process of really transforming your application. (Or … re-think what advantage you believe GUI offers. If it’s just marketing — being able to say, “We’re GUI” without being better for it in any way — then the whitewash product may be just what you need!).
. . .
I use the word “Design” in the new subject line above in its broadest sense. Design starts with listening to users, and includes building mockups, having real users test and critique them, re-working the interface to accommodate this user feedback, and iterating on this process. “Design” does not just mean drawing pretty pictures or screen layouts!
You’ve been reading an advertisement
October 13, 2009
That’s right. This whole blog is a marketing tool. That’s not to say it’s not interesting, perhaps engaging, accurate, or useful to most of you who are not my clients. But it’s also an exercise in relationship marketing.
While you’ve been reading this blog, you’ve been developing a relationship with me. And if you’ve taken the initiative to add comments, you’ve helped me learn about you. I hope — and do believe — that our relationship of one of trust and respect.
Now … what if you need a consultant to help with questions of strategy or organization in your business? What if you’re concerned about maintaining your organization’s values in this age of increasing automation and mechanization? You may feel that your computer systems or web sites are confusing, hard to use. Or perhaps you feel that some “coaching” or “clarifying” would help you work more effectively, overcome a creative block, or break through some other barrier. Most of us don’t go to the yellow pages, or its internet successor, Google, to find help in these times. We look to our established relationships, and set them in a more structured business model.
In this relationship marketing strategy, I’m trying to build connections that will result in a few business relationships. I say “few” not to be self-defeating, but because I’m realistic. In marketing terms you’re not all “qualified” prospects, who can gain value from my services and skills. But some of you can. (Talk to me, please.)
Some of you may stand back, observe this scene, and notice how such relationship marketing can work for you. People talk about “social networking” as if it’s a technology. But, as our local social marketing consultant Fred Abaroa (Costa Vida Fred) has proclaimed, “If you want to use social marketing, you have to be social!”. Treat this blog, and all the electronic and soft personal communication that can surround it, as a potential salon for sharing, listening, and finding who and what can add value to your life and your business.
The advertisement is not over. Keep reading!
Putting Computers In Their Place
October 13, 2009
This was written in 2002. I’m amazed to find how relevant it is today — even with all the changes that have taken place.
I help design computer systems for business applications, and so you might expect me to extol the virtues of computer systems in this column. But — quite the contrary — I offer here my observations on the overuse of computers, on the danger of excessive reliance on this technology, and on the need for creative vision.
To many of my clients, and would be clients, I am, of course, a priest of this technology. Clients bow to me, expecting that my knowledge of computer technology uniquely qualifies me to design a role for computers in their organizations. I remember one client in Holland begging me for a “great purchasing system” to compliment the scheduling tool I had given his organization. But when I asked him what problems this system should solve, he was mute. He could not tell me whether the critical problem was vendor selection, quality control, scheduling full truck loads, lead time, or what. And yet, without me, he was running the purchasing department, and must have been sensitive to such issues and knowledgeable about which were in control and which were not.
The role of type is to be read (simplicity #2)
October 12, 2009
My father was a graphic designer, perhaps best known for the red and blue “Bazooka” bubble gum package. He told me clearly — both in words, and by example — that “the role of type is to be read”.
(from http://www.madebymany.co.uk)
The sign in the street on the right has such crazy letter spacing that an unsuspecting pedestrian would probably spend more time looking at the type than at cars coming from the direction least expected. Reading this text is very difficult — and this is supposed to be a warning sign! I expect it was painted by well intentioned citizens after an accident or near accident.
On the other hand, this type was clearly squashed together by somebody trying to be fancy. It may be an interesting graphic, but it’s hard to read. Just because our pc’s let us use a thousand fonts, modify the leading (line spacing), kerning (special character spacing), etc., doesn’t mean that we should do all these things.
If curving type does not make it easier to read, don’t do it. If extra rules or boxes or borders don’t improve readability, they don’t belong on the page. There are plenty of treatises on good typography that explain in detail what we should do, how different fonts work in different ways (some are better just for headlines, for books with lots of text, for quick readability on signs, etc.) One principle they all exhibit is that simpler and more straightforward is generally better. That’s all my father was trying to tell me.
A plea for simplicity … in all things
October 11, 2009
My tolerance for complexity — in all things — seems to be decreasing with age. And I don’t believe it’s the onset of dementia. Quite the contrary, I attribute it to wisdom gained with considerable experience
Brian Kernighan, one of the authors of the ‘Unix’ computer language, wrote:
Debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
Computer programs always have some degree and complexity, and usually are not exactly correct. They are born with “bugs”, and the task of debugging is about finding those flaws of logic that lead to wrong behavior in certain — perhaps unusual — cases. If the program is written in a clear straightforward manner, with visible structure, and an appropriate number of explanatory comments, the debugging process will be much easier. But if the program is written with clever tricks — perhaps taking advantage of some esoteric facts about the number system — debugging will be difficult or, as Kernighan suggests, impossible.
I used to travel widely, delivering to computer programmer audiences a talk entitled “On being lazy, absent minded, and a great system developer”. I explained that being lazy meant that once I’d developed some code that worked, I’d take time to document it carefully, and package it so that it could be re-used in other larger programs in a natural way. Thus I would do something well, once. Being absent minded meant that I’d often lose track of where I was in the coding or development process. To compensate, I’d have to write a plan first, and document any changes to that plan as I proceeded.
With these definitions, all the developers and analysts in my audiences could affirm that my qualities of laziness and absent-mindedness — as I compensated for them — were excellent qualities! In fact, what I’d spelled out are two best practices for writing code. A program consisting largely of well written and already debugged small sub-programs will almost always be more reliable than one written as a new mass of virgin code, and intelligent comments are an important compliment to the code itself.
I asked my audiences for a show of hands, how many spent much or most of their time debugging or updating other people’s code. Most raised their hands. Then I asked how many found that code to be unclear, unstructured, hard to read, and difficult to modify in a safe reliable fashion. Again, most hands went up. Finally, I asked how many were rewarded in their performance review for writing such high quality code — instead of just for writing lots of lines of code that seemed to work. This time the hands stayed down.
Evidently, although we recognize that complexity is almost unmanageable, we’re too often unwilling to invest in simplicity. And simplicity is the product of good design. I believe that the underlying issue is our reluctance to understand the importance of design.
I’ll have more to say about this in future posts on this blog.
These signs sure confused me!
October 10, 2009
(Image mentioned in comment by Marko)
The best time to win customer loyalty is when you make a mistake
October 9, 2009
“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:
- 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.
- 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.
