Enabling the pursuit of different goals

XVI.1 January + February 2009
Page: 66
Digital Citation

FEATUREThe value of visual design in software development


Authors:
Kimberley Peter

The question of whether or not visual design has value in software might seem moot. For decades now, graphical user interfaces have been the dominant paradigm [1]. We revere the visual fruits of Apple; we delight in the graphical levity of the pervasive Web 2.0 look; and we get a visceral tickle out of the many visual and interactive effects of the Microsoft Vista, Linux Ubuntu, and Mac OS X operating systems. We like to be delighted and engaged visually. And why not? Whether our use of computer software is business or personal, we spend a lot of time with machines and the soft stuff that helps us get things done. The time spent might as well be pleasant.

This sentiment is appreciated in mainstream software, yet things have been a little different in the world of software development for programming and business tools, where user delight and the virtues of visual elegance have not been so widely or confidently embraced. Things appear to be changing, and exposure to design is a significant part of this change.

Dearth of Designers/Dearth of Design

Each day I work with people whom I consider sophisticated users. These are the ones who make software for software developers and the related technical and nontechnical disciplines that use Collaborative Application Lifecycle Management tools [2]. As a team we create both desktop and Web-based applications. Increasingly, we use the tools we build. We are also collectively exposed to a great deal of software, both mainstream products and the tools we use to do our work. This exposure helps to inform our expectations of our own products, as we increasingly expect them to do more and look great. As we have sophisticated and diversified audiences, we want the tools we build to offer more than the same old integrated development environment (IDE) interfaces of years running. We also need to be competitive. To do that, attention to product interface design and its level of quality are essential.

Transformation is wanted, expected, and happening. It’s a good time to be a visual designer.

Still, I do hear of designers struggling in their organizations to make a difference, to exercise their capabilities beyond the usual graphical requirements.

Additionally, there are software projects in which no visual designers are involved at all. Part of this may be lack of awareness or recognition of the value they can bring, or lack of funding to expand the team to include them.

Given the taste we have developed for more thoughtfully and elegantly designed user interfaces in both consumer and business segments, is it a good idea for software companies to exclude visual design from their project teams?

Toolkits and Prêt-à-Porter UI

I observe in my daily work that the availability of toolkits can have an influence on whether or not a visual designer is involved in a project, or to what degree. Toolkits provide varying degrees of ready-to-use function often replete with the code that renders the UI, what I will call prêt-à-porter, or ready to wear. This is beneficial if you are a developer because coding from scratch can be much harder; it takes more time, and it can be highly experimental until a suitable and desirable solution is determined.

But do we want our software to look the same as numerous others using these prêt-à-porter toolkits, particularly those of other companies?

Consider Eclipse, an open source IDE and framework that provides the tools to create Rich Client Platform (RCP) applications as wide-ranging in purpose as Soccermaster RCP for tracking soccer results and NASA Jet Propulsion Laboratory’s use of the RCP for its Mars missions. Currently, there is no easy way to visually skin an Eclipse-based application. The effect is that most Eclipse-based apps end up inheriting the look and feel that comes “out of the box.” This is handy if you want or need to adapt to the look and feel of the native operation system, but there is no distinction for your application from any other built with Eclipse. This could be seen as a purely aesthetic drag or a significant business problem. One might need to customize an application to align its look with brand guidelines or existing products, to distinguish it from a competing product that is also built using Eclipse, or to better suit a nontechnical audience. To a degree, customization is possible, yet it requires additional effort in design and code.

Another popular open source toolkit is the Web-based Dojo and its widget library “dijit.” These are highly customizable, yet often we see the default dijit theme “Tundra” used, as is. Why? People use the default because it looks acceptable and because the cost of change is prohibitive—it requires less effort and less cost to simply accept the standard look and feel.

Toolkits come with a great deal of useful functionality that can serve to propagate patterns, fostering not only good practice through use but also consistent presentation and interaction across suites of tools and products—something that is particularly important if there are multiple and distributed teams working on different parts of the software. But except for the accompaniment of interface guidelines, if present, the use of toolkits does not necessarily make for the most appropriate or desirable UI presentation, much less one that is tailored to brand or audience.

Even if the toolkit provides widgets and styles to manipulate, the decisions and details around style, organization and flow of the information, composition and alignment, or appropriateness of color and other cues are typically not part of the package.

Value in Practice

Whether or not toolkits are used, these details and design outcomes are the result of certain activities and modes of thinking that visual designers contribute, in some ways uniquely, to software development projects.

A product’s brand, visual style, and the collective treatment and interplay between elements that lend to its character are a few of the obvious ways in which visual design contributes to the software user experience. More interesting are the nonobvious ways in which these things come about, where perhaps their greater value lies. It is through things like abductive reasoning, making the abstract concrete, and working with constraints that visual designers and their craft can add significant value.

Abductive reasoning is something Roger L. Martin, dean of Rotman School of Management, describes as embracing the logic of what might be rather than what is (inductive) or must be (deductive) [3].


A product’s brand, visual style, and the collective treatment and interplay between elements that lend to its character are a few of the obvious ways in which visual design contributes to the software user experience.

 


Put in terms related to user experience, abductive reasoning is working from intuition and possibility, inductive reasoning is working from observation and user feedback, and deductive reasoning is working from design principles and established guidelines. All methods of inference are important in doing design. In the practice of visual design specifically, abductive reasoning plays an important role in the breadth and depth of ideas generated that ultimately contribute to more-considered product solutions.

Making the abstract concrete is the hands-on extension of the thinking process.

Visual designers take ideas and turn them into something concrete, if still fictional, by giving them form and illuminating function. By mocking up the possibilities, often in high fidelity—from single static screens to multiscreen interaction flows—we are able to see what “works” and what does not. It’s a way of thinking in pixels or vectors or moving images toward solutions.

A significant part of the value in this process is what is revealed without any commitment to code. This exploratory process also helps the team develop a sensibility to what is worth taking forward for further iteration, and is an excellent aid to making decisions on UI direction.

Working with constraints is an essential part of doing design. In software development, toolkits and technologies provide constraints, as do other factors, including customer requirements, user feedback, design principles, and best practices—all of which help bound the design space. While constraints are not unique to design, they increase the challenge, often making it a lot more interesting to solve the design problem. They have a tendency to help focus energy and encourage designers to think creatively beyond the imposed limits.

Using an Eclipse example, we gave the base form UI a facelift [4] and in doing so developed an approach to using color that allows the flexibility of customizing an Eclipse-based UI without sacrificing its ability to adapt to the native operating system theme. We call this the “Adaptable Color Approach.” The constraint in this case was a limited palette derived from each of the standard operating systems that, if applied in any way other than the intended use, could result in wild variations in contrast and quality on the different system themes. To control this, we used Eclipse’s ability to read RGB values as a way to anticipate the resulting color, without hard-coding the colors per system theme. We can now attain richer UI rendering of widgets, views, and editors simply by manipulating color with basic code rules. It was through the process of testing colors in design, understanding how they would behave once implemented, and providing the color rules that this was possible.

While much is accomplished in software development without the aid of visual designers, the interfaces that get produced can be limited by toolkits and scant exploration prior to implementation. Increased general exposure to more viscerally delightful mainstream software interfaces is helping to drive an increased appetite for similar experiences in software development tools. Visual design has a role to play not only in making these interfaces visually engaging but also more thoughtfully designed, by bringing to them a unique perspective and practices that can help take design issues toward more considered solutions.

References

1. Baecker, R. “Themes in the Early History of HCI - Some Unanswered Questions.” interactions 15, no. 2 (2007): 22–25.

2. Monson, P., C. Pampino, M. Gothe, N. Yuce, K. Nizami, K. Patel, and B. M. Smith. “Collaborative Application Lifecycle Management with Rational Products,” IBM Redbooks® (draft), June 2008.

3. Martin, Roger L. “Creativity That Goes Deep.” BusinessWeek. 3 August 2005.

4. Archer, A. “Forms: New in 3.3.,” Eclipse Corner Articles. September 2007. <http://www.eclipse.org/articles/article.php?file=Article-Forms33/index.html>

Author

Kimberley Peter is a visual designer with the Media Design Studio at the IBM Toronto Lab. She works on Eclipse- and Web-based applications for the IBM Rational Software brand. Her most recent design activities have been for the Jazz Project, where for the past few years she has enjoyed collaborating with her fellow design, usability, and development colleagues on the making of Jazz and the first Rational products to be based on it. Kimberley writes about user interface design and related issues on the Jazz Team Blog at https://jazz.net/blog.

Footnotes

DOI: http://doi.acm.org/10.1145/1456202.1456219

Figures

UF1Figure. Some examples, from the Eclipse Plug-in Development form editor, of how the color adapts to native system themes.

©2009 ACM  1072-5220/09/0100  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2009 ACM, Inc.

 

Post Comment


No Comments Found