Out of Overload

A Guide for Technical Managers

Chapter 9
Software Design

User Levels:
1. Core Functions
2. Using the Functions
3. Managing the Process
4. Status View
5. Overall Management
6. Enterprise Level

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.

For example:

Tony could hardly contain himself, "I could not flip'n believe it. They came back with, 'It's too complicated.' I killed myself putting in all their special operations. That's what made it complicated."


Linda recalled the scene vividly. "The guy kept asking if I could get it to work like their old DOS program. I built him a state-of-the-art interface, and he was pushing for three boxes. I wanted to wipe that little smirk off this face."

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:

1. Core functions.
2. Using the functions.
3. Managing the process.
4. Status view.
5. Overall management.
6. Enterprise level.

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.

For example:

Ed remembered the good old days. Starting up the app was simple, just type in: "c:\spapp\test22\tracker3 -m3 -w -j -kit -pass -no -no".

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.

For example:

Bill had worked on the project for a year, and he still referred to the menu map on the wall. There was about 150 menus per tree. And to make matters worse, some of the menus changed depending on previous selections. Just when you thought you knew where you were, the menus looked different.

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.

For example:

Anne began by adding a "show me" flag to each field. By setting the flag with a configuration Wizard, users could eliminate most fields.

Her baking industry customers soon asked for more flexibility, such as, different "show me" configurations for the morning and afternoon shifts. Several also wanted to limit employee access by "show me" levels.

Anne built in an expansion capability which she wouldn't need to support personally. Menus and configuration screens were self-adjusting. If someone chose five items out of 150, those five items would automatically consolidated onto one page, not sprinkled throughout the original 25 pages.

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 example:

Tony monitored incoming quality and acceptance levels. If a vendor started providing products that didn't meet the specifications 97% of the time, he wanted to know.


As a grilled chicken restaurant, it was important he didn't run out of chicken. Bill monitored the freezer inventory personally. He also kept an eye on the perishables' expiration dates. As products approached the cutoff dates, he'd run a special to ensure they moved.


Linda needed to know whenever the product color started going out of tolerance. With enough early warning she could make an adjustment before any material had to be rejected.

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.

For example:

Bill depended on his status summary screen. It listed the state of 24 background operations, each of which he could set to alarm with a red flash, an audible alarm, or a code to his pager.


Bob knew what he didn't want, "Don't show any out-of-tolerance red areas on the screen. We have too many customers around. I don't like them getting the idea we're producing bad product. Just send the warnings to my beeper."


Tony wanted to know when overlapping vacations increased his coverage risk. If he knew early enough, he could get the staff to adjust their vacation plans.

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.

For example:

Tony was surprised by the product rejection profiles. Monday's and Thursday's were the worst. He found that Monday's material sat in the parking lot all weekend, and it picked up a lot of moisture. On Thursday, trash pick-up forced the delivery trucks to use an older driveway to the dock. Three large pot holes were bouncing the boards around.


Linda found about 30% of each shift needed additional training on the new testers. Failure profiles pointed out deviations by tester as opposed to product type.

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.


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.

Go to: | AWSS Main | Previous Chapter | Next Chapter | Feedback: jdavis@awss.com