|The Brand as an Asset – The Five Evolutionary Steps to Creating a Brand|
|Branding Hearts and Minds|
|Themes, Schemes, Skins, Shells, Bells and Whistles|
|frog design Website|
|Resources: Visual Design|
Several years ago, I wrote an article for the debut of the SAP Design Guild that discussed the primitive state of branded GUIs for enterprise applications. At the time, the act of applying any sort of brand language to enterprise software was an adventure. Even the art of applying color to an interface was new. Most enterprise applications emulated the plain gray Windows environment and were brutally unfriendly to use, complex, and just plain ugly. Things have improved with many enterprise applications, but certainly the industry as a whole has a long way to go. Part of this evolution has been in the flexibility of enterprise software to express personality – and not just the personality of the software vendor, but that of the company that purchases the software, and the user that operates the software.
The process and environment for developing GUIs is getting sophisticated. User experience design, like technology development, is becoming a multi-tiered environment. Even more important, the control and responsibility over each tier is being distributed within organizations, and in many cases, across multiple organizations. This distribution of control and input, into what can be summarized as the user experience, we can call the user experience development "food chain". This metaphor describes a chain of players that define a user experience: starting from the software's initial inception with the application vendor, to the outside consultancy that custom fits the software to a customer's needs, the customer's IT group that distributes and manages the applications, and lastly, the end user that ultimately must put the application to use. This food chain is becoming a critical consideration in the development of a software brand experience. It is no longer reasonable that the vendor determine a fixed visual style for the user experience and expect that the integrator, customer, and user settle for this design. The integrator now requires flexibility to adapt the UI along customer requirements. The customer requires the ability to further adapt the UI to corporate branding standards, and even the user has a desire to personalize the interface.
To help illustrate how we arrived at our current methodology, it is helpful to describe our experiences over the last several years of SAP application design: In 1999, we (frog design) began working with SAP to design a new interface for R/3 (v4.6) that was determined to bring a new level of flexibility and quality to the user interface (see figure 1). The new design incorporated three layers of branding to allow SAP, the application integrator and/or customer, as well as the user to jointly control the visual experience. As the first layer, the SAP brand was strongly reinforced through the prominent placement of the SAP logo and the shape of specific onscreen controls. These controls were given a unique design quality that could immediately identify them as "SAP" when compared to generic Windows controls. At the second layer, specific areas onscreen were defined for a customer logo. Also font and interface colors could be modified to align the interface to a corporate brand. Lastly, at the third layer, the user could also modify certain background color attributes to suite their personal taste (see figure 3). Together, these three layers define shared control over a common experience for the user.
Figure 1: In the background, an R/3 screen in the standard Windows look; in the foreground, the same application in the Enjoy look (R/3 v4.6)
Figure 2: The R/3 blue bar, always placed at the very top of the application window, visually differentiates SAP software from other applications on the user's desktop
Figure 3: Another differentiating characteristic of SAP software is its sophisticated and customizable color palette, comprised of colors that are easily viewed over extended periods of time
Since that initial project, SAP and frog have worked to improve this methodology. SAP customers caught on to the opportunity to customize the software and demanded more flexibility and control over the experience. Together we have evolved the experience over several generations of Web platforms. Our initial approach involved increasing the flexibility in modifying key bitmaps, colors, and widget appearances. As we developed more sophisticated ways to inject personalization and customer brand into the interface, we eventually realized that customers want so much flexibility and control over the user experience that we needed a more radical approach to the problem.
Figure 4a-b: Example of older SAP Web applications with GUI-like branding elements
This brings us to 2002 and the most recent solution to the demand for complete interface flexibility. Ultimately, achieving this goal requires that we have the confidence that despite such extensive customization, the interface will always retain a minimum common experience that can be identified as the SAP brand. Similarly, in the early 1980s, MTV (Viacom) demonstrated how a brand can be both incredibly flexible yet retain a common set of attributes that give it universal recognition. MTV allowed their logo to be rendered in any possible texture, shape, material, and color just as long as the basic outline of the M and the TV were always identifiable. It was a powerful example of brand flexibility. Today, the SAP software design language shares a similar philosophy. The system is designed to allow an almost infinite flexibility in color, dimension, font, and other attributes.
Figure 5: Variations of the current MTV logo
So, given this idea, what ingredients are available to a designer to determine a software brand, and which of those ingredients should be made adjustable by the customer?
First and most obvious are the parts of an interface that can convey the most personality. Typically a Web application has space for a masthead bitmap, often spanning the width of the masthead. This is the easiest place for a vendor to put the application brand, but also the first place a customer will go to customize the experience. We recommend for most designers that you provide a clear delineation between masthead decoration (the bitmap) and masthead functionality. Without this a simple desire by the customer to modify the appearance could end up impacting the functional quality of the masthead.
Most icons within an application will be the last thing a customer changes. They are often too tied to functionality, and unless you do a horrible job of designing them, the customer will not be inclined to change them. This means there is a reasonable confidence that the icon language will retain the original vendor design and can be used to convey part of the vendor brand language story. Also, icons can provide an obvious visual relief to an otherwise plain interface. If the application has a few, fixed universal functions, designing beautiful icons for those few functions can provide a nice aesthetic touch. However, this can easily become a problem if this causes undue visual emphasis on otherwise insignificant functions.
Figure 6: Icons used in the system toolbar of the R/3 system
This attribute comes in both obvious and subtle flavors. Attributes such as corner radius or angles to group boxes, buttons, and other shapes are more obvious qualities of a visual style. If you are planning to create a user interface that allows deep customization, these attributes will be critical to adapt the visual style to a specific customer brand language.
Figure 7: We leverage the 45º angle from the logoform to other design elements, in order to subtly reinforce the brand
Figure 8: Example of an R/3 screen showing elements with characteristic shapes based on the 45º angle
Creative shape attributes such as rounded corners tend to demand more sophisticated presentation layer coding, such as more detailed table definitions, or even worse, bitmaps within a control's definition. Because these design attributes add complexity, it is very important to understand that modern Web applications are constantly being developed with performance as the top criteria. Given that Web app performance is almost always at-best, slower that a similar desktop application, these design attributes of a Web application cannot get in the way of performance. Our most recent experience with the new SAP Design Language demanded that we create a visually flexible appearance without the use of many bitmaps. That meant that most onscreen elements use rectangular shaped objects. Because of this, the following attributes became even more important.
Most often, when a designer wants to inject personality into the appearance of an interface, they turn to shape. Because high performance Web applications tend to limit shape flexibility to mostly simple shapes, line becomes a very important attribute. In the new SAP Design Language, line thicknesses are varied to signify how one region encompasses or is separated from another. The lines play both a decorative and functional role. Because they are so prominently used in the new design, modifying their thickness or color creates radical shifts in the appearance of the interface. And ultimately, the interface can be dramatically modified by defining specific lines to be invisible (equal to the background color).
Figure 9: Lines play an important role in the R/3 user interface; for example they help users to associate a label with its corresponding input field
These qualities are the least recognized and perhaps the most fundamental in establishing the overall gestalt of an interface. Negative space is defined as the widths and heights of gaps between objects. What amount of space defines the gaps between group boxes, buttons, and form elements. How consistent are the measurements to each other? More than any attribute, the consistency of special values defines the overall impression of quality in a software experience.
Figure 10: Negative space helps users to group screen elements
It is important to note that the special relationship and alignment of objects are two attributes that requires the most attention and shared responsibility between designers and developers. A designer can easily identify ideal ways to lay out specific content on a screen, but the design can fail if the software has to be able to automatically lay out infinite combinations of objects onscreen without any human intervention in the process. In this case, the relationships of objects must be defined at the control-level so that the extent of their combinations always create aesthetically pleasing and consistent spacing.
Scale is a similar attribute. For example, the proportion of text labels to header or button heights for example will define whether an application feels crowded or open. And the consistency of object sizes throughout the screen will also lend a sense of quality to the overall experience.
Figure 11: Proper scaling helps users to gain a quick overview
This attribute is easily the most difficult to define in the design process. It is not typically because of technical limitations, but because color is perhaps the most disputed attributes of personal, cultural and functional taste. We have learned the hard way. No one will ever agree on a color. In 1999, we were given license to introduce defined color simply because it was a precedent to move away from the Microsoft Windows gray world view. Today it is critical to provide color flexibility. With SAP, the original R/3 color system allowed for only two background color changes. Even then, we narrowed the range of color shifting to avoid usability problems. Later systems retained a set of key SAP brand colors such as the SAP blue, but opened up the control library for extensive color modification. The latest design offers complete customization of every color attribute in the system.
Figure 12: Example of a screen from the newly released SAP CRM 3.1 before (on the left) and after (on the right) customer rebranding showing the latest design's flexibility in color customization
There are a few key practices that can help in the definition of a color system for a user interface:
This describes any number of onscreen elements that are not easily identifiable, yet still contribute to the overall appearance. Simple attributes such as shadows beneath boxes, lines, and various controls can easily create a dramatic 3-dimensional appearance. Simple decorative shapes at the extents of controls can give them a unique personality. In the new SAP Design Language we defined simple boxes at the left end of headers, title bars, and form elements that lend some subtle functional value, but for the most part, offer a certain affectation to the overall visual style. More importantly, the color and size of the extra boxes can be modified to affect the style of the interface. In another example, the tab control of the new language has one of the few bitmaps found in the design. It uses a 45-degree angle to lend a visual break from the common horizontal and vertical form of the interface. It also happens to correlate nicely with the angle in the SAP logo.
Figure 13: Here we balance 2-D forms with 3-D forms in the R/3 GUI to serve as both a sophisticated visual effect and a visually intuitive indication of various control surface capabilities; all clickable elements have 3-D qualities, while the input and output fields remain 2-D for simplified reading
In general, when designing a user interface that is technically constrained, for performance or other reasons, the effective use of a few key onscreen elements for decorative qualities can be used to enhance the overall appearance as well as provide yet another point for customization.
In summary, in putting together a flexible UI system, there are some easy methods to apply:
Right now, the attributes and parameters of visual design vary dramatically between applications. There is little consistency. The opportunity going forward is the establishing of a common set of design parameters, such as color, that applications can understand, and even read into their own environments. Ultimately, an OS might even provide a repository for a universal style sheet that any application could read and apply style into, regardless of technology. In one future scenario, a user might use a style sheet to skin the Windows OS according to company colors. The SAP portal environment could then also read the same style sheet and apply the color system in a consistent way. Even sites like my.Yahoo.com could read this system and offer the option to base its experience on the same style sheet.
Another hope is the extension of personalization attributes beyond visual style into control-level customization – eventually blurring the line between style and functionality. Even the behaviors of widgets could be customized to be serious or frivolous to be part of a personal or brand experience. Does a drop down menu just appear quickly with no fuss, or does it unroll like a roll of paper? The pragmatist in you may scoff at ideas like this, but these small attributes are the critical elements in modern products that make them unique. The highly personal opinions of Linux, Windows, and Macintosh users demonstrate this is already the case at an OS level. More obviously, we don't choose between a Ford and a Honda based solely on functional merit but more importantly because the many small attributes such as the door handles, motor sound, and seat controls appeal at a deeper personal level. Software can appeal to users in the same ways. It is our job as designers to identify user interface design attributes, define their ideal values, and open up the control of design attributes in creative ways to the customer and empower them to control the user experience alongside our own designs.