Unintended consequences of features: Lessons from an automobile

Posted by Christopher Hill on Feb 12, 2014 9:48:00 AM

Constraints can be beautiful

Several years ago (before I had worked with RSuite), I posted on my personal blog a couple of times on the merits of constraint in design http://blog.chiliarchy.com/search/label/constraint. At that time, I was dabbling in software design but had yet to be responsible for establishing and communicating constraints to the engineers building a software application.

The redesigned RSuite of today often challenged me and the engineering team to balance many competing opinions and interests. With an application offering the flexibility of RSuite, it is tempting to always do more.

Engineers tend to like building things. A good engineer's "can-do" attitude will favor developing enhancements. It's more fun to create new code. Going back through existing code to refactor, trim, or remove can sometimes feel like cleaning out the garage.

Customers often request more, seldom request less

Project managers, the tip of the spear when it comes to customer projects, are also often managing requests for features. Customers tell them they need a button, widget, dial or gadget and it seems simplest to just add it. Rarely does a request come in to remove anything.

Features have immediate and ongoing costs

It's obvious that a new feature costs something to build. Most people consider this when deciding whether or not a feature is worth adding. The more important factor is the long-term costs that aren't so easy to identify. A single button can have an exponential effect on the number of test cases and unintended interactions. Documentation and support have to be revised and maintained. More features often mean more visual elements for users to process when using the software. These penalties often seem relatively tiny when viewed in isolation.

An automotive example

I was on a work trip driving from Minneapolis to a city several hours away in a rental car. I rented a Ford Focus, a car I actually owned in 2000. It was a dark winter night in Minnesota, so I took time to check the lights, made sure I knew to to operate the various wiper modes, adjusted my mirrors, and familiarized myself with the climate controls and stereo.

Unexpected company

After 45 uneventful minutes on the road, I made a quick stop for food then headed back out on the dark two lane highway. Twenty minutes later a car overtook me from behind. Rather than pass, he tailgated for a few annoying miles. Suddenly a flood of police lights had me pull over to the side.

As the patrolmen cautiously approached I fumbled for the window controls.

The car "helps"

As I was trying to unroll the window, the Microsoft Sync voice came over the speakers asking how she could help. I didn't know what I had bumped that caused this but decided to first get the passenger window down. As it opened the patrolman asked for my license. As I retrieved my wallet the car's computer voice told the officer she didn't understand the command, could he try again? I began to try to explain when the car interrupted and began listing some examples of commands she could understand.

I fumbled around for an "off" switch. Suddenly the controls I thought I largely understood were becoming confusing. I turned off the key but she kept talking. I pushed several more buttons. I pulled the key out of the ignition. She kept talking. Then I remembered that the power to the accessories remained on until the driver opened the door. I gently pulled the door latch and she fell silent. The officer seemed mildly amused as he said, "Rental car?"

Good design or a trap?

Ford's engineers had done an excellent job adding lots of additional features to this car without making it seem unfamiliar.

A myriad of optional features were present, but not obtrusive. I had left the airport confident that I could competently operate the vehicle. Under stress, however, the inadvertent activation of voice control had suddenly made me realize the large number of controls I hadn't paid attention to. In my attempts to silence the computer I had tried pressing many of them. Would I regret some of those actions later?

Taillights-off mode

The patrolman informed me that I was driving with no taillights. I told him the headlights were working and that they must have burned out. He said that he had seen this a few months prior on a Ford pickup, and asked me to try all the positions for the light control. I turned the knob to several positions. "That's it. Remember that setting."

While he went back to his car with my license, I studied the symbols on the headlight control. What seemed so natural an hour ago now looked like symbols on an alien spacecraft. The patrolman returned with my license and wished me good night.

A dubious feature documented

I'm still not sure why the car could run with the headlights on and the taillights off. Later I consulted the owner's manual. To improve accuracy and save costs, automobile manuals are modular to accommodate re-use across models and provide for optional features. In the manual, there was what appeared to be a single page showing the use of the lights. No where was there any mention of the possibility of using headlights without taillights.

If you were reading the owner's manual cover-to-cover you'd find two more pages on the lights. When was the last time you've done that? At the end of the third page, below several optional features that were irrelevant and further encouragement to stop reading, was this warning.

describe the image

I had to read it a few times before realizing it applied to me. Although I still wasn't sure how this all played out. Even if we were to move the warning to a more prominent place at the beginning of the section and clarify its language, how many people have read the owner's manual before operating their car for the first time?

A lesson for IT projects

Whether designing a car, creating a piece of software or customizing an application for your organization, managing whether and how features are added is an important activity that is too often overlooked. It is easy to see how a feature might help when used as directed. The real challenge is in being able to see potential unintended consequences the feature may create.

Whether you are designing, modifying or selecting software, it is tempting to just list all the desired features and evaluate its presence or absence. Much harder is evaluating whether the features provided are provided in a usable way. Don't assume that more is always better. Sometimes a feature like "headlights on taillights off" can create problems for users.

If you find yourself having to place warnings or cautions in the documentation you should be reconsidering either the presence of or implementation of a feature.

Software often has an advantage over car design in that it is easier to add custom features to software. The CMS I work on, RSuite, makes it possible to implement features for a subset of users if needed. Sometimes customers complain that some feature isn't included.

Balancing features and design

RSuite has a flexible user interface that can accomodate a wide range of features. Menus can be rearranged and reorganized easily. This makes it not only easy to make product changes, but also can be used if a customer wishes to customize RSuite for addressing specific business requirements.

When developing the product we strive to balance the impact of additional features against the overall product usability. This often means looking for ways to clarify, simplify or modify other areas of the interface. It is also vital to test for unintended consequences that may inadertently create potential problems for users. 

Reflect on your design

A major goal as we work on our RSuite product is to find ways to design RSuite's interface to support the highly flexible architecture while discouraging practices that might create problems that are invisible or difficult to correct. This is a primary consideration whenever a user-facing modification is made to the interface. Even though objective perfection is not possible in any design, we strive to examine each implementation and look for potential refinements that could benefit the product as a whole.

We've made a number of refinements over the last several months from these activities, and have identified more substantial changes that will be rolled out in upcoming releases. Some of these will actually provide additional features to users while reducing complexity.

Potential signs of design problems

There are some areas that often indicate potential design problems. None of these are a smoking gun, but they are good starting points when reflecting on a design.

Does the feature rely on an "Are you sure?" confirmation before performing an action?

Do you find your support staff complaining that users don't read the manual? 

Are you putting cautions and warnings into your documentation?

Do you rely on users to report problems? Remember users often are unaware of problems they may have inadvertently caused - instead blaming the software.

Are there "irrational" complaints or support requests that cannot be reproduced? 

Are there support requests that have been marked "as designed"?

Have you looked at what aspects of product implementation require the most customization effort, documentation effort, or training effort?

More is not always better

Sometimes they are right and we add the feature. Other times the request is narrow, and adding the feature would probably result in more harm than good. It is easy to overlook this whether designing, modifying or evaluating software. Creating a long checklist of features is tempting. But make sure those features don't leave your users in the dark with their taillights off.

Topics: software design, documentation

Behind the scenes: RSuite 4’s Action-based Interface

Posted by Christopher Hill on Jan 9, 2014 9:00:00 AM

In the coming months, I’ll periodically be writing a bit about the design of RSuite 4. It has been very exciting to see the effort and thought we put in to the user experience translating into a much improved experience for our users.  

RSuite 4: Unnaturally Natural By Design

Many of our new customers starting out with RSuite 4 may not be aware of the effort required to put together such a natural design. It’s easy to forget that thousands of hours of thought, design, and refinement by many people are usually behind those interfaces that seem so effortless. Starting now and for several months I will be periodically posting this series of behind-the-scenes discussion of RSuite 4. Along the way you will have the opportunity to get a taste of some of the major challenges and opportunities when designing software user interfaces.

Indirect Action Traps Unsuspecting Users

Traditional content and asset management users might click on an image then scoot up to a toolbar or some menu to conduct an action.  You might find the preview button on the toolbar. Click it and the selected image is previewed for you.

This works fine if users operate with a clear understanding of what item they have selected as well as an action’s area of effect. Accidentally clicking the mouse or forgetting about a change of selection and users may find they've acted on the wrong item. With each mistake an inexperienced user’s confidence is eroded, often snowballing into more errors. Not only are inexperienced users struggling to get their work done, now they have to undo their mistakes. If they can find them...

Look at the RSuite 3 screenshot. The selected item is clearly identified with the orange highlighting. Bump the scroller on your mouse, however, and that orange item can slide out of view. The toolbar, though, remains visible and is still ready to act on the now-unseen item. If you are sure that the now-hidden item you want to act on is still selected then you can click the toolbar. Most users lack this surety and instead have to scroll around until they can double-check that the right item is still selected. 

RSuite 3 - a traditional design

After observing many types of users repeat such behaviors in a wide range of software applications, I suspect that users have become resigned to these error-prone designs. They aren't aware that this checking and double-checking is time consuming and directly impeding their ability to get work done.

Context Menus: A Step In The Right Direction

In the mid-90s mainstream computer software adopted context menus, menus accessed by right-clicking an item and selecting an action to take from a flat list of menu items. Context menus had the advantage of providing users a direct action interface. Right click an item and a list of actions relevant to that item are displayed. It was definitely a step in the right direction. Web applications like RSuite 3 typically offer context menus.

Context menus were great for users who figured out how to right-click something provided the action you wanted to take was present in the menu that appeared. But the flat menu design of context menus generally lacks the density of functionality of buttons on a toolbar. So the compromise of context menus is that some subset of available actions appear in the context menu.

A Context Menu or Scavanger Hunt

Most interfaces ended up with many actions available only in the toolbar or some traditional menu structure. It is common to also find a few actions that are only available in the context menu. There also might be additional menus hiding somewhere with the action we need. Inexperienced users struggle to memorize the interface or become a highly practiced scavenger hunters as they try to get their work done.

A careful UI designer will go to great lengths to design some logic into the interface to explain why some actions are in toolbars, others menus and still other in context menus. Unfortunately understanding the design logic usually requires a solid understanding of the application. So users who could be greatly helped if they could more easily act within the application lack the level of understanding of the software needed to interpret the design logic. 

Extensibility Is A Design Challenge

RSuite’s renowned extensibility usually requires integrators find places to extend the UI in order to interact with the user. Should I put a new button in the toolbar? In the context menu? Add to some existing menu? Or look somewhere else? Or maybe put it everywhere? Instead of focusing on the actual business goals, most traditional UI designs bog integrators down in decision-making, UI coding activities and design tasks that are not productive or efficient uses of their time.

In spite of an integrator’s best intention and effort, traditional integration projects can end up producing customized applications that feel more like trying to land a 1974 jumbo jet for the first time rather than doing my actual job. While it is easy to blame the integration team, sometimes you might find that traditional software design and integration points are complicit in the ineffective result.

747 cockpit

RSuite 4: Consistent, Direct, Logical

RSuite 4 uses a direct action-based interface revealed by left-clicking on an item. Long toolbars filled with inscrutable icons are no longer present. Traditional menus are reserved for a few special cases. If a user wants to know what actions are available on any item in RSuite 4, just click it. Every available action for the item they click on is displayed clearly in an action menu.

RSuite 4 interface example resized 600

Want to act on an image? Click it. A menu with icons and text clearly communicate all of the actions you can take. This simple approach means that no experience is necessary to discover what actions are available. Over time, as your implementation changes, users only have to understand the changes to the business-specific actions available. The UI remans consistent. 

Integrators have a clear, consistent design language for any extensions they care to add to RSuite. The application’s logical design greatly reduces the effort required for most common integration tasks. Adding to or removing from an action menu doesn't require any complex Javascript or other UI coding.

Would You Like To Know More?

With RSuite 4 we have worked hard to remove barriers that are still far too common in business applications. If your interested in seeing more check out our online video tour or visit our website to contact us for a demonstration.

Topics: RSuite 4, software design, behind the scenes

Comment below