Originally published: Jan 09, 2003
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.
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.
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.
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 experience 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: you can 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'd had tremendous experience 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 experience with 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.
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:
In contrast, users of ring applications display different patterns:
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:
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 considering 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. •
Read related articles: