|  Skip to Content  |  Search  |  Contact us  |  Newsletter  |  Sitemap  |  Article List  |  www.sap.com

Home & Services   Resources   Editions   Community   Goodies

Overview    Editions    Highlight Topics    Articles by Editions    Articles by Topics

Archive - Edition 6: Branding

 To Overview of Branding Edition

Leading Article and Introduction

• Leading Article: The History of Product Branding at SAP
• Branding Glossary
• Branding – Links and Other Resources

All About Branding

• Extending a Software Brand Language Across the Vendor, the Customer, and the User
• The Brand as an Asset – The Five Evolutionary Steps to Creating a Brand
• Branding Hearts and Minds
• Visual Branding
• Themes, Schemes, Skins, Shells, Bells and Whistles
• Branding – An Unscientific Survey

SAP and Branding

• The SAP Theme Editor
• Brand Adaptation of the mySAP Enterprise Portal
• Branding and Usability in Software Products
• Branding – From the Point of View of a Usability & Design Consultant

 

Extending a Software Brand Language Across the Vendor, the Customer, and the User

By Mark Rolston, VP Creative, frog design inc, USA – February 21, 2003

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.

 

Looking Back

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

 

Ingredients of a Software Brand

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?

Bitmaps and Icons

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

Shape

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.

Line

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

Negative Space and Gaps

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

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

Color

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:

1. Establish a color system for functional semantics and make those colors off-limits for decoration and branding. You don't want to allow confusion.
2. If you plan to combine a branded color system with some amount of color personalization, define them as separate onscreen regions to avoid direct color collisions. In our experience, one foundation brand color is the best you can expect to easily retain in a system that offers customizable color themes. With too many foundation colors, the occurrence of color-clashes is very frequent.
3. Because coloring screen elements requires some degree of artist ability, limiting the range of color modification can help dramatically – even if it is more of an assistance than a limit. In the R/3 application, we created a system that allowed color hue adjustment without saturation or brightness control. In this way, the user was prevented from defining an unreadable background color but they still got the sense they had a high degree of control.
4. Color pairing also requires artistic skill. You can help developers and users by creating a system that demonstrates color pairs or color systems that work well together rather than forcing independent color choices.
5. Color choice for users is often more about emotional context than actual colors. To lend more context, theme titles can make the choices more attractive and valuable to users. For example, a theme titled "cool breeze" will likely be more satisfying than "light blue theme". Don't underestimate the value in providing packaged themes.

Affectations

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.

Summary

In summary, in putting together a flexible UI system, there are some easy methods to apply:

1. Color is the most effective and extensive quality to customize. It is also the area where customers demand control. But it also can do the most damage. Therefore it is critical to offer it as a fundamental property for personalization, but if you can afford to offer a style editor or color templates, you can avoid usability issues.
2. Spacing, scale, and negative space is probably the most significant area for communicating design quality. It is also the area that users and customers will be the least interested in customizing. If this part of the design is well done, it can provide a foundation for the software brand.
3. Lines are an overlooked quality in interface design that can do much more than simple border forms. Using line color and thickness can dramatically improve the UI quality. Also, allowing the line attributes to be customized can offer a wide range of flexibility in the GUI appearance.
4. Shapes are attributes that can create very dramatic aesthetic shifts but requires specific compromises and effort in the technology to support it. Customers are also not always equipped or interested in modifying these properties – unless you offer predefined shape choices (round, angled, squared, etc.)
5. Lastly, affectations bitmaps, and icons are a low-cost, low-impact way to inject personality and customizable properties into the interface. Elements like shadows, boxes, dotted lines, etc. can create memorable personalities to a GUI with little technical or usability overhead.

 

What Does the Future Hold?

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.

 

top