Design issues for software depend a great deal on whether the market uses it for constant, core job functions, or whether it's used occasionally for light-duty work outside the key competencies.

by Jared M. Spool

While researching at a small automobile repair shop, we were struck immediately by the presence of two completely different computer systems. One was in the garage, with software used to diagnose cars. The second was in the office, and had applications for billing and creating marketing promotions.

The car diagnosis system enhanced what the mechanic was trained to do: fix cars. It had all sorts of functionality dedicated to that purpose. On the other hand, the office applications were designed to help people manage a small business -- something mechanics aren't trained in.

What if you were to find the opposite user: a person who was an expert in small business management and knew nothing about cars? How would these applications work for this person? Our guess is that they wouldn't work at all. The office apps would be too simplistic and under-featured, while the car diagnosis application would be cryptic and foreign.

For the mechanic, the car diagnosis software is what we call a core app, because it is intended to enhance the mechanic's core competencies. We call the office system a ring app, because it helps with tasks that fall outside these core competencies.

Ten years ago, all software consisted of core apps -- no one had the luxury of developing or using something that wasn't essential to getting a job done. Spreadsheets were probably the first commonly used ring apps. Spreadsheets enabled users who weren't programmers to create their own small core apps. For example, a Realtor could write a spreadsheet to calculate the maximum mortgage payment a buyer was qualified for.

Core or Ring?

There are a couple ways to determine whether your application is a core or a ring. The key is to think in terms of the users, not the software

Do users know the domain? An auto mechanic isn't an expert on small business finance, but an accountant is. Therefore, an accounting package would be a ring app for the mechanic, but a core app for an accountant, and the version for the accountant would need to be a lot beefier. Are your users experts?

How much training do users receive? People generally aren't trained to use ring apps, but proficiency with a core app is something they'll put on their resume. For example, law schools teach students to use a research tool such as Lexis or Westlaw as part of their legal training. These products are very powerful, but so arcane that law firms will hire or reject applicants based on which one they know. Obviously, these are core apps. Is training mandatory for your product?

Why It Matters

The distinction between a ring app and a core app affects several aspects of marketing and developing the product.

A core app that is aimed at a ring market is primed for failure, because it requires more of an up-front investment than its users may be willing to tolerate. Consider early versions of WordPerfect; it was a core app for secretaries, who made the time investment to learn its cryptic commands. But for the larger business community, a word processor is only a ring app, and users balked at the effort required to become proficient. Thus, word processors that were easier to learn eroded WordPerfect's market share.

Amount of Functionality

Ring apps tend to be *lighter weight* than core apps, focusing more on base functionality. If you're developing a ring app, the point of diminishing returns from adding more functionality comes sooner than it does for a core app. In a core app, users will appreciate the more powerful and sophisticated aspects of the product.

No More Novices or Experts

We used to think you could divide the world of users into novices and experts, and that features of the product were aimed at one of these two groups. This dichotomy has rarely been useful; it often failed to give us insights into how we should make the kinds of design decisions described below. The advantage of the core vs. ring model comes from the emphasis on what users need rather than how long they've been using the product.

Productivity and Ease of Learning

As a rule, core apps can focus on user productivity, but ring apps must not ignore ease of learning. If you're developing a core app, think *power user* -- shortcuts, codes, command line interfaces, and macro languages. These users will appreciate features that increase the quantity of their completed work without sacrificing its quality.

If you're developing a ring app, think *performance support* instead -- wizards, on-screen instructions, and error prevention. It's unlikely these users will notice a few extra keystrokes.

Technical Detail and Control

Users of a ring application don't really care how the software does something; they just care about the result. Designers of a ring app can think in terms of creating an illusion, shielding the user from technical details. Having the software take actions automatically and perhaps even invisibly may be perfectly acceptable to users. Ring app users don't need to make lots of decisions about how the software does its job, so it may make sense for the designer to set up appropriate defaults and templates to help the user get started.

On the other hand, users of core apps want those technical details, along with a greater degree of control over the software. For example, they want to know which algorithm the software used to perform a calculation, and perhaps they'll even want to choose it. The issue is partly one of trust: because core app users are familiar with the domain, they need this information to feel comfortable that they are getting the same high-quality result that they would have obtained using only their own expertise.

Development Methods

We use the techniques of contextual inquiry and usability testing for developing both core and ring apps, but we use them to get different types of information.

For core apps, we go out and watch users do whatever it is that they do so well. We identify obstacles to their productivity and look for ways that the app can save them time. When we usability test a core app, we determine whether we've given users the power and flexibility they need.

For ring apps, contextual inquiry helps us understand how frequently users need the app and the most important things they do with it. Usability testing will pinpoint what concepts users have trouble with (including concepts that can be hidden because users don't need to know them), and where the interface needs to provide more guidance.

This article originally appeared in Spool's newsletter, UIE (User Interface Engineering) Tips. Visit The UIE website to subscribe, or to read such articles on such topics as: how tabbed dialogs can get designers into trouble, using paper prototypes to manage risk, how to spoon-feed conceptual information using tips and hints, and a comprehensive UI bibliography.

Social networking icons by komodomedia.com.