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

 

Finding Common Ground...

By Gerd Waloszek, SAP User Experience, SAP AG – Updated: January 30, 2008

From time to time, I get somewhat frustrated about the progress that the software industry has made with respect to delivering usable applications. In my opinion, one of the many reasons for this situation is the barriers that still exist between software developers and UI professionals. Developers and UI people seem to live in different worlds and speak different languages. In this editorial, I want to delve a bit deeper into this dilemma and look at the proposed solutions.

 

Living in Different Worlds

Photo of Gerd WaloszekAgain and again, it appears as if developers and UI designers live in different worlds. At a closer look, however, this situation should not be surprising. Developers live in a technical world of databases, programming languages, formalisms, algorithms, data structures, and the like. UI designers live in a world of requirements, tasks, scenarios, user goals, and last but not least users, in other words, actual human beings. When developers search for solutions, they are trained to find generic solutions, ones, which, for example, scale from n=1 to n=very large (or infinity). They design solutions for machines, for which this strategy makes perfect sense. UI designers, in contrast, look for solutions that fit the information processing and memory capabilities of human beings, as well as other human "oddities." For humans, it makes a huge difference whether we have deal with three, a thousand, or a million items. The limitations of human information processing play an enormous role when we ask questions such as how many items can be presented to humans, whether they should be presented in parallel or sequentially, at which speed, at which level of detail, and so on. They also constrain how we design tasks that humans have to perform, be it browsing, comparing, remembering, or recognizing items.

Let me use an example that illustrates the different worlds that developers and UI people live in: I was shocked when I learned that the AGILE methodology for software development had simply forgotten to include users. Personally, I am convinced that this was not an oversight. The HCI tradition has existed for several decades now, how can one forget to include HCI in a software design methodology? Once they realized this omission, some UI people became anxious that there would be no work for them any more. So they waved their hands and cried: "Hey, look, we can show you how you can integrate user-centered design into AGILE!" The future will show, how successful this strategy will be...

 

Speaking Different Languages

Obviously, developers and UI designers speak different languages. Consequently, a popular recommendation given to UI designers is to speak the developers' language so that the latter will understand them easily. For several reasons, I do not agree with this suggestion. Firstly, why not meet somewhere in the middle? It seems to be a common conception that it is the UI designers who have to approach the developers, not the other way round. UI designers are an endangered species who always feel that they must – and are expected to – justify why they are there. Consequently, they are expected to make the first move. But isn't usable software a goal we are all striving for, so why this submissiveness? Secondly, speaking the developers' language means speaking a "foreign" language. It is evident that UI designers will not speak this language anywhere nearly as fluently as the developers, which will definitely weaken their position when it comes to hot tempered debates on UI issues. Thirdly, wouldn't it be nice if developers gained a deeper understanding of the clientele for whom they develop their applications? Many developers are definitely open to acquiring this knowledge, but find it hard to get at. Therefore, I propose that developers and UI designers meet somewhere in the middle and adopt a common language, one with less UI speak and less technical jargon. In this language, preferably one that everybody understands, they can all talk about the ultimate purpose of the software to be developed and how the users' goals can be accommodated within the given technical framework.

 

Finding a Common Language

Actually, I am not the only person to suggest a common language for developers and UI designers. A number of proposals have already been made, each dedicated to a certain aspect of the design space: Users can be modeled by Alan Cooper's personas or as user roles, processes by scenarios, use cases, or Karen Holtzblatt's step model. At a more detailed level, prototypes of different fidelities or screen mockups may serve as means of communication. Last but not least, the technological framework, for example, the development environment, can act as a "bridge" between both parties: It may already include and apply UI knowledge, be it through predefined approved solutions, built-in constraints, or a supportive help system.

In the days of the SAP Enjoy initiative, influenced by our consultants Cooper and Holtzblatt, SAP UI designers mainly used personas and scenarios as the media to communicate with developers, solution managers, management, customers, and users. Later, they also included Holtzblatt's User Environment Design (UED) in the design process. SAP's current UCD process has adopted a more formalized approach with, for example, use-cases and user roles as the preferred means of communication. In addition, Visio prototypes are used for communicating at a more detailed level. In my opinion, however, the question of which methodology should be used is not the most important one. The primary concern should be to ensure that a tried-and-tested approach is used in the first place – and if it is that its deliverables are grounded in real user and usage data, not just common sense and ideas.

Admittedly, the UI community itself has had some controversial discussions about the best approach, leading to even more confusion for development. On the other hand, such discussions are necessary and useful. Workshops at UI conferences, such as the CHI conference, present good opportunities to discuss and compare the different approaches, though with little participation from the development community. Personas seem to be discussed more often than other approaches because they have been so widely popularized. There have been papers on the value of personas, and I was able to visit a CHI panel in 2006 that discussed personas. All in all, such an exchange of ideas and practices can very fruitful for the UI community, but it would be even more fruitful if the development community participated in it.

One aspect that is often overlooked is that of cultural differences. These exist between UI designers and developers, as well as within the communities themselves. For example, we found that European UI designers and developers rarely share the excitement about personas that their American colleagues exhibit. These differences may prevent a successful communication between UI designers and developers, but they can also present an obstacle if, for example, a international company tries to implement a certain method.

By the way, sometimes, it's easy to preach to the choir, as the following example shows: When I replaced a colleague's paper sketch by an HTML prototype to propose a design to a developer, everything worked fine – we had found a common language.

 

But One Step is still Missing...

At a closer look, however, there is a gap between "early" approaches, such as use cases or scenarios on the one hand, and "late" approaches, such as prototypes and screen mockups on the other. One step is still missing from the design process, namely the final screen design, made up of real screen elements. This step is urgently needed to come up with more detailed prototypes and mockups that are grounded in the early models.

Holtzblatt's UED is a step in this direction: It defines places (that is, screens), the respective functions offered there, and the links between the places. But the step to the actual screen elements is missing, too. In her book, Contextual Design, Karen Holtzblatt dedicates remarkably little room to this final step, as I pointed already out in earlier articles. Her argument is that technology is a "given," and a design can be accomplished within the restrictions of nearly any technical framework. Many UI designers will definitely contradict her position: They often even claim that they cannot implement a design if a certain control is missing from the technical framework that they have to use.

Own version of Sidney Harris' cartoon

Figure 1: My own mouse-made version of Sidney Harris' cartoon (see the original cartoon on Sidney Harris' Website)

When we asked designers from Cooper about this final step, they agreed that some "magic" is involved – as depicted in the famous cartoon by Sidney Harris. Personally, I agree that some magic is involved but there is also a lot of experience and knowledge of UI conventions. Platform-dependent interface guidelines, such as the Windows or Apple Human Interface Guidelines, already define large pieces of the user interface, such as the menu structure and the way functionality has to be presented. In addition, criteria exist for selecting the correct screen element available, some of which involve the magical number "n" that I referred to above. For example, when implementing single selection designers have to decide between radio buttons, lists, and other design options on the basis of how many options users have to consider. Nevertheless, more guidance is needed for UI designers. The SAP User Experience Methods team is trying to crack this "riddle of the final step." Perhaps one day they will present their results on the SAP Design Guild...

 

Summary

I started this editorial by observing that developers and UI designers often seem to live in different worlds and speak different languages. Requiring UI designers to adapt to the world and language of the developers, as has often been proposed, does not seem the right approach to me. In my opinion, both parties have to meet somewhere in the middle and find a common language when designing user-friendly software. I listed a number of proposals that have been made with regards to overcoming the language barrier, such as use cases, personas, and prototypes. I also suggested that the choice of the method is less important than using a tried-and-tested method and ensuring its deliverables are based on real users' data. Finally, I pointed out that there is an interesting gap between early and late approaches to overcoming the language barrier, which still seems to require some "magic" and deserves further investigation.

 

References

 

top top