April 15, 2015
I was once hired by a company that develops software for collection agencies. They wanted a partial re-design of the screen that shows on the collector’s computer after an automatic dialer generates a call to somebody with one or more unpaid debts.
It quickly became clear that what they wanted was not really a redesign – They just wanted me to stuff a few more fields onto an already very crowded space. I knew this was not a good idea, but how to proceed?
The screen in question was a very detailed review of unpaid debts, promises made for payments, or for a payment schedule, and actual payments received.
My first request to this client was standard: “Can I spend some time observing some real users working with this system?” Indeed, that was possible – although I believe they expected that I’d spend an hour or two in this phase. To their surprise, I spent a few days, sitting next to several collectors, and always wearing a “training harness” that let me listen to both sides of the call in progress. I offered no advice, and no comments. My purpose was not to educate or engage, but just to observe. A few times, after a call was completed, I’d ask a question about what they were trying to do with the computer screens – but my questions were never pointed.
And then, after many hours of patient observation, I blurted out this comment: “So, have I got it right, you’re in the business of getting your clients [those who owe money] to make promises that they keep?” The collector I was with practically jumped up and down for joy, exclaiming that nobody has put it so clearly. It hardly felt like a creative breakthrough to me, but this formulation did help me see more clearly what was going on.
Then I asked, “So, what are you doing with all this data on the screen? Are you, I wonder, computing a kind of index of promise keeping?” This was exactly what was going on, I was told, and when I asked what computations would go into that promise keeping index, the collector knew exactly.
Finally, I asked if instead of displaying so much detailed data, I showed only the promise keeping indices, and a few key data points. “That would be wonderful”, the collector explained. This would give him a quick picture of who he was dealing with, and would free him up to be more creative in the debt collection dialog.
Right away, we had a whole new paradigm for designing the key screens in this system. Instead of just showing lots of raw data, we could show some trends, that would really guide the collectors. It would still be necessary to have a way to drop down to the detail data, but that data would not be in the way when it was not needed.
The big picture here was quite typical: At one time all this data was probably written manually on paper files. The collector could open those files while talking to that particular “customer”. Later the collection agencies were able to use software that mimicked that paper files – although with easier access, updating, and reporting. And there were probably several upgrades to that software that were faster, had prettier displays, and perhaps added some other bells and whistles.
What’s wrong with this picture? The software had been designed, right from the beginning, to “computerize” the data, rather than to creatively help the debt collector manage the collection dialog. The notion of promise keeping indices was a radical transformation, that offered a paradigm for a new generation of debt collection software.
At best, user interface design or redesign doesn’t just result in more attractive displays of data. It helps users do their job better, faster, with less hesitation, fewer mistakes, and more satisfaction. A really good user interface elicits a positive emotional response. This is where the phrase “user friendly” really comes alive.
I called this short essay “Usability from the inside out” because the starting point is not the data or the screens, but the user goals and user tasks – which usually correlate closely the the overall business goals. By paying attention first to the big problem or goal, we can design software and systems that enhance productivity, improve user morale, provide more accountability, and are often simpler to use and to maintain.
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.
December 1, 2009
In consdiering the design challenges I face, I’d distinguish process from paradigm.
Many of the processes I use may be time worn, orthodox, etc. Contextual inquiry (or listening to users) is not new, paper prototyping was not invented last week. I use them not because they are “accepted orthodoxy” but because I find them functional steps towards creative solutions. The fact that they may be “orthodox” does not make them wrong or outmoded.
But I’m stuck with too many old paradigms about how to understand the world. I imagine a vehicle having some controls, and would have trouble coming up with a Segway where you just lean to steer it. I imagine sound players will have knobs, and would not have expected the iPod model. I still expect cameras to look like those old film devices, even though the physical constraints that led to such designs are gone. I don’t choose these paradigms — I’m stuck with them, until I find a way to escape.
How will my processes, methods, whatever, help me to see the world outside the paradgms that limit my vision? That’s the burning question for me — each day, and with each new project.
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.
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 »
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.
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!
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!
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!
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!
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.
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”.
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.
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.
October 10, 2009