It never occurred to us that users would exhibit multiple personalities when using applications. At least, not until we met Chip, an auto-repair garage owner in Lawrence, MA.
We were conducting a field study, looking at small business owners, when we met Chip. His business is a $2 million-a-year venture that employs four mechanics, a tow truck operator, a receptionist, and several part time employees. Chip's business isn't huge, but it is profitable and certainly respectable.
As part of our research, we were visiting the businesses and having the owners give us detailed tours of their operation. We'd spend several days with each owner, directly observing each one as they used the technology that helped them accomplish their jobs.
Personality #1: the Computer Novice
Chip's first personality came out as we saw him working with the software he used to keep track of the garage's finances. While using the software, he'd displayed typical behaviors we'd seen many times before.
He was extremely timid with the software. He'd told us he'd really only explored about 10% of the functionality, afraid that he would possibly do something hazardous to the data, the software, or even his computer. He always accepted the default settings, never customizing the interface, even when it would make his life easier. As we watched him use the software, it was almost as if he was continually checking with us to make sure he wasn't doing something stupid.
As we were watching him, it was easy for us to conclude that Chip was a computer novice. All of his behaviors-- the timidity, the fear, the way he opted for the defaults--told us that he wasn't comfortable with technology. We would have left his shop with that impression had it not been for our second session.
Personality #2: the Expert User
In the second session, Chip took us into one of the shop's bays and showed us how he diagnosed an ailing car. Chip is an excellent diagnostician, who can get to the root of almost any automotive problem very quickly. He's the ideal person you want working on your car if it's making a noise that nobody else can fix.
As we were watching Chip work with the diagnostic equipment (a self-contained PC with 'sniffers' and other input devices that report a vehicle's vital statistics) he was a completely different person. The transformation from the earlier session was striking.
When working with the diagnostics, Chip was extremely confident with the application. He knew many tricks and techniques that he proudly told us he had discovered through much trial and error. He was very particular about the configuration of the unit, having spent significant time customizing the settings to exactly what he wanted. He'd even written macros to optimize certain operations that he frequently performed.
The Distinction Between Core and Ring Applications
When we were done with our observations, we had two separate personalities: Chip #1 and Chip #2. Chip #1 was the personality who operated the financial software--timid and unsure. Chip #2 worked with the diagnostics system as if he'd written the software--confident and fully knowledgeable of its complete capabilities.
We tried to understand where these two different personalities originated. At first, we hypothesized that maybe Chip had only recently started using the financial application, while he'd used the diagnostic application for much longer. Turns out he purchased both systems at the same time, as the result of a business expansion loan he received.
We then considered that he might use the diagnostic application more every day, giving him more time with the system. However, we found out that he used both applications almost the same every day. He'd go into the garage at 6:30am and work until about 4pm on cars. Then he'd go into the back office and work on the finances until late in the evenings. (The joys of owning a small business--you can work your own hours: choose any 14 hours each day.)
Chip had the same amount of experience interacting with both applications. Then why did he behave so differently with them?
What made the difference were Chip's core competencies. Before Chip acquired the systems, he already had a detailed understanding about diagnosing vehicles. He'd been working on cars since he was 11 years old. He knew the workings of automobiles inside and out.
Therefore, when he purchased the diagnostic system, he was looking for an extension of his existing skill set and knowledge. The system was basically an extra set of hands, allowing him to diagnose cars faster and more effectively, but not doing anything radically different than what he was doing before he'd gotten the system.
The diagnostic system is what we call a "Core Application" in Chip's case. Core applications extend the existing core skills of the user.
The financial system is what we call a "Ring Application." Ring applications deliver functionality that is beyond the user's core competencies. (We call it a *ring* because it is outside of the *core*.)
When Chip purchased the financial system, he'd had virtually no knowledge of small business finances. In fact, he'd told us the reason he got the software was his accountant had threatened to quit due to Chip's inability to properly keep the books by hand.
Chip was looking for the financial system to be an extra brain, providing expertise and knowledge about bookkeeping that he didn't already possess. He looked to the software to give him solid advice on how to run his business, something he would never permit the diagnostic software to do.
The Behavioral Patterns of Core and Ring Users
This distinction of Core versus Ring has helped us understand user requirements a lot better than any previous model we had. Over the years since we first developed the model, we've seen patterns in the behaviors of users of core applications:
- They are comfortable with domain-specific concepts, jargon, and abbreviations. When the application is "dumbed-down" through the explanation of concepts and jargon, they grow impatient and seem to resent it.
- They come to the application with established processes and procedures that they aren't interested in revising because the software does it differently.
- They are willing to customize the software to fit their specific needs.
- They'll explore the software willingly, trying out features and options, looking for ways to be even more productive.
In contrast, users of ring applications display different patterns:
- They need concepts and jargon explained in plain language or eliminated entirely.
- They look to the application to suggest procedures. (For example, Chip wanted the financial software to walk him through the end-of-year closing process.)
- They'll usually accept all of the application's defaults and standard configuration settings. For many preferences, they'll defer to the application for its expertise.
- They rarely explore options in the software. If the package doesn't directly guide them to functionality, they're unlikely to discover it. Fear of "breaking something" constrains their behavior.
An Application for Multiple Personalities
A given application could have two separate interfaces to serve these different types of personalities. For example, designers could create a tax preparation package for both individual taxpayers, who would be ring users, and for tax preparation accountants and lawyers, who would be core users. However, the interfaces would have to be different:
- The ring users would expect tax law to be explained simply. Any choices the user has to make, such as calculating the number of deductions, would probably involve several screens of explanation and be broken into a multi-question wizard to end up with the correct number.
In contrast, the core users wouldn't want definitions of deductions. They'd probably just suffice with a single box to enter a number, having done the calculation quickly in their heads.
- The interfaces for core users would need to support many different taxpayers, whereas the interface for ring users would probably only have one or two taxpayers in a household. The wide variance in the types of taxpayers (for example, corporations, partnerships, and personal) would demand real flexibility for the core user package that probably wouldn't be required for any of the ring users.
- The designers of the core package would need to do a fair amount of research of tax prep professionals to understand how their businesses operate, learning what kinds of reports are needed, how data is entered, and other procedural details that currently exist. The goal is to identify opportunities to make the users more productive.
The designers of the ring package would want to experiment with making their users comfortable, looking for places in the application where the tax preparation process frustrates or overwhelms the user. In this case, looking for opportunities to simplify the complexity becomes the primary goal of the research.
How do you know if you're building an application for core users or for ring users?
Well, you'd want to look at the expertise of the users. Have they received significant external training on the domains involved (such as tax rules)? Do they already have established practices for handling these activities? Are they familiar with jargon and concepts?
If your answer for these questions is "yes," then you're probably dealing with core users. Otherwise, you'd want to strongly consider developing an application that you tailor for ring users. We've found that once we can identify which personality the users fall into, it can give the design team clear direction for producing an interface that really delights the users.
