Out of Overload

In most technology environments, software plays an active role in the workflow. Applications store data and may control operations. If two-thirds of industry shops are users, the others are creating the software itself. It seems like everyone is involved with software in one capacity or another.

Unfortunately, software is a serious contributor to overload. Complex applications force you to decipher a path through their operation; less behaved software requires that you understand and work around its bugs; and some software makes you learn a scripting language for customization. On top of that, you may need to change your operation to fully use the application's features.

Add up all these stray facts and your overload increases. With some software, however, this isn't a problem. At a glance you understand the functions, and everything for your operation is within reach. Design is the key. With the right design, things go more smoothly and the entire process is intuitive.

Ideal designs are not common, but it's not the fault of the individual developers. Two obstacles stand in their way. They don't have the time to design the user levels properly, and even if they did, they're not sure how to approach it. With so much focus on core functionality, it's rare to find a developer who has a feel for other design stages.

The following sections outline the design issues that make software difficult to use. With a fresh view of the link between software and overload, you should be able to reverse trend. As a user, you can push your vendors to shape applications to fit your operations. If you're a software developer, you'll be able to distinguish design issues from coding practices and produce a more usable product.

Software Developers

Design problems begin with the software development environment itself. It's tense. The demand for applications has made software developers among the most overloaded. Their missions are a tangled web of requests: they must untangle legacy code built by someone who left three years ago; they must get customers up and running in time zones spanning every hour of the day and night; and their current products better not be late. Software developers are all too familiar with overload.

The frenzied pace creates a problem -- expediency is king. Project leaders have little choice but to focus on delivering the precise functions that are specified. Developers seldom have the leisure or the freedom to shape the user interfaces to fit more than one operator's procedures. As a result, most users end up consolidating and restructuring the application's interface as they use the functions. Adding this to their already full load increases their overload.

It's not that the internals aren't structured properly, it has to do with the fit to the user. Improperly designed user interfaces produce overload. The following User Levels offer a framework for untangling this mess of needs.

User Levels

Every end user has specific needs and depend on the software to run their operation. At the development end, the original designers did their best to ensure target customers identified with these functions. A series of Beta sites helped hone the offering further. If customers bought the product, the goal was met.

Frequently, however, designing for a specific group of customers would leave other groups out in the cold. Hence the common line, "You can't please everyone."

In addition to the design difficulties, emotional stances often hinder adjustments and mid-stream corrections. Because of the extreme effort that goes into software creation, developers soon identify with the application. It becomes "their baby," and suggestions or mild criticism are taken as a personal attack. With so many sleepless nights and painful system problems, almost everything about the application is emotionally charged.

Keep the passion about your work. These apps are indeed a part of your life -- they are your creations. The trick is to look at these criticisms in a more useful light.

Comments on software complexity are really requests for specialized interfaces. Users want the application to function in a way that makes sense to them. Because users vary, these suggestions seldom consolidate into consistent requests, and they can feel like meaningless criticism.

The following method translates interface requests into software design categories.

Breaking the user population into User Levels allows you to address multiple needs. As simple as that may sound, it's in sharp contrast to making an application be all things to all people in one pass. The model must expand.

The most common User Levels:

Each level needs its own design plan. You'll be surprised how much easier it is to address a broad base of requirements with these design levels.

1. Core functions.

When a software project is first created, internal calculations are the critical elements. Taxes, for example, need to come out correctly; the database must return the right records; and indexes must function according to the specification.

Initial development focuses on core functionality. And rightly so. If the core features aren't accurate, you don't have a product.

Constructing the core functions takes effort and tenacity. System pitfalls must be solved, and thousands of design details must be chased down. When the base product is complete, it's a major milestone. The event can seem like the end of the project.

2. Using the functions.

In reality, the project is far from over. And in many ways, adjusting the application to the user is as important as the internals. If the end user struggles to make your system work, they will jump to the first reasonable alternative. Brilliant functions can't counter the fact that no one will buy it.

The next phase shifts attention to the user. Operators need a way to activate the application's functions. Today, GUIs (Graphical User Interfaces) are the common vehicle. There are icons to click on and buttons to select.

Direct Tie

The Direct Tie method connects each internal function to an external activation point. If, for example, there were twenty-eight functions, the interface would consist of twenty-eight buttons. These ties give users access. Its shortcomings surface, however, when the complexity increases. In cases where the application has three thousand selections, any Direct Tie method becomes overwhelming.

Shaped Interface

Early attempts for more simplified selections involved menu trees. Actual activation came last, and you selected your way to the functions you needed. Again, these weren't too bad until you found yourself navigating through hundreds of menus.

Wizards help consolidate choices. Their increased error checking and prompted selections have reduced the number of incorrect configurations.

At the high end of the Shaped Interface continuum, profile inferences about the user operation establish a set of default configurations. These settings are then presented as a configuration overview. Summary screens allow the user to customize defaults to their operation.

3. Managing the process.

When using complex applications, managers want to complete their tasks and ignore everything else. The less they have to distract them, the better. Software products should facilitate this selective perception.

Whether through Wizards or hidden features, managers want to focus on functions tied to their operation. Even then, they would rather not be overwhelmed with details that aren't critical at that moment.

4. Status view.

Experienced managers have alarm levels in their head that trigger when error conditions occur. For most of these warnings, early detection is essential -- every operations manager wants time to react before conditions reach crisis levels.

For software developers, the need for status and alarm notifications means adding a layer that summarizes the output of active processes. This might include a network status, a list of deliveries coming in that afternoon, or a weakness in staff scheduling.

5. Overall management.

Once operations reach a certain size, trends become more important than individual pass/fail statistics. The total sum of alarms and error conditions dictate policy and plant-wide shifts rather that specific adjustments. Information needs to be consolidated and profiled to the point where it facilitates larger inferences and decisions.

6. Enterprise level.

At the enterprise level, software developers must take the broadest view.

When business expands to several plants, trends and profiles take on an added importance. Consolidation software functions must point out regional and operational differences. It should aid corporate management in leveraging individual strengths and propagating best-of-practices throughout the enterprise.

Overview

Software applications with all six User Levels are rare. The more they connect to these levels, however, the more users embrace the product. Each level addresses part of a customer's operation. If you hit more than a couple of these areas, you are on the way to building genuine customer loyalty.

A majority of applications don't make it beyond User Level two. Anything above that places you well ahead of the crowd, and you'll be reducing the world's overload.