Practice, Practice, Practice
When I am consulting with a client, and navigating on my machine they are absolutely stunned at the speed of me using just the GUI. I have to remind them: I’ve been using GUIs for 30 years — starting from the very first Macintosh, and using various OSes since then (from BeOS to X-windows and back again). Given my use “cross-training” and approximately 40,000+ hours (conservatively) of using practically every type of app, I’d think I would be an expert at efficiently navigating almost any app. As a side effect, I have also gotten very good at spotting good and bad UI. If I don’t know how to do something: I usually know the magic words and the search terms to use. If even I cannot find info quickly, then something about either your apps and/or your documentation is lacking.
This not a boast, but the answer to “how are you so fast/learn this so quickly?” Basically: I’ve seen UIs grow up, and used them so long it would be like asking a 9 year old how they walk and talk at the same time: it’s second nature to me. I have had people ask “do you know this app?” or “do you know how to do this in this app?” I’ll say, “no, I don’t…” they’ll look disappointed in the split second before I add, “but let’s see if I can figure it out.” 98 times out of 100, I find the solution within minutes if not seconds. The 99th & 100th time results in me learning that either: (1) it’s not even possible with the app or (2) I search the web, and in about 2% of the time, I never find an answer thanks to really bad Knowledge Bases (KBs) or marketing material were actual support info should be. Technical Specs should be a list of supported standards if it is a product that connects to other HW/SW, measurements of accuracy, environmental limits such as upper file size bounds in the case of software, and lower & upper operating temperatures in the case of portable hardware.
BTW: if you are going to use a new icon, you really should have a screen shot (or tooltip) with each on labeled and a description of its function.
I still possess the ability to rollback what’s second nature to communicate with people less experienced in terms they can understand, and teach them terminology to help them communicate clearly.
“The ‘little triangle thing that you click and it opens’ was/is officially called a “widget” even though that name has been co-oped.
“The sidebar is usually adjustable by hovering over the split in good apps, and in better ones the sidebar has almost no minimum width
“Good apps usually have windows can be resized to to be take very small amount of real estate.
“The icons on the dock are single click, and can be added or removed from a variety of way, etc.”
There is nothing “special” about my ability—everything above is well known to people who spend more time using their machines than they have to. It’s just people with innate curiosity, open-mindedness and interest that discover this, and it is what separates 10-years using, but still “novice” users from 1-year but “competent” & “advanced” users.
This minimum level of genuine interest why I tell people not to go into any industry just because it pays well (hopefully what industries you are interested has jobs that pay well), because you will hit a “lazy wall” of “good enough” and might become obsolete long before retirement age, while a person actually interested could be doing a much better job because he or she is driven by genuine interest in the work.
On the flip side, I have found that my point of view is also rare: it is one of a person that considers use cases outside my own, and is always open to options for others, and always looking for ways to improve things. Add to that, growing up seeing GUIs evolve and seeing where their logic stumbles, and you get the following.
Testing Also Means “Using”
When I design a simple DB view or other UI element, I “eat my own dog food.” I do intensive needs analysis (which most recruiters have never heard of). I design systems to do the job the way that allows the user to learn it with a very low learning curve by anticipating or observing points of aggravation (noted above). This has become known a “task-oriented UI.” The entire reason for this is to avoid making the user switch mental modes from doing a task to navigating the interface to pull up the right screen.
The whole idea of what separates good and bad interfaces is, in a good one, you want to avoid interrupting a user mid-task by eliminating any sort of mental contextual shift. And shifting from doing the actual task to navigating is a disruption that can kill productivity. It coincidentally is also were many people get side tracked. Switching contexts loses momentum. It is akin to a bike rider having to stop peddling to look for the levers or button to switch gears every time they change speed.
Now here is where a majority of UI designers whose work I have seen and that I have spoken to get it all wrong. They think 1-click to switch screen is no big deal and they also think that consistency means the control or display for something should only be in one place. This is “dead tree” thinking, that belongs in a landfill of outdated concepts. I think os screen as a landscape with only so much “real estate” to show whatever we want that refreshes 60 times (or more) per second. As long designers give visual indications by using ordering/hierarchy, proximity/clustering, even slight color embellishments, and other cues that suggests a logical progression we are off to a good start. Also, all controls to do a task should be as accessible as they are in a car. So, I sprinkle both helpful controls and feedback throughout my UI if I find it helpful to the task. Sprinkling usually happens in my own testing, as I realize I have to switch screens to see info relevant to my current task. I get tired of flipping views back and forth very quickly, and think, “I’m the designer, I can easily put a non-editable view of this field in this task view. What if they want to edit it? I will grey it out to suggest it is read only, and add a locked icon. Then they will want to edit it sometime, so the lock icon is actually a button that switches views. Oh, now I have to add a warning or cache their info… what’s more logical?” As you can see by that example, I am geared for problem solving. A large percentage of good UI design is anticipating behavior and coming up with solutions that handle those behaviors both elegantly, efficiently and most of all consistently.
When I am designing a UI, I have often one view that shows everything just for myself. Even the sum-fields that are computed and un-editable are viewable (this can help you spot a stray space if it is a concatenation field FYI), so I can see all the moving parts at once. Sure it’s ugly and sometimes cramped, but it is the “under-the-hood” engineering view only meant for me, and anyone with the guts to look at it—yup, sometimes (for non-sensitive data) leave it in. I have had end users find it, and ask, “What the hell are all those fields!” or “why so many?” or permutations of those questions. I tell them, “I consider it my overview for diagnostic purposes. If something goes wrong, I can look at that and spot the problem quickly—oh, and in case I want to look at everything.” Then they ask why allow them to see it, and I reply, “why not? If you want to understand how it works you can. Just stay in the list or record views if it bugs you, but if you want to see what’s going on in the background sometime, take a look.” And if nothing else, they suddenly appreciate how complicated this system really is or they suddenly are able to troubleshoot mistakes, and then realize I “saved” them from having to look how a pure engineer would make the UI “UAF*” or saved them from having to get help because they realized they could also use it as a diagnostic overview and solve their own problem more quickly than getting me.
Now obviously, some controls, such as “delete this entire document” you want to stick where the gas intake is on most cars so the user has to intentionally switch modes to do things incredibly destructive. The concept of “forgiveness” is lost by many of today’s UI designers, and they won’t hesitate to put a delete key within miskey range of a “spell check this segment” key (or something similar). Time and time again, I find myself miskeying on my phone, and the delete key destroys a bit of work, with no undo. Some UI designers explain away this bad UI using the “they just have to hit command/control-z.” Do they not realize how many people don’t even know that there’s an undo? And how many more don’t know what they mean by “command/control-z.”
When the same information is shown different ways depending on the task, I also tend to present it the same across the application so users will recognize it, and find it faster. For instance, an address cluster will have the same layout while any money fields will be slightly tinted light green and each section might have a color attached to it, so related fields/controls pop out at the user. Without even reading a single instruction, people immediately get color coding as long as it is consistent—don’t make a time related set of displays yellow in one view and then brown in another. The bigger the navigation shift, the bigger the visual indicator. So, yes, the “delete it all” button (if there is one) is bright red, and oddly enough, the “undo” button next to it that was a pale grey will light up bright blue if the red button is pushed. I have gotten comments about how a good design can stand on its own without color, and that color should be minimized. These people don’t know why the rule is there, and misinterpret is as “avoid color (or clashing colors) at all costs!” This is not true. The avoidance of garish colors is to allow the user to focus on the task and not distract them with a trip through Wonderland. If a user hits a button in error, then “zombie-ly” clicks through the “Are you sure you want to delete this record button” — it actually happens a lot. The sudden surge of panic washes away when they see a clamming blue “undo” button light up that tells them (1) the interface forgives them and (2) it’s okay to make mistakes because (3) this program has your back. I know and you know there is command/control-z, but for those that don’t “Thank god there was an undo button!” will be spoken, if not to you, to someone that might know who put it there.
When I sit down to test an Alpha or Beta, or make my own interface, I look for ways to synthesize a solution that optimizes how people “think” about the process of navigating their computer. If this is a “simple” retooling of a UI, I try to make something that turns their frustration at using the computer as a tool, into an easy process if not a delight—like the multiple paths to the same info or controls, and forgiving little mistakes. Anytime I grimace or see a user grimace or look lost, I find out why, and address it as best I can. But before the user even sees my UIs, I literally do the same work they would, and use the tool how they would, and find most of the sore spots and fix them well before the user even sees it. Any problems left after I make a UI/process is usually at their end because they have a higher level of proficiency doing their task than my own, and I might not have realized they did something. So, I go back and often I add an optional way to do it to their liking (and keep my basic option as well). “Options are a good thing.”
Every time, without fail, this “handcrafted” process has resulted UIs that are far better than a majority of actual users could have hoped for had I just taken the use cases at face value, and stuck the user with whatever I found convenient and met the pre-requisites.
But I have been spoiled by having access to users because most of my designs are in-house where some or all of my end users are in the same building. If you are crafting a UI for the masses, you want to find as many different types of people as possible to hopefully find your apps flaws before the first paying customer can trash it in a review.
Forgotten Guidelines
The problem is, current designers have forgotten or never knew the fundamental principles of consistency, feedback, forgiveness, perceived stability, aesthetic integrity, modelessness, nor why they even exist. The general rule about breaking guidelines is this: if you don’t know why a guideline exists, then you do not know when it is appropriate to break it. Your idea for a killer UI trick might break a rule and cause frustration you might never see because your environment or your use case is not identical to every other persons. “One size does not fit all.”
After this baseline, a good UI is supposed to allow people to “level up” their skills at using their software at their on pace. The addition of shortcuts and alternate ways to interface is a plus. I still see tons of people filling out webforms without realizing they can hit the tab key to move between form fields. So they have to switch the the mouse, find the pointer, then click the next field. The tab shortcut has been around decades, but without a gentle push (as in a quick-tips above), many naïve users will never discover this shortcut feature. Also, some form fields with predictable input (such as IP octets) auto-tab which actually makes some more advanced users skip a field. Others, also make their form field a fixed pixel size that doesn’t account for different font widths which prevents a user from seeing their entire field input art a glance. If simple math of converting 16 pixels to 1em and vice-versa is too much for these page designers, then there is not much hope that the situation will improve.
Options are a time saving feature that are appropriate for users of all ranges make your app or web page more enjoyable to use — but they aren’t easy to come up with if you don’t learn about good UI by both studying it and also trying good and bad apps — and a lot of them. If your app is not enjoyable, and people are making faces while using it, there is something wrong. And no matter the level of technical behind the scene wizardry you cook up, your app will be perceived as poorer than others that might not have your apps level of sophistication (Aesthetic-Usability Effect). I have seen the removal of shortcuts for advanced users many times — apps slowly striped of efficient functionality to appease the desire to look easy. Yes, eye candy is nice, but the true “candy” is an app that is a pleasure to use. Unfortunately, more designers have forgotten that “simple UI” is not a synonym for “easy UI” than have not.
The hip designers that make flashy non-standard UIs have forgotten that their audiences do not all live on their machines like they do. They have no concept of building on established UI standards. They have forgotten that if you are going to invent a new icon, you should probably either make it very obvious what it means using a well thought out design language or offer definitions (as above). Also, they have forgotten that a clean UI is more than having as few controls and icons visible — it’s having the options even advanced users want within a few clicks. And the fewer the clicks, the stronger the consistency of the design language and the clarity of which you inform new users of it will determine how many support calls you get, and how efficient your tool is at doing what it is supposed to do. Remember that: at the end of the day, all that really matters is how fast you can get work done in an app as easy as possible for users of all levels. If a novice or advanced user has to jump through hoops, guess at what something means or has to switch out of creation mode to navigate or orient themselves or switch to problem solving mode, your apps reason for existing is damaged, and you are also ripe for someone else to come along and show you how its done.
Guideline Blind Features & The Knowledge Gap
I’ve seen most of the conventions evolve from the ground up and have seen new ones die trying to be become groundbreaking without actually studying how people want the application to act. Most that failed suffered from being blind to how they actually affect usability, and those that were good but never took off (and are now being stripped out in the name of “simple”) suffered from not informing the user of their existence. So, if you design UIs or are an end user, you can still learn a lot if you haven’t studied the guidelines or learn to orient yourself quickly by understanding the structure of design metaphors. Once you know the guidelines or the metaphors, you will be able to level up your designs and user savviness. Until someone comes out with a UI that communicates with concise clarity, there’s also duckduckgo.com’s search to help — assuming you can find the magic words. But that’s another problem that I hope is eventually addressed. I myself have an idea about how to, but the problem is learning how to implemented it. Again, it comes back to a knowledge gap.
The Bridgeable Gap
21st Century’s next UI breakthrough could alleviate a majority of these knowledge gaps. They could be clear, concise, communicative, contextually aware, instructive and raise everyone’s ability to use their apps to their fullest instead of the current trend of lowering true usability in the name of a nebulously defined “simple.” Things don’t need to be simpler, they need to be clearer. Time and again, “refer elsewhere for what this means and what your option are” is as helpful as no reference at all which is also increasingly common. Again, it all comes back to breaking out of the page metaphor rut and using information displays to display the right information when and where it is needed in addition to making altering the information consistent, reliable and discoverable vs. dumbing everything down hoping your user base instinctively gets it. Sadly, in my experience, the saying “Invent something fool-proof, and a bigger fool will appear” is true. So, instead of going “down,” go up and expand sideways — and take everyone with you.
Thanks for reading.
*UAF: can stands for a few things. It is similar to “PBKAC,” but it’s about programs designed by people with no understanding how others will use them.