Design Tidbits

back To Overview of Tidbits

Design Tools

Simplification

Interaction Design

Screen Design

Hierarchies

Visual Design

Design Process

Web, Web Applications, Web Design

Performance

Miscellany

 

 

Bridging the Gap: From Structured Data to UI Designs – Part I: Introduction

By Gerd Waloszek, SAP User Experience, SAP AG – September 1, 2009

In my editorial Finding Common Ground... published at the beginning of 2008, I touched on the following issue: In the user interface (UI) design field a gap still seems to exist between the requirements that have been gathered for guiding a design and the concrete design itself (in the editorial, I refer to "early" and "late" approaches). For their part, designers' might be pressed to ask, "How can we derive a design from a requirements specification?" One might counter: "Where's the problem?" The "problem" is actually easy to describe: Both sides of the "gulf" deal with different entities and speak different languages. More about this discrepancy below!

I also mentioned that the SAP User Experience – Methods team was trying to crack the "riddle of the final step" of the design process, and I expressed the hope that they might present their results on the SAP Design Guild website one day. Since then, however, more than a year has passed, and the Methods team has evolved into the Research, Standards, and Methods (RSM) team and is now focusing on field and user research and feeding the UI design process from the other side – from the "source," one might say. It looks as if the prospects for publishing an article from the RSM team about this topic are not promising. I will therefore pitch in with a short series of design tidbits in which I will present a couple of approaches to "bridging the gap." My articles can only be teasers that cover the topic in a sketchy manner. But I hope to inspire UI designers with my articles and encourage them to experiment with these approaches and see whether they help them successfully arrive at a UI design. These approaches can — and sometimes — need to be used in combination, particularly if an application is complex and has to serve many purposes.

This first article in the series introduces my approaches to bridging the gap between specification and design. The second article will cover mapping approaches, while the third and final one will cover structural approaches and will end with a short conclusion.

 

"Structured" Raw Materials

In order to keep my article short, I will not start from scratch. Instead, I will assume that the design team has already gathered user and requirements data and assembled it in a structured manner, as follows perhaps:

All these methods allow you to describe the prospective users and tasks to be accomplished at various levels of detail, ranging from high-level descriptions to lists of detailed task steps (typically, a method can be used in a hierarchical manner). The descriptions are more or less formal (for example, semi-formal use case versus a more informal textual or pictorial description), and their choice may depend on the design team's preferences, the respective company's design process, or the target audience of the description.

Sample of persona descriptions

Figure 1: Sample of persona descriptions (from a Cooper project for SAP)

Typically, the descriptions do not contain any design or technical details – at least they should not. On the one hand, this "omission" is precisely the reason why there is a gap between the data and the design. On the other hand, if this data already contained technical details or prescribed a specific design, it would severely limit the designers' options. In real life, however, there are often certain constraints already imposed on the design – such as the use of a specific UI technology or computer platform.

By the way, if you look at Figure 1 and the figures below, you will easily recognize that there is a difference between the entities involved and that there is a gap that needs to be bridged.

 

Some Approaches to Bridging the Gap

I'm afraid that the respective UI design gurus will not like to read this: For the sake of brevity, I will also assume that the different descriptions listed above are more or less equivalent. This allows me to focus on the transformation of such a description into a UI design. First, let us look at what we have at our disposal and where we want to go:

Some people still seem to believe that UI design is just about putting controls on a screen, but even they have to acknowledge that there must be a "system" behind all this if the result is to be anything other than a random screen.

In the next two articles, I will discuss the following approaches, which are intended to help UI designers "bridge the gap." Some are mapping-based approaches; others have a more structural basis that is typically guided by an analogy:

Apple Font/DA mover

Figure 2: The Apple Font/DA Mover introduced a UI paradigm (or solution to a specific issue...) that has been imitated over and over again

Map room in Kai's Photo Soap

Figure 3: The map room in Kai's Photo Soap leads to different rooms, each of which performs a certain type of processing; the rooms are usually run through in a fixed order.

Some readers, their antennae buzzing, will interject that structural approaches are mappings as well. So why do I make this distinction? I introduce it because mapping approaches follow a more abstract approach, while structural approaches are more concrete and often guided by "striking" similarities or analogies. I hope that the usefulness of the distinction will become more evident as soon as I discuss the approaches.

 

Outlook

As already promised in the introduction, two more articles will follow – one presenting mapping approaches and another one presenting structural approaches. The third and final article will also offer a short conclusion.

 

References

 

top top