Case Study: Elemental Drumbeat

Case Study: Elemental Drumbeat

One of our more interesting design projects was for a small start-up company in San Diego named Elemental Software. Its product, Drumbeat, is an authoring tool for creating dynamic, database- backed Web sites.

The cast of characters we developed for Elemental was indispensable , even though it consisted of only two very simply defined personas lacking even last names . ^[6] By creating these two personas and understanding their goals, we gained radical insight that changed the entire design philosophy of the product.

^[6] Actually, the full cast of characters had more than two personas, but Betsy and Ernie stole the show.

From the beginning, Elemental had set its sights high. Elemental wanted to create a program that was far more powerful than any other competitor's. It also wanted to make its program easier to use than any other. These goals were not at all incompatible. Most of the trouble we had arose because Elemental had acquired an existing product from another company, and we had to build on top of an existing code base. There was constant confusion between what we wanted and what we already had.

The existing product had some powerful features, but it had been constructed with a muddy user vision. None of the features was easy to use, and the effect was a not-very-powerful product. Ed Forman, the new VP of development, took a gamble by bringing in Cooper Interaction Design. He was himself new enough that he hadn't fully earned the trust of his new programming staff, and our presence could have ignited revolution. Ed was an excellent champion, however, and he gave us considerable time with his team to get to know them and to let them hear about our methods .

The Investigation

For our investigation, we interviewed several people, primarily Webmasters. As we proceeded, we saw a clear pattern emerge. The world of Web authoring was neatly divided into two camps. Of course, we defined a representative persona for each camp, and these two became the keys that unlocked the entire Drumbeat puzzle, though not in the way we anticipated.

Within just a few days of starting, we were able to name and roughly describe our two Web builders, named Betsy and Ernie.

Betsy is an artist. She wears black and drinks espresso. She used to be a graphic artist but got bitten by the Web bug, and now she creates screen layouts instead of page layouts. She has read enough books to teach herself how to build nice-looking—but simple and static—Web pages. She has mastered the basics of HTML, but she knows —and cares—nothing of programming. Betsy's own Web site is a model of cool hipness, with subdued typography, swathes of asymmetrical pastels, and quotes from Patti Smith and Esther Dyson.

Every time Betsy needs some advanced processing, she must appeal to Ernie. Ernie is a new-age programmer geek. He loves computers, computer games , computer languages, and computer equipment. Compared to older programmers, he's still kind of lightweight: He doesn't know C, C++, or assembler language, but he is an incredibly facile user of hacker tools such as CGI, Perl, JavaScript, and Visual Basic. He knows hundreds of ActiveX controls and JavaBeans. He can assemble a significant amount of functionality from complex components in just a few days that would have taken a C programmer four years to build back in the 1980s. Ernie's own Web site is a random collection of Star Trek iana and Simpsons quotations. It uses garish red text on a black background, eight different typefaces , blinking text, streaming audio, jitterbugging icons, Submit buttons , and links to the coolest Quake sites.

It was quickly apparent to us that the Elemental team had, without a clear vision of Betsy and Ernie, been developing a program that tried to make them both happy. The result was a fuzzy concoction of powerful and complex features in a graphic presentation. They'd say, "Look what new cool thing the user can do now!" Their "user" was elastic, and they didn't have any idea of his goals. The programmers at Elemental were generally sympathetic to Betsy but, being temperamentally more akin to Ernie, their product had naturally tended toward Ernie's needs.

After we introduced them, the entire company immediately recognized both personas as extremely familiar archetypes and seized on them as useful user definitions.

Who Serves Whom

Visual tools for constructing Web sites was (and still is) a hot marketplace , so there were plenty of competing products, but for the first time our client could assess itself and its competitors relative to Betsy and Ernie.

The competitive market had also split along the Betsy/Ernie division. On one hand, several other Web-authoring-tool companies were writing cool new tools for Ernie. They were all complex and hard to use but let Ernie create powerful, dynamic, and sophisticated Web sites for corporate clients .

On the other hand, some other Web-authoring-tool companies were writing cool new tools for Betsy. They were all simple, visual, and easy to use, but they were all weak as kittens. They could only be used to build static sites with weak functionality, completely disconnected from any outside databases.

After we could see the landscape through the Betsy/Ernie lens, it was clear to everyone that the big opportunity was to provide Betsy with a tool giving her far more power than she was used to. This would give Elemental a desirable product in an uncrowded part of the marketplace. The programmers soon adopted "Betsy" as their rallying cry and focused their efforts on helping her.

This was a good starting point, but as we proceeded with our design efforts, we looked more closely at Betsy's goals and discovered an interesting thing.

In the old world of simple, static, first-generation Web sites, Betsy was independent. She could design and build a Web site for a client without any help from Ernie. Because it was just Betsy doing what she was experienced with, she could tell a prospective client how much work was involved, what it would cost, and when it would be done. She could confidently expect to deliver on her promises. That independence and self-determination was what attracted her to the Web in the first place and what convinced her to give up her day job and become an entrepreneur.

As the Web evolved, it rapidly became more powerful, but it also became much harder to build sites. Web sites were now increasingly dynamic, had more functionality, and directly accessed databases. Betsy couldn't do this level of geeky , programmer stuff. Besides, it wasn't that much fun for her, and she didn't want to learn. That's when she met Ernie, who could solve all of these technical problems for her. He loved all of this geeky stuff.

But Betsy found that she was now dependent on Ernie to deliver a finished product to her client. For every new Web site she created, at some unavoidable point during the process she had to find Ernie and get him to install the database access and the dynamic page-composition code. She could no longer deliver a finished Web site without using Ernie, and he wasn't anywhere near as punctual as she was. She could no longer give her clients a due date and have confidence that she would deliver. Ernie's randomness upset her business. A somewhat different picture of Betsy's goals began to emerge.

Although Betsy still wanted to build a cool, powerful, dynamic Web site, that was not her most important goal. What had been a hygienic goal, and one that she had taken for granted, was her independence, but as soon as it was gone, it became dominant. Her most important goal was to be independent again, liberated from Ernie. She wanted to be able to strike up a relationship with a client, and then design, create, and deliver a beautiful, powerful, dynamic, database-backed Web site without ever having to wait while Ernie puzzled out some technical problem .

Our original vision had been to make Betsy's Web-building tool even more powerful while remaining easy to use. Although this was still very desirable, it merely delayed the time when Betsy would have to seek Ernie's help and wouldn't meet her most important goal. To succeed with Betsy, we had to design Drumbeat so that it would allow her to complete projects all alone.

Ernie wasn't all that happy working with Betsy, either. He needed to get all of his work approved by Betsy, and she was always nagging him about a pixel here and a pixel there—stuff he considered immaterial. She demanded that he rework things five or six times, making irrelevant (to him) changes before she was satisfied. He wanted to be independent of Betsy as much as she wanted to be free of him.

The Design

We were now able to make a very clear and simple case. Instead of delaying Betsy's need for Ernie, we had to put up an impenetrable wall between them, granting independence to both of them. Betsy still needed the functions that Ernie created, and, after all, Betsy was a great source of work and revenue for Ernie, so there still needed to be commerce between them, but their jobs had to be fully disentangled.

This meant that the wall between them had to be a common standard—an interface—for creating and using functional modules. It had to give Ernie a programmer's interface, so his code could be connected to, and it had to give Betsy a Webmaster's interface, so she could create her sites. The Drumbeat program would be the common, neutral ground for both of them. Ernie would write powerful, flexible modules and publish them by using Drumbeat's functional interface. Betsy would use those modules by using Drumbeat's visual programming interface.

Betsy could now create dynamic, database-backed Web sites using published modules, yet never meet their author. Ernie could write, publish, and sell functional code, without ever having to change background colors. By freeing them from each other, we leveraged Betsy's design-and-production skills and also leveraged Ernie's programming skill.

Ernie now finds himself in the role of tool builder instead of custom programmer. He creates plug-compatible code modules that can dynamically become part of Betsy's toolkit. His modules have a wider audience because he can sell them to many other Betsies, who can in turn use them in a variety of other sites.

This is an interesting case in which the interaction design had significant effect on both the internal structures of the program and the way it was marketed. It is a good example of how design affects the inside while specifying only the outside.

Pushback

The Elemental software engineers were reluctant at first. They thought our solution wouldn't work because they imagined several edge cases in which Betsy would still need Ernie's special talents. "You can't take Ernie totally out of the loop," they said, because Betsy might want to do something very special or difficult.

Well, we thought, that is true, but only in a few cases. In most cases, she would be independent, whereas currently she was never independent. For those few edge cases, she would merely be back to the status quo ante of depending on Ernie. This would certainly not make things worse , and in most cases things would be a lot better.

Because Betsy's independence is important to her, she will be willing to make commensurate sacrifices to get it. Because Drumbeat allows her to build Web sites from start to finish completely without Ernie, she is very willing to make minor compromises in her design to take advantage of Ernie's canned routines. ^[7] This is not a big sacrifice because not that many clients have demands that are out of the ordinary. If she ever gets the commission to build the intranet for Wal-Mart or the online reservation system for Hilton Hotels, she will certainly need to bring in sophisticated programming talent to help her with those gargantuan tasks , but not for most of her clients.

^[7] Creating Web sites is programming, and Betsy finds herself under the irresistible influence of code reuse.

Other Issues

The original program had many small floating palettes containing various drawing tools. Each palette covered up a portion of the Web site under construction. Everyone at Elemental had somehow acquired the idea that users really liked to move these palette windows to and fro on their screens as they worked. In every demonstration of the product, they proudly showed them off.

Every one on our design team found the floating palettes intrusive , complicated, and completely unnecessary. Sure, the tools were needed, but we knew there were better ways to present them. Every time we said anything negative about them, though, the programmers—and product managers—would tell us how everyone used them a lot.

As we began to watch real Betsies use the product, we soon understood why floating palettes were so popular. The original design made palettes indispensable. Most of the tools on each palette were rarely used, but each palette had at least a couple very useful, very frequently used tools. This meant that Betsy needed all of the palettes to do even a very simple task. Each palette was unnecessarily large because of its extra tools, and the palettes floated over the visual image of the Web site under construction, so, as she worked on the site, she continually had to move the palettes out of her way. An alternative option let her lock the palettes to one side of the screen, but that just meant that Betsy had to repeatedly scroll her work to bring the current part into view. Betsy was stuck between a rock and a hard interaction. She could either spend lots of time unnecessarily scrolling the Web site, or she could spend equal time unnecessarily repositioning the palettes. We call forced, unnecessary actions such as this one excise , and the original program was filled with it.

To solve the problem, we knew that the only tools that should be kept around were those that were used very frequently, and any tools kept around were better off if they stayed in one place. Betsy would be confused if they moved around.

By a simple process of reorganizing the palettes so that they contained only frequently used functions, we made them much smaller. We then fixed them onto the screen in static locations. They now became an almost unnoticed part of the interface. This is a good example of how Goal-Directed design actually reduces the amount of interface code needed.

Both the product and the design have been successful. As the implementation of the version based on our design neared completion, Elemental was able to raise a significant amount of venture capital thanks, at least in part, to the innovations in its interaction. Since its release, Drumbeat has been widely hailed by the industry press. This quote from PC Magazine is representative:

Drumbeat is a unique and impressive product that automates more advanced Web site features than anything else on the market. It lets non-programmers get the job done with drag-and-drop ease. You can build gigantic, professional-level Web sites, optionally using Active Server Pages, without writing a line of code.

The product has been successful, despite the fact that many other Web-site-building programs preceded it to market.

As you have seen, looking at things through the lens of the user's goals can give us a unique and powerful perspective that opens up new opportunities for creative design. This is the core of Goal-Directed design.