Editorials

back  To Overview of Editorials

Editorials 2008

Editorials 2007

Editorials 2006

Editorials 2005

Editorials 2004

Editorials 2003

Editorials 2002

Editorials 2001

Editorials 2000

 

What is an Application Design?

By Gerd Waloszek, Product Design Center, SAP AG – 07/27/2001

Now and then, user interface designers find that their interface design has not been implemented "correctly" by the application developers. They go to the developers and ask - a little bit annoyed - how that could happen. There are many excuses to that, such as, there was too much time pressure, or there were technical restrictions that prevented the implementation of the the original design. In this article, however, I do not want to discuss these well-known issues. Instead, I look at how different people interpret what a design is and what different approaches to design mean. For illustration, I take a look at "archetypes" of designs that we meet in our daily life as user interface designers. But let me start with a typical misunderstanding between user interfaces designers and application developers.

 

"Feature List" or "Shopping Bag" Design

Let's return to the user interface designers who are disappointed because their design has not been implemented by the application developers. They may find that the developers do not put forth the usual excuses; instead, they firmly believe that they faithfully implemented what had been proposed to them - and they wonder why the user interface designers are so furious.

So, what did happen here? To my belief, there are often misunderstandings between user interface designers and developers about what a design is and what it means to implement a design. The bottom line is that user interface designers expect their designs to be implemented "as a whole" with nothing left out and nothing added to. It's like a complete artwork - if you pick only parts of it and add other elements you spoil the design. The developers, however, regard the design that was handed over to them as a feature list or shopping bag. They pick the features they like, add perhaps some other features not found in the proposal, and in the end arrive at something that looks fairly different from the original design. Nevertheless, the developers are convinced that they implemented the design proposal and nothing else.

So, my first statement is, that designs are not equivalent to feature lists. Feature lists are made up of certain elements, but the elements in a design are not isolated or independent from each other. They interact with each other in a certain way to optimally achieve a goal. The design is "balanced" - if you change it the balance is lost. This is similar to what my doctor did when he prescribed a certain set of inter-balanced medicaments to treat my high blood pressure. If I leave one medicament out or replace one with another one with a different physiological effect, I destroy this balance.

Statement 1: Designs are not feature lists to pick from.

 

"Include Everything" Design - "Everybody's Darling" Design

Now let's start our walk through the "design zoo." The first "beast" is the "include everything" design. It may have many origins; one is that developers love technical challenges - and one challenge is to include as much bells and whistles into an application as possible. Maybe, some distant user needs these features and might use them one day, they argue. Thus, developers seem to believe that "more is better" - they want to be "everybody's darling." Many users, however, do not think that more is better; they are confused by the sheer mass of functionality - and often they don't even know how to access and use it.

Nowadays, user interface designers and developers talk about the 80:20 approach, that is, to implement only the most needed functionality. However, there is one problem with this approach - often the development team does not know what the most needed functionality or data is. So they have to make a guess, but that is not easy. In order to improve its "hit rate," the team modifies the 80:20 approach into something like a 95:5 approach - and we are back on field one in the design game. We all know that the only escape from this dilemma is to ask users and customers early and frequently, that is, to conduct site visits, arrange user days and confront users frequently with the software.

Design by Customization

This leads us to another closely-related "beast" - the design "by customization:" When developers do not know which functionality and features to include, they include everything they manage to include in the application and postpone the fine-tuning of the application to the customization process. That is, the basis strategy is downsizing the applications at the customer's site. The problem with this approach is that such a downsizing may not lead to a usable application. It also heavily depends on the quality of the customization process.

Statement 2: Good designs do not try to make everybody happy by including everything possible.

 

"Average of all Instances" Design

Often people believe that a good design is a design that incorporates the average of all possible instances of something. For example, the "ideal" and most beautiful face would be the average of millions of faces. But think of the ideal hammer as the "average" of all hammers. This would be a mid-weight and fairly simple hammer. But is this hammer useful? I doubt that because there a reasons why there are so many different hammers around. The carpenter for sure would be unhappy with this "average" hammer. So I don't think that a good word processor would be the one that is the "average" of all word processors on the market. It's far better to find a niche market - large enough to nourish you, of course - and write a word processor for this clientele.

Statement 3: Good designs are not the average of everything.

 

"Collection of the Most Wanted Features" Design

Sometimes, designs are shopping bags in the sense that they include the most wanted features. These features may have been collected by the marketing department or product management, for example by looking at the competition, sending questionnaires to customers, or conducting meetings with customers and users.

Such a design will surely have some success on the market, especially if it addresses a wide audience. However, if it addresses a more specialized clientele, it may turn out that the design is too broad in scope or too general to fit the needs of this group. So, you should collect useful features in as narrow a population as possible.

In addition, it is an open question, whether a collection of features is already a coordinated design. Maybe, leaving certain features out or transferring them to another application would lead to a better design.

Statement 4: Good designs are not a collection of features but a coordinated solution.

 

"Default" or "Generic" Design

The next "beast" in our design zoo stands for a "standard" or "average" design in the sense that "default" solutions are used, which in the end lead to a "sub-optimal" or mediocre application. For example, as tabstrips came into use, everything was presented in a tabstrip. Another example is the tree-mania: if data look like a hierarchy, a tree presentation is typically chosen regardless of the number of data or depth of the hierarchy. So we find that certain design elements are used, even though there are better solutions.

This tendency for "standard" or "generic" solutions has many causes. One cause is - as in the case of the tabstrip - that "everybody" uses such a design. "So, what is wrong with it?" a developer would ask. Another cause is that developers often have too little knowledge about the users, the task and the usage context - a knowledge that would enable them to create a better design. For example, in the case where a developer chooses a tree, he or she may not know the typical amount of data to be displayed. So the developer chooses a "generic" solution because this is always correct and can handle any situation. Yes, it does, but it is not optimal for the users. They might prefer a two-level list that is far easier to handle.

The bottom line of this is: if you want to avoid dull standard and generic solutions you have to know enough about the contexts in which the users work with your application.

Statement 5: Good designs are not standard or generic but focused.

 

"One Fits All" Designs

With users getting more and more into the focus of application design it turns out that users vary with respect to their domain and computer knowledge. Not only are users different, one user him or herself changes over time when working with an application - starting as a novice and maybe becoming a proficient user one day (not all users will however reach this stadium). In spite of all this we design applications as if there were only one type of users. These days we sometimes design special applications for beginners, for example when we design for the Web; in other cases we design for proficient users. If we are lucky, most of our users fit this user type, but often enough there is a broad spectrum of users with wide variations.

These days, the 508 accessibility issue makes us aware of people with disabilities. Now our "one fits all" applications also have to fit these users. Sure, there are economical reasons for the "one fits all " approach. In addition, having three to five different versions of a program makes life much harder for system administrators in a large company. Nevertheless, I firmly believe that we need software that addressed the needs of different users differently - be it by designing different applications, or by applications that can be adapted to the needs of different users or one user while getting experienced with an application. As an example, SAP developed prototypical Web applications, which offered different amounts of instructional texts. The user could select his or her appropriate level of talkativeness of the user interface. Other approaches might include designs where users can choose between two types of navigational structure: in one version users would be moving from screen to screen and thus being more guided; a second version would offer screens with multiple areas, which include all relevant aspects for a task and thus give users more freedom in performing their tasks, thus avoiding any navigation between screens.

Statement 6: Good designs do not attempt to fit all users but allow users to adapt the application to their needs and knowledge level.

 

What Are the Characteristics of a Design?

Let me close this article with a few statements about what I believe are the characteristics of application design.

Design is Tailor-made and Focused

A good design is like a suit made by a tailor - it fits well in every aspect. I know that this is an ideal in a mass market for software. But keep in mind that the more you focus your design on the prospective users and their needs, the better the design and the resulting application will be - and the more content the users will be.

Design is Specific and Concrete, not Abstract and Vague

Setting a focus for a design means to be specific and concrete, not abstract or vague. Abstract and vague designs lead to generic solutions and thus to mediocre applications - to applications that fit somehow but users do not feel comfortable with them because they are not tailor-made. They have been made for many people and situations, not specifically for them.

To be specific and focused you have to ask specific questions, such as:

And many, many more....

Design is Fragile - It Rests on Assumptions

A design is not created out of nothing, it is based on certain assumptions. If the assumptions are no longer valid and new requirements added the design may break and you may have to start over. There are critical and less critical new requirements. A less critical requirement may, for example, be that none or two additional fields are needed on a screen. A bit more critical is the need for three new functions: now you have two rows of buttons instead of one, which looks ugly. The really critical changes, however, require a more or less radical redesign. For example, the additional functionality requires a restructuring of the application - instead of a one-level navigation bar you may need now a two-level navigation.

The assumptions you base your design on are an "extract" of the information that is given to you. Of course, you know that the information is to some degree incomplete. But for creating a good design you have to rely on a certain stability of your assumptions. Many development teams are not aware of this fact. When they pull new requirements out of the box they do not realize the possible impact on the design. So one important task for user interface designers is to call the developers' attention to the fragile relation between a design and its assumptions.

Design is Interactive and Iterative

Application design is different from design in arts. Picasso would have never asked someone else whether he is on the right track when creating a painting. User interface designers, on the contrary, design products to be used by people in their daily work. For achieving an optimal product, it is fundamental to check the design over and over. Not only can requirements change, we also may not be sure whether our assumptions based on the information given to us are correct. Therefore, user interface designers need frequent feedback loops with the development team as well as with the prospective users. These iterations and interactions also prevent that a design looses track and in the worst case has to be recreated from scratch.

Last Word

So, whenever you design, design for people - and your users will be happy.

 

top top