This past week, my lovely wife pointed out that when I talk about complex subjects, I often resort to metaphors and analogies from unrelated areas of life. She said that it serves me well as a communicator because it can simplify otherwise difficult concepts ...and since she is my wife, I must of course agree.
The way I see it, when dealing with a sometimes obscure or confusing subject like software design and development, appealing to abstract, common sense ideas helps highlight the important bits while avoiding getting bogged down in details. There's no reason why I shouldn't be able to explain key software concepts to competent, non-technical people. They might be bored to tears but they should at least be able to understand what I'm talking about. In fact, as a consultant, I consider it a fundamental skill of the trade: if I can't explain to people (i.e. clients) what they're paying for, then why on earth should they be buying it in the first place?
What follows is a very incomplete list of some of the homegrown expressions I use most often when discussing software design. I've long been planning on writing entire articles for some of these (and most likely will at some point) but with my work schedule being as full as it is, here they are for now in a more concise form:
Concentrate your efforts on the small part of an application that people can actually see.
Roughly only 1/8th of an iceberg's volume is above water. A similar principle applies to software: you can often only see and touch but a small portion of the actual development effort. Therefore, make sure you prioritize the quality of the visible parts (i.e. the User Experience) because psychologically, that's the portion of your solution for which clients are primarily paying. No matter how rock solid your back end might be (and it had better be good), if your UX is poor, the total package can still be a complete failure in the eyes of users.
"Push on a Pull Door"
Never provide more than one proper way to use a control.
Some doors can be pulled, others pushed while even others can be both pushed or pulled (saloon doors anyone?) If something so simple as a door can lead to broken noses and bruised egos, then how frustrating can an unpredictable UI component be? This also relates to a warning I've often given myself and other developers: if you make a smart user feel dumb, you're just asking for trouble. Therefore, make the purpose of your UI controls, as well as how users are to interact with them crystal clear.
"The Free Coke Effect"
It feels especially good to get something for free when you expected to pay for it.
There is a special, warm, fuzzy feeling you get when you go to buy something (e.g. an ice cold Coke from a vending machine) and receive it for free instead. In this case, expectation is everything. You see, receiving a gift feels good but not nearly as great as pulling out your wallet and being told not to bother. This is because gifts are supposed to be free. Pound for pound, getting an unexpected freebie is altogether more surprising and enjoyable. Try to inspire this feeling of visceral satisfaction in your users whenever possible and you'll soon be a UX hero.
For more on this topic, please read my article at UXMag.
"Self Medication"
People with undiagnosed ailments will often intuitively turn to homemade cures.
Certain people suffering from mental distress will turn to substance abuse to soothe their unidentified ailment. Their addiction can therefore be seen as a symptom of another, underlying issue. Likewise, if you discover an overabundance of spreadsheets, Access databases, shared folders, or other homegrown solutions on a client site, expect to find heretofore unidentified business process or business system deficiencies.
For reference: http://en.wikipedia.org/wiki/Self-medication
"Smart Dog Software"
The expression "Even a dog knows the difference between being stumbled over and being kicked" also applies to software.
Make sure that your software is designed to differentiate between different levels of error/warning. Popping up "scare windows" every five minutes is a sure fire way to get users to ignore real problems when they occur. Think about it: if a sleeping dog is smarter than your software, you should probably expect trouble.
This can also sometimes be referred to as "crying wolf".
"Shouting at the Deaf"
Don't berate lost users, show them the way.
Whenever you must guide users through complex forms, failed validation, etc. it is often better to show them the right way of doing things than to berate them when they make a mistake. If they couldn't figure it out on their own to begin with (i.e. by following instructions or labeling), anything short of showing them how to do it right might also go ignored. After all, there's no use in shouting at someone who won't hear you.
So there you have it: Volume I of Taylor's Software and UX Design Lexicon (tm). I hope you enjoyed reading it. If you start using these expressions, please let me know, and feel free to send along any of your own useful software-related analogies and metaphors in the comments.
Oh, and if you're into such things, please take the time to follow me on Twitter.
Take care!
]]>