Editorials

back  To Overview of Editorials

Editorials 2010

Editorials 2009

Editorials 2008

Editorials 2007

Editorials 2006

Editorials 2005

Editorials 2004

Editorials 2003

Editorials 2002

Editorials 2001

Editorials 2000

 

Links & More

Print version Print version
   

Related Links
document What is an Application Design?

Background Links
document SAP User-Centered Design

Stumbling Blocks for Good Application Design

By Gerd Waloszek, SAP AG, SAP User Experience – March 9, 2001

Design guidelines assume an ideal development process: users have been investigated, realistic usage scenarios have been created, the developers listen to the user interface designers and eagerly implement their designs, the test results are satisfying. In real life, however, things do not work that smoothly. There are a number of stumbling blocks to be overcome, and lots of reasons why design projects may fail. In the following article, I present a couple of such issues based on past experience.

 

Time Issues

No Time - And How You Can Make up for It

The most frequent excuse for bad design is lack of time: There was so much other work to do, and the schedules were so tight, that no time was left for going on site visits, creating scenarios, asking for usability consulting, reading usability guidelines, visiting usability-related Websites, or whatever the development team could have done to improve the design and usability of the application.

Inevitably, time schedules are very tight these days, but this is something we usually can't change. So what can realistically be done under time pressure? At least the bare minimum can be done: The development team can - assisted by a user interface designer - conduct a 1-2 day workshop to

If a quick evaluation of the prototypes cannot be carried out during the workshop, I strongly recommend demonstrating them at least to people outside of the development team. Ideally, the test persons should be prospective users, but coworkers from other departments, relatives, friends etc. also work out fine. It is very important to complete these activities within a few days and not distribute them over several weeks. Otherwise, the team will indeed run into timing problems. It may seem that there is no time to conduct such a workshop, but in reality it saves the team a lot of time which would have to be spent later fixing the design.

No Big Changes, Please - The Dilemma of Last-Minute Consulting

Imagine a typical situation in the daily life of a user interface designer. The designer is asked to have a "quick look" at a developer's screen designs. Often, however, it is not the problem the interface designer was asked to look at that makes him shake his head in quiet frustration. Instead, the application design is flawed as a whole, and the designer comes to the conclusion that a redesign would be necessary to solve the inherent problems of the application. Such a move is usually impossible to push through and also wasn't even the developer's original intention, which was just to fix a "small problem." There seems to be no way to prevent many big usability problems from making their way into the final product.

This situation becomes even worse when the release date creeps up and "help" calls to user interface designers increase in frequency dramatically. Usually, in such "last-minute consultations," the developer has a funny feeling about the design and calls the UI designer for a quick approval of what he or she has implemented. Or, the developer has a very tricky problem that he or she cannot solve.

While in both cases the user interface designer often finds a fundamental design flaw, all of his or her proposals have to be very simple changes to be accepted by the developer because there is hardly any time left (development closes "in an hour," or "tonight"). All major changes, which would substantially improve the application, are impossible to implement under the given time constraints. So, we end up with a frustrated user interface designer who, for example, only managed to reposition of a menu item and with a frustrated developer who hears for the first time, right before development close, that the design is fundamentally flawed.

 

Meetings

Frequency of Meetings

After the initial design phase, further consultations may continue over a longer period of time, maybe for three months. During this time there will - hopefully - be further meetings to refine the design, discuss the progress of the implemented application, and fix the problems with it. But how often should you meet? For usability consultants outside the development team the simple answer is, "the more often, the better." As long as there is no evidence that the design is really implemented, you should meet at least once a week, in the beginning even more often. If meetings are delayed or canceled and the next meeting takes place only after three or more weeks, you may very well find that what has been implemented has little in common with the design ideas created during the last meeting. As I show below, it can be very hard to move the design back onto the right track.

Requirements Appear "Out of the Box" - Ill-Defined Scenarios, Meetings with Ever-Changing Participants

One of the most frustrating moments during a design discussion is when, after a long and heated debate, the team finally settles on a design and then all of a sudden someone pulls out a new requirement and asks "Have you thought of XYZ?" Of course, nobody has thought of it; all the other team members assumed that the requirements for the design were evident and laid down in the existing scenario descriptions. So, if the team agrees that the new requirement is important and should be included in the scenarios, that means that they were obviously not fully specified from the beginning. The problem with such "late insights" is that they often make the whole design crumble. The team may be forced to start over, loosing valuable time. Therefore, it is critical that scenarios are as complete as possible before designing begins. You can only design if you have a firm foundation. Any change in the prerequisites may lead to very different design decisions. But please, don't get me wrong, this doesn't mean that you should do without scenarios to avoid such problems. Even an ill-defined scenario is better than none.

There is another cause for "out of the box" requirements, namely design meetings. These meeting are often strung out over weeks and months with participants changing from meeting to meeting - sometimes with little or even no overlap between people. New people do not know much about the old design ideas and the rationale behind them. They tend to bring in new requirements and new design ideas - they have to justify their participation anyway, and the design will never stabilize.

Meet with the Right People

As experience shows, it is important to meet with the right people when consulting an application. If you meet with people who are willing to implement the design, be sure that they really are the people who implement it. Otherwise, some other developer may all of a sudden come up with an implementation that typically has little in common with the design that you and your discussion partners established during the meetings. And as we all know, a design that is already implemented typically wins.

 

The "Art" of Design

Random Walk Design

Often design discussions follow a "random walk" structure. The discussion starts with some initial design proposal, which is put forward by one or more team members, and then other members come up with their requirements and proposals. Typically, during such a discussion the design changes continually, depending on people's influence or loudness and the duration of the meeting, among other factors. Team members change opinions now and then, older designs "reappear" from time to time. After a couple of hours the group ends up with a totally different design - often achieved because most participants are too exhausted to oppose the current proposal. This may not be bad in itself, if the design is much better than the old one. But usually the resulting design is just a product of chance: the rationales behind other designs, their pros and cons - if ever evaluated - have been completely forgotten. As a result of such erratic design discussions, the discussion starts anew with every follow-up meeting (usually it also has a couple of new participants). There, new proposals are brought in, old ones as well as their pros and cons are forgotten, and so on, and so on...

Coffee Corner Design

Many design meetings take place in coffee corners. An informal meeting culture is good for a company; it presents, however, a problem, when designs are discussed. In coffee corners are coffee machines, but there are no computers, whiteboards, beamers, flip charts or whatever devices that support the team members' imagination. Instead, as developers are used to abstract thinking and like it very much, design issues are discussed only verbally - maybe someone makes some cryptic scratches on a napkin. Hopefully, there are no logical errors in all the assumptions and design decisions made, but nobody really knows how the design looks or how its elements work together - and nobody seems to care. In my experience, it takes a lot of effort to force a team into a room with at least a whiteboard or at the computer and have a look at what they just "designed." But if you succeed, some decisions take minutes that before took hours.

Design by Authority

There are several types of authorities in interface design. For instance, a user interface designer is an authority for interface design because he or she has a lot of knowledge and experience in this field. In spite of this, there are cases, where developers or managers do not respect this authority; they believe that interface design is like raising kids or driving cars - it is a topic where everybody feels like an expert. Sometimes, however, it is the other way round. Developers leave all the design decisions up to the interface designer saying, "Tell me how to do it. I'll implement whatever you want." This is not the right way, either. Now developers are cut off from the decision-making process and if the design fails - even if they implemented something quite different - might put all blame on the interface designer in the end.

Another source of authority is managers. Sometimes managers want to take part in design meetings, for example, in order to "speed up" the discussions. Of course, the manager takes an active part in the discussion - he or she is the boss. As the discussion moves along, the manager may create a lot of clever design ideas. As a matter of fact, most of these ideas have already been discussed and discarded for one reason or another in previous meetings, but now it is the manager who puts them forth. Only a few participants dare to point this out. In the end, the manager's design ideas survive, and hours of previous design meetings are wasted. Even worse, if this pattern repeats itself, the manager comes to believe that he or she is a great designer and may take over the whole application design. Actually, this is not what the manager is paid for, and I dare to doubt that he or she does user interface design better than managing.

Usability People Can Err - Ask the Users, not the Principles

Let's face it - usability people and user interface designers can err. Often they have to make their decisions under certain assumptions and with incomplete knowledge, or they are simply expected to say something. However a decision was derived, it can be wrong, especially under such circumstances. For example, in the case of incomplete or inconsistent knowledge, interface designers often base their decisions on general rules or principles like "consistency." Users on the other hand, simply try to understand and use an application. They do not care about principles - they do not know them - and may act even contrary to them. Therefore, I urge you to ask and watch the users if you are unsure about a design decision. Conduct a user test, as quick-and-dirty as it may be, but do not rely solely on your abstract knowledge and intuitions. What matters is how well users accomplish a task, not whether certain "important" usability principles are obeyed.

 

The Developers Have the Power

Whatever interface designers or usability people are doing and telling the developers, they should be aware that the developers have the power, not the other way round. So, chances are good that an interface designer will advise a developer to implement a certain design, but the developer will implement something quite different. The following tips may help to improve the outcome.

Thinking Habits

This unproductive situation can happen for different reasons. Maybe, the developer simply dislikes the proposed design. More often there are technical restrictions and problems, which lead to such differences. A better communication between the developer and the interface designer would solve this, but in practice communication is not that easy. Often traditional thinking habits combines with problems which arise when technology changes. For example, when creating new Internet applications, many developers still followed the "old route" and exported ERP applications to the Web.

Designs as Feature Lists

There is another reason for differences between design proposals and the actual implementation: developers often interpret designs as a "feature list." They firmly believe that they implemented the proposed design, if they implemented most of the features - they do not have a "holistic" view of the design. Usually, user interface designers are not very pleased with the results of such an approach. They feel that the gist of the design is lost this way. If they express this feeling and complain that their design has not been implemented, this in turn confuses the developers who believe that they did what they had been told.

Coded and Standing "Solid as a Rock"

User interface designers repeatedly have the experience that once something has been coded, however flawed the design may be, it stands "solid as a rock." There are many reasons and excuses for this, such as: "It took so much time and effort to achieve the current state" or "Time pressure is high, there is no time left for changing the design. Maybe in the next release..." or more offensive "I think it's not that bad; people used it in the past and nobody complained."

One of the reasons for this disparity may be that the contact to the developers has not been close enough. If you meet developers only when they ask for help, you will be astonished what they made of your design ideas in the meantime. Aside from the reasons stated above, it is often the developers' confidence "We can solve this on our own," which leads to a "loss of contact." I already addressed the issue of talking to the wrong people. If you do not talk to the person who really implements the design, the final result might surprise you, and then it is too late for changes.

A Question of Balance

After many frustrating experiences some usability people have even come to the belief that the only way they can influence the implementation is to sit beside the developer and make sure that he or she implements the "right" design. This is, of course, not desirable, because it is just a reversal of power. What we really need is a fair relationship between user interface designers and developers in which each side accepts the other's strengths and abilities. User interface designers should not argue about SELECT statements, but developers should also acknowledge the authority of user interface designers in interface design issues - at least as a "last word" when no consensus can be found.

 

Other Stumbling Blocks

Sorry, Not Available Now

All design decisions end up with the selection of some "existing" interface elements, as well as their combination and arrangement on the screen, so that users can accomplish a task. I would like to draw your attention to the little, but important, word "existing." In a software company like SAP, user interface technology has at any given point in time, reached a certain state, which may be far beyond all other standards, or - more probable in the context of business applications - be a little bit behind. Usually, the company is working hard to change this, but for the developers and user interface designers this means that not all possible design options are actually available or the company's interface technology is evolving and thus constantly changing.

The latter means that developers may not be familiar with the new features or how to use them. It may also be unclear whether these features will be available in time to be implemented in the upcoming release. The features may also be very unstable in the first period of availability, something that can make development a hassle. Sad as it is, under these conditions, many great design ideas may have to be buried when faced with reality.

 

top top