Form, Function, Emotion
Inside the philosophy and process of Frog Design
by Jennie Rose
May 2002When it comes to surviving in a rapidly consolidating market for design services, possessing a pool of design talent and an entrepreneurial spirit is only half of the solution. The other half, according to Mark Rolston, VP of Creative for the Digital Media Group at Frog Design, is found in the "gray space."
For Frog Design, the German firm that designed the Macintosh case for Apple, the gray space is the convergence of business, engineering, and interaction. When focusing on a product's usability, these areas can't be isolated. "Too many design studios started to fail in 1999 because they had convergent problems and were dealing with them in segmented ways," says Rolston, who launched Frog's digital media group in 1994. "Studios like Organic and Razorfish screwed themselves," he adds, bluntly. "They had monkeys doing Photoshop work who did not understand the business problems. They were handed usability designs where the usability designer didn't care about how [the product] looked."
Founded in 1969 as Esslinger Design by product designer Hartmut Esslinger, Frog branched out to the United States from Germany in the 1980s, and moved into brand design. Frog's philosophy calls on the company's employees to regard product, brand, and user interface design as "inextricably linked."
Redesigning SAP
In the Digital Media Group's early days, Frog had its share of straightforward Web design projects. But the group's standards and practices turned a sharp corner in 1998 when SAP, the world's largest enterprise software company, hired Frog to help improve the look and usability of R/3, SAP's enterprise resource planning suite.
"With SAP," notes Rolston, "we cut our teeth on developing a methodology for defining design solutions at a less literal level, and at a more abstract, procedural series of layers." In effect, prompted by the practices of software engineers, the Digital Media Group began to objectify the design process. To explain, Rolston refers to the levels of abstraction that programming languages have gained over the years. "When I was a kid playing with computers, if you wanted to program the Commodore 64, you could write in Basic or you could write in microcode. There was no level of abstraction there," says Rolston. "Nowadays, even the OS is made up of several layers of abstraction. All of it is meant to further remove us from having to be more detailed than we need to be at any particular time."
In programming scenarios, it's often more efficient for developers to talk about objects than about specific lines of code that represent an idea. The group at Frog feels that the same is true of Web design. Using the example of the graphic artist who will "fuss and fuss over the right shade of blue" while failing to see the bigger picture, Rolston says his team approaches things from a bird's eye view to create a kind of meta-design in layers before delving into production. The goal is to find a common taxonomy to discuss both problems and solutions. "Too many design conversations happen without an agreed upon language," says Rolston. "[We need] a taxonomy in the sense that letters make words and words make sentences and sentences make paragraphs. There's layering even inside of thatof different meaning and formalityand all of that is agreed upon before you've even written a word."
Layers of abstraction don't necessarily mean that software engineers are always efficient. In most cases, standard control libraries (like collections of sliders, trees, lists, and tables) provide developers and designers with pre-built widgets that save time when building applications. With SAP, however, the developers had a non-standard control library overrun with duplicate controls. Frog immediately went to work producing a smaller list of uniform controls that SAP's developers could use for each problem. "If they had 20 table controls, we reduced it to one," says Rolston. The group defined a smaller, universal library of widgets from which application interfaces could be built. Each widget now has its own set of rules for how it can be used and displayed. For example, if a button has a label, the rules define where next to the button the label will appear.
As with any borrowed idea, a bit of adaptation and refinement was needed. For example, the group quickly realized that control is a word with mixed meanings. Some Web site elements do more than control a functionthey take on properties and functions based on their content, or on surrounding elements. To better explain how Web pages work, Frog adopted an atom and molecule metaphor. The metaphor defines a Web page as a series of molecules. Molecules are groups of elements called atoms, like buttons and labels and textfields. The molecules adhere to global branding guidelines that define attributes like color, type, voice, and content.
According to Frog's system, content has its own layers. For example, a page could have business content and a second layer of product content with its own voice. Likewise, visual content, such as photography and charts, will have styles that relate specifically to it.
Figure 1 shows the SAP R/3 interface. Launched in 1999, R/3's new look was a big hit with customers, many of whom were pleasantly surprised by the shift from a black and white interface to one with full color.