Category Archives: Techniques

Techniques and methodologies for efficient user experience design

SwissCHI event Apr 30, 09: “Prototyping of Rich Internet Applications”

Last Thursday I attended the monthly SwissCHI meeting. That evening's topic was "Prototyping of Rich Internet Applications" – Andreas Binggeli, Marc Blume and Yuan-Yuan Sun presented their Master's thesis (from their MASHCID studies). Interestingly, but not surprisingly, paper prototypes compared really well to more elaborate prototypes done in Axure RP Pro or realized using Ajax-y technology, and users didn't really pay much attention to the paper prototypes lower fidelity. (I wrote up a piece on which prototyping tool to use in which case earlier.)

After a brief introduction into what RIAs are (or rather, aren't: "RIA ≠ Ajax ≠ Web2.0"), Andreas, Marc and Yuan-Yuan presented their study. The following hypothesis were to be tested:

  • Between different forms of prototypes, there would only be differences in speed and visual appearance
  • There wouldn't be differences in user hesitation, difficulties, slowing-down, quality of interaction etc.

They'd be asking subjects to form an overall assessment of visual appearance, behavior, and speed.

The four prototype variants they were testing were:

  • hand-drawn paper prototype
  • Powerpoint-created paper prototype
  • Pseudo-HTML prototype created in Axure RP pro
  • Ajax prototype

These were their findings:

  • Both the hand-drawn and the PowerPoint-created paper prototypes were experienced as (too) slow; a lot of preparation on the researcher's side and high concentration were needed
  • Axure-powered prototypes used interaction elements that looked alright but didn't live up to their expectations
  • The Ajax-based prototype was quite slow in some parts, which lead to some immediate reactions not being perceived by the subjects, whereas some elements' affordance wasn't perceived properly
  • Interestingly, subjects didn't really see differences in the visual appearances of the prototypes
  • All methods can be used to prototype RIAs, but all have their very specific weaknesses
  • Interaction quality is compromised most severely by unexpected behavior, not so much by visual appearance or speed
  • The appropriate method should be chosen based on the phase the project is in, the Ajax pattern to be simulated, and the desired longevity of the prototype

In the end, if you take the effort into consideration, paper prototypes might still be the most appropriate method in most cases. This finding really doesn't come as a big surprise…

SwissCHI event Mar 26, 09: “Interaction Design Patterns in the Real World”

On March 26, 09, the monthly SwissCHI event focused on "Interaction Design Patters in the real world". A panel of six experts plus an advocatus diaboli came together to exchange opinions and experiences on design patterns, but it quickly became clear that they weren't talking about the same thing at all: They were arguing on very different levels of abstraction, from controls to actual design patterns.

An initial definition of an interaction design pattern reads:

  • A proven solution to
  • A recurring problem
  • in a defined context

Participants in the discussion were:

  • Marcel Brunschwiler, UBS AG
  • Christian Hübscher, Zürcher Kantonalbank
  • Bernhard von Allmen, Roche Diagnostic
  • Thomas Kneubühl, MAS HCID
  • Stefan Schallenberger, eGovernment Kanton Aargau
  • Frank Leidermann, Swisscom AG
  • Daniel Felix had the role of the Advocatus Diaboli
  • Christian Hauri moderated the session

Marcel Brunschwiler, UBS AG, opened the session. UBS is using design patterns as "aid to self-aid" for better UI design (and to free up resources in the usability team for more challenging tasks). They don't really have interaction designers at UBS; instead Business Analysts are defining everything. There used to be a style guide that also defined how certain elements were to be applied.  UBS AG's pattern effort started with a big document. Later they switched to an HTML-based tool that featured a description of the pattern, its application, and related patterns. Future releases will incorporate best practice examples. The pattern library has already been in use for some time. Christian Hübscher, ZKB, seconded Marcel's description – at ZKB, too, Business Analysts describe the GUIs. They usually don't have any background in HCI. Currently, their pattern library is limited to one application. This app is based on an organically grown piece of standard software (which, by now, shows a huge degree of inconsistencies). They have been building up their pattern library within the context of a redesign project. They're using a Wiki. The Business Analysts aren't using it for their daily work yet, though. This shall be changed in the course of the introduction of a new spec process, in which specs will be linked to the library. They're also building the library into their prototyping tools. From the ZKB's point of view, the pattern library needs to be well-structured and needs to be available electronically.

Daniel Felix jumped in as the advocatus diaboli and pulled out a number of style guides, asking: What's new about this actually? He said all the pattern stuff has been there before, even linking all the elements can be found in earlier style guides. This at least triggered a longer discussion on the question whether controls and patterns are the same, which showed clearly that most of the audience wasn't quite sure about or familiar with the concept either. In the end, it was mentioned that the big difference is that a pattern library should always go from the problem to the solution, while a style guide usually starts with the solution and then describes where to apply them. Bernhard von Allem, Roche, told us of how they started out to define a style guide and later realized they had actually defined patterns, as they had started from the problems. For him, a spec contains information on colors, fonts etc., stuff that doesn't belong in a pattern definition. He pointed out that patterns were "management compatible" – they are easy to "sell" to management.

Stefan Schallenberger, eGovernment Kanton Aargau and MASHCID student, related that they had derived their patterns from requirements and paper prototypes. For him, it's important that a pattern library isn't just a collection of stuff, but needs to be accessible (they're using an HTML tool). He said patterns limit the solution space and help to achieve consistency. At Kanton Aargau, the project has been a success: they're planning on redesigning 80 internal apps. Thomas Kneubühl, Postfinance and also MASHCID student, told us about his project "Patternfinder", which looks at why patterns aren't used more heavily and how to make them more accessible. He found 1400 pattern descriptions in 40-50 libraries, which could imply a high level of redundancy. Interviews within their internal development department revealed that patterns were completely unknown. They were looking at involving the future users of the library more, e.g. by having them create their categorization scheme themselves, using tags etc.

Finally Frank Leidermann, Swisscom, spoke about the customer center application, and organically grown, very inconsistent app. They put together a pattern library that abstracted heavily from the actual UI and relies on, among other things, inheritance. It partially contains controls or styles, partially flow diagrams.

The subsequent discussion focused on the following points:

  • Patterns are very interesting for HCI experts, needs to be defined by HCI experts and made available; the target audience, though, isn't usually HCI experts. No-one needs to be afraid that a pattern library could turn everybody into an HCI expert (and render us out of work). It does allow HCI experts to focus on the really interesting issues, though
  • A pattern library should never be released without proper training, and their usage implies common sense. Engineers were looking for solutions to copy anyway
  • Patterns aren't the same as guidelines. There should be one solution per problem that a company should agree on
  • Pattern Languages are valid within a given domain and move within certain forces, e.g. what's feasible technically
  • Do patterns need to be updated? Should we collect older versions? Are patterns that need to be updated patterns at all? Aren't pattern technology-agnostic?

As for the future of design patterns ("what's going on with patterns in ten years' time?"), the panelists saw these options:

  • Patterns will be tied into design tools and IDEs
  • Pattern libraries and guidelines will live side-by-side
  • The hype will have died down
  • Those who understand them will use them; those who don't will ignore them

Hunting for the optimal prototyping tool

This is a summary of my experiences with different tools for and approaches to prototyping. Prototyping is, eventually, a central area of work for interaction designers, information architects and people with other roles in the software development process.

Why prototyping?

Why bother? The aim of prototyping is to simulate the behavior of digital artifacts before any real development effort has had to be invested. This is driven from the insight that changes get more expensive the later in the development process they are realized – and anyone who has worked in software development knows that changes are inevitable. Change requests surface whenever you walk your project team through a design (no matter on which level of development you are right then). Requirements for an optimal prototype can be derived from this insight: Prototypes musts be

  • fast to create (with little effort)
  • easy to change
  • close to what will actually be built later
  • good to communicate (i.e. in a file format that can at least be viewed by the project team members, better even annotated)

With interactive products à la Web2.0 a new approach to prototyping becomes necessary – thinking in static pages doesn't help anymore as pages or elements thereof can look totally different based on system state (e.g., user unknown / known, but not authenticated / authenticated) or on user action (user has finished an action successfully / an error has occurred). It makes sense to introduce modular design into the prototype already – it'll be the basis for the technological realization anyway. This way, the interaction designers have vast degrees of freedom to have modules react onto events in other modules or to have them ignore other events. Based on this, another requirements becomes clear: the tool must support a modular approach to prototyping.

Prototyping techniques

Based on the goal you want to achieve, you can differentiate horizontal and vertical prototypes (assuming you've got limited time). Horizontal prototypes illustrate a website or an application in its whole width, but offer little or no functionality once you start drilling down. Vertical prototypes in most cases show only very rough illustrations of wide areas of a site or an application, but in limited areas, they provide a very deep and detailed view into the site's or app's depths.

If you're about to create a prototype for a usability test of a specific function, in most cases you'll want to build a vertical prototype illustrating this function in depth – and all the surrounding areas only very sketchy. If you'd like to explore the navigational behavior across a whole site, you'd rather build a horizontal prototype with very limited deep functionality.

You can create electronic or paper prototypes. Paper prototypes have got a number of advantages – they're fast to create, can be changed right in interview sessions with test participants, and because they are intentionally not finished, they invite people to playfully interact with them. They can be extremely helpful in very early project phases, because usually that's when the last requirements are being negotiated. The big drawback of paper prototypes is that you'll have to create recurring modules as often as they occur. Also it's difficult to hand them on or to document them.

Electronic prototypes usually have a more polished appearance about them. This can be a disadvantage when it keeps test participants from voicing change requests – because they could think the solution is already near completion. In addition, the participants cannot directly interact with elements of the prototype. On the other hand, a modular approach can (more or less) be realized, and you can hand on designs to the project team. Documentation is a breeze too.

HTML is quite well suited for creating interactive prototypes – if you're savvy enough and / or got the right tools. A nice example is Adobe Golive. Golive allows you to work with objects and recurring elements that can be defined outside the page. It's relatively close to development and the target system, which can become a drawback as well – when the prototype is used as the starting point for developing the actual system. You should by no means fall into that trap; otherwise Alan Cooper's scar tissue will be created: Code that has been adapted over and over again, that is not elegant anymore, and that's by no means easy to maintain.

Of course you can create HTML prototypes without using tools such as Adobe Golive (or Dreamweaver) – it's just more effort. In that case you'd need an environment that can handle modules (and you find yourself deep in the actual development process), or you start creating ugly solutions based on frames within frames to let appear single pages as modules. Both approaches are suboptimal for accelerated prototyping.

I'll exclusively cover electronic prototyping tools in the following chapters.

Prototyping using electronic tools

Microsoft PowerPoint

Microsoft PowerPoint is probably the most widely used prototyping tool. As it is installed on nearly every office PC, it's got the unbeatable advantage that everyone can view a prototype created with it – and can perform edits. This leads to another question, the question of ownership. A prototype must belong to one person, and only this one person is allowed to carry out changes to the prototype. Even if this sounds like lots of work for this one person – this is the only way to ensure that the prototype is consistent within itself and reflects the current state of the discussion. (There may be exceptions to this rule if there are very strict design guide lines that are known to everyone involved in the project and if there is a top-down mechanism in place ensuring that people follow these rules.)

PowerPoint allows for fast putting together and a very rough initial arrangement of elements. Elements can be linked to simulate interactivity to a certain degree. Later, once you've been talking to engineering with a finished PowerPoint-based prototype and you've got a first glimpse onto a possible end result, you'll realize why PowerPoint is actually quite ill-suited for building prototypes: Measurements don't fit at all. You'll fit lots more onto an actual 1024×768 web page or screen than what can be displayed (and read and edited) on a PowerPoint slide. In addition, PowerPoint's scaling functions can tempt users to make elements fit on the screen that would otherwise never fit – which, unfortunately, results in  screens that cannot be built like that anymore.

Another really severe drawback of PowerPoint is that it cannot deal with modules. PowerPoint only works with copy&paste – and once you've distributed an element on 40 slides and need to go at it and change every single instance of it over and over again, you'll realize that something important has been forgotten and / or PowerPoint just isn't the tool of choice. To summarize: Not suited except for very rough idea visualization.

Denim

Denim is an innovative tool for early phases of the definition process. You can create pages and their links on different levels of detail, even simulate a certain interactivity. It uses gestures, if available also using a graphics tablet. Circular contextual menus speed up usage quite a bit. The tool, which is written entirely in Java, is available for Mac OS X, other *nix systems and Windows. Unfortunately it's got one major drawback: it's not really stable. In addition, it starts eating system resources like crazy once files become big, and the built-in HTML export functionality only works partially and produces code that, strangely, runs only on Internet Explorer. It's nearly impossible to export to PDF or just to print properly. So: promises to become an extraordinary, very innovative tool, but isn't ready yet.

Apple Interface Builder

Anyone who's got the Mac OS X developer tools (on original Mac OS X system disks or downloadable from apple.com) can use Interface Builder to create really extraordinary simulations of Mac OS X user interfaces. Simulations? No – these are actual UIs, just without logic and data structure. Guides appear automatically when you start placing elements on the pane, ensuring that the placement is in sync with the latest version of the Apple Human Interface Guidelines. Amazing! Drawbacks: it's only well-suited for application design (and only support app design really well), runs only on Macs, and saves only to the proprietary .nib file format.

Microsoft Visio

Microsoft Visio is actually a tool for creating diagrams of all kinds. It's well suited for this task, and that's what I used to use it for quite a lot. It's also used a lot to create screen design concepts. It's got the big advantage over PowerPoint that the presentation is much closer to reality; you can actually get an impression of how much content to fit onto a screen. Working with modules is possible since Visio 2003 by placing files in files (see this very helpful article over at BoxesAndArrows). Stencils can be used for recurring elements, too. Unfortunately, Visio uses a proprietary file format; it can export into a multitude of different other file and image formats, but none of them is really good. (The same applied to OmniGraffle, by OmniGroup. Unfortunately, GomniGraffle cannot place OmniGraffle files. It's available for the Mac only; Visio is Windows-only.)

Adobe Photoshop

The queen of all image processing tools is used for prototyping purposes as well. As you can combine elements in layers (and layers in folders …), you can simulate a certain degree of modularity. The great possibilities in Photoshop tend to tempt designers to create a much higher-fidelity design of the prototype that what would actually be necessary (or desirable) at a given project stage. At the end there's a rather polished design that cannot be changed as quickly. High-polished designs, in addition, can impress participants in usability tests and keep them from voicing their opinions because everything looks so "finished" already. Photoshop can export to a number of file formats. A drawback lies in the huge data files, which can hinder data exchange. If you want to rather use jpgs or pngs – to reduce the file size –, you again need a tool like PowerPoint to ensure things are viewed in sequence (e.g., in a scenario), or you'll have to create and maintain a naming convention for file names. That's why I feel Photoshop is only partially suited for creating prototypes.

Adobe Illustrator

The BoxesAndArrows article shows that Adobe Illustrator and Visio are the only two graphics tools that support modular prototyping. You create elements in files you place (as PDFs, on Windows, native Illustrator files are supported as well) in other files. If you change anything in the elements, these changes are reflected nearly instantly in the main files as well. Finished versions can be exported to PDF; you can assume that the Adobe Reader is pre-installed on nearly all systems. If – in addition – you've got Adobe Acrobat, you can create coherent presentations and, if you've got enough time, even put in links to simulate a certain degree of interactivity. A drawback of Illustrator (even in the CS3 version) is that it still cannot deal with multi-page documents (even though Freehand had this feature for so many years ago – d'oh.). This can be smoothed out using the PlugIn MultiPage (by HotDoor). Thus, you can combine complete sets of view in one file, source out and maintain individually modules and optimize the resulting exports in Acrobat. Should you also have got InDesign, you can place the finished views (or the modules) in InDesign and create design comments directly there – supporting the life cycle from prototyping to design documentation. One big disadvantage of Illustrator is the steep learning curve you encounter when getting in touch with a complex vector graphics package like this.

Axure RP

Axure RP Pro promises to be a very interesting tool – including integration into Word and HTML export. The demo I've seen recently looked impressive, but it also comes with an impressive price tag.

Conclusion 

Personally, in terms of prototypes, I'm currently most productive in Adobe Illustrator, possibly combining it with Acrobat: fast; close enough to the final result, but not too close; modular, that is it supports fast changes; exports files to a commonly readable format (PDF) that can even be annotated with the appropriate tools (e.g. Acrobat Elements). As licenses to Illustrator are normally not available with every office PC the question of ownership of the prototype is solved as well: It rests with a small number of people who stay in control of the prototype.

(This is the translation of a post for my now inactive German-language blog from June 2006 – I've updated some small things wherever necessary.)

The Challenge of Internationalization

For my German usability blog, I interviewed Marcel Becker, Technical Manager International Portal & Products at AOL LLC, on the challenges of Internationalization ("I18N") and Localization ("L10N") of centrally built products. Marcel says,

Building internationalized products basically requires the development teams to make the products localizable. This means they can easily be translated in the respective target language (and use the appropriate char set etc). …
I18N and L10N are more like principles and attitudes which define how you actually develop a product. It is absolutely important that developers will follow established guidelines and are using standards to develop software. Sticking with legacy or non-standard approaches will not just mean additional work for maintaining applications, but maybe also creating additional interfaces when standard systems or applications are used to access non-standard systems.

Read the full interview in Marcel's I18N blog. (Or read the original German interview.)

Usability Engineering in Development and Customization of Enterprise Software

You will have heard of enterprise software systems, most probably you’ll have used one or the other system yourself. They usually have a bad reputation ? difficult to handle, cumbersome, sometimes of little relevance for the task at hand. Basically, most of these issues are usability-related. A typical after-work conversation may go:

– We’ve just implemented XYZ. And I hate it.
– Oh! That’s tough ? same here (or at a friend’s company, or ?)

Sometimes it feels like this conversation is part of the software implementation package ? as though people only fulfilled the expectations posed upon them by the situation. And while the ERP companies themselves are doing quite nicely business-wise, their products’ reputation still suffers.

But wait ? aren’t the vendors doing anything about it? Have there not been initiatives within SAP, IBM, Oracle, ? to improve the usability? Definitely. All of these companies have invested heavily in usability (and continue to do so).

Usability Engineering as Part of the Software Development Process

Usability engineers in the software development process have an interesting and challenging position. They need to understand the (rather complex and constantly changing) business requirements, translate them into application front-ends taking into account the possibilities and limitations of the technology, and negotiate with development on front-end-related priorities. Oftentimes, they engage in usability testing and / or reviews as well, feeding back user input into the application design team. And user research (via Contextual Inquiry or comparable field studies) becomes a more and more important area as well.

Application front-end design is a process of identifying the best compromise for a multitude of infinitesimal design problems: finding the best possible solution in a force field of different requirements and positions on the basis of a given technological background. When the usability engineer does her job well, the technologies’ possibilities are leveraged to their max, creating a solution that supports the users optimally in doing their job and thus contributing to their companies’ success. Usually, a solution has reached a certain (satisfactory) level of maturity before it is released; it has been tested extensively, and user research has been conducted to get solid support for design decisions. But then, why is it that users dislike using the software after this amount of user-centered work?

Enterprise Software is special in that it is never used in an off-the-shelf way. Through a long and thorough process, the software is “customized”, i.e. adapted to the processes and structures within the target company. This process deeply changes the software that came in the original software package. In fact, the instances of a software package used in two different companies can be very different, nearly incomparable.

Usability Engineering during Implementation and Customizing

Basically, the software in engineered a second time at the customer’s site. If things go well, there is a user experience specialist on the customization team, conducting field work, aggregating and prioritizing requirements and negotiating with project management on how to implement certain features. More often than not, this is not the case, and the requirements from the business are translated into code (and UIs) by technology consultants. As a user experience pro, it’s difficult to get a stand on an implementation project because they tend to be under much higher pressure than the development projects. You will have had to convince your project lead first and the customer second to take you on the team. You’ll have to prove that your works adds value and improves the final solution, and often the UX work will only be part of your role (i.e., you’ll be working on visual design adaptation, change management etc. in addition to the user experience aspects). As far as the level of commitment to and awareness of user-centeredness is concerned, the consulting business is quite a bit below the level typical development units have achieved in the last couple of years. To my experience, it’s the exception rather than the rule that a dedicated UX pro is part of the implementation team.

This is understandable. Implementation projects are always under time and money pressure. “Typical” UX work with ethnographic studies and several iteration cycles doesn’t seem to fit into these constraints. What is needed is an understanding on the consultancy’s and the customers’ side that user experience design in implementation projects needs to be taken care of ? that the changes to the software affect the user experience and usability. The implementation team needs tools to support discount usability engineering and ways to ensure decent usability even if the project has been staffed without a UX pro. (The B?ro f?r Arbeits- und Organisationspychologie (BAO), Berlin have conducted some research projects on ergonomic customizing of SAP software.)

A Solution: UI Patterns

We’ve got a dilemma here: The software company invests in usability engineering for a “raw” product but cannot foresee all possible changes. The implementation partner can only move within the time and money constraints set by the customer and within the boundaries set by the limitations and possibilities of the software. And the customer cannot spend any more money on the project and expect it to deliver good quality.

The UI patterns approach might be a solution to his dilemma.

The software company needs to change their software to be UI patterns-based. The patterns would have to encapsulate UI best practice, no matter how they are parametrized (i.e., set to look and act as a certain “flavor” of the pattern). To achieve this, close collaboration between the implementation partner and the software company must take place. Both parties must ensure a knowledge transfer about what requirements there are in the real world and what answers can be created in the patterns. In the end, the UI patterns need to be frozen ? the implementation partner should not be able to change the internal workings of the patterns, but only parametrize them, responding to the customer’s requirements. Of course, there needs to be a feedback loop from the implementation partner back into development to ensure no crucial flavor of a pattern has been overseen.

If the software company have done their job well, i.e. if most possible requirements have been taken care of and a decent usability within and across the patterns has been ensured, switching to a UI patterns-based approach will solve the problem ? and it will speed up implementation (and, after this first investment, development!) projects tremendously.

Using User Interface Patterns as a Design Framework

Design Frameworks in UI Design have come some way. Starting out as conventions amongst designers, then platform standards or standards across a number of platforms, to a written-down and agreed-upon set of guidelines, we have arrived at pattern libraries. Just recently Yahoo! released their UI pattern library to the public, allowing designers to profit from their research and development effort. Design Frameworks not only offer guidance as to how to design things so that a certain level of consistency is achieved. Their real power lies in structuring the way designers think about their domain and the tasks their users are doing: They can be used as tools for requirements engineering as well. But some hindrances need to be overcome.

What are Patterns?

The idea of patterns originated in architecture with Christopher Alexander's 1977 book "A Pattern Language". Alexander noticed that certain design problems kept occurring in different contexts but afforded a relatively small number of similar solutions. So he created the idea of patterns as the optimal solution to a given question in architecture. It could deal with a room, a building, a street, a town, or some transportation infrastructure. Alexander identified and described a set of design patterns and a "pattern language" that described the interrelationship between the patterns. Later, the idea was adopted in User Interface Design, and Martijn van Welie and Jenifer Tidwell started researching and publishing design pattern libraries for user interfaces for PCs; later these were expanded to cover different devices.

It is important to understand what patterns are not: patterns are not single interaction elements (or controls). They are not solutions to simple problems like "select one element from a list". They are parameter-sensitive sets of controls, interacting with each other on a given input and creating a certain output. Their aim is to support one specific design problem. Use Cases are one way of stating design problems. Basically, design patterns can be defined as optimal solutions to a given abstract use case, and a design pattern in context (i.e. with the right input and output parameters) represents the design solution to a specific use case.

Just as Christopher Alexander set up a number of patterns and defined a pattern language, a pattern-based design approach requires a basic set of patterns to choose from. Your pattern library is the toolbox you need to build your applications from. So, how do you create a pattern library?

Creating a Pattern Library

A pattern library needs to have a critical mass, to contain a certain number of patterns to work. It's useless to start with too small a number of patterns because you will end up trying to "squeeze" your applications, to fit your requirements to the patterns. That's not sensible. You should have patterns for all major places in your apps. E.g., in business applications, you'd need at least one list pattern and one framework / container pattern for actually viewing / editing business objects. Within the editing container pattern, you'd most certainly use different patterns for applying actions to the object. These patterns need to be there in different flavors to provide notifications (like success or failure messages).

Defining a pattern library is not really a democratic process. There needs to be a group in charge of the pattern library, and their task is to document patterns, evaluate requests for new patterns, and keep the number of patterns low. A high number of patterns not only increases design ambiguity and waters down the guiding power of patterns, but also increases maintenance effort. Therefore, all patterns should go through this central group to be approved.

The best way to arrive at a sufficient number of patterns is to take a close look at some exemplary applications. Abstract the use cases and activities undertaken in these apps from the actual design solutions. Out of the number of use cases, a limited number of recurring activities will emerge. Based on your industry, your users will mostly edit business objects, browse image libraries, request information on articles, or search huge databases of information. Within each of these domains, only a limited number of sufficiently different activities exist. For each of these core activities (i.e., for each of these design problems) an optimal design solution can be found. Try to identify the solution or solutions that are applicable to most or (if possible) all your use cases. Draft and iterate it until a somewhat stable solution emerges. This is your first pattern. Write it up on a Pattern Card, describing the design problem, the usage context, constraints, dos and don'ts. Then move on to the next pattern until you think you've covered most cases. Then go back into actual application design and re-design your apps, incorporating your newly-defined patterns

as you go. You will undoubtedly encounter numerous cases where your patterns don't fit as well as they should. Document these cases, but try to keep the number of patterns low for the first iteration. Once you're through with your apps, go back to the drawing board and re-evaluate your work from a certain distance. Think about the difficult cases – do they warrant new patterns, or can the existing patterns be extended to satisfy the newly discovered needs and requirements?

Once you've arrived at a stable number of patterns, you can go the next step: get the design patterns wrapped in code so that you end up with a number of components. Believe me, it's easier to start later, once the requirements and flavors of the patterns are clear and been through at least one iteration. Now it's time to profit from the work you've invested.

Harvesting the Crop

As soon as you've got design patterns and components – their equivalent in code –, you can benefit from your previous work: You'll realize how much patterns speed up the process of product definition and development. On the way, you'll notice that you've changed a number of job descriptions: UI design is changed from creating specific solutions to every problem anew to rather analyzing the use cases and identifying the most appropriate patterns for the problem at hand, including the right flavor of a given pattern and well as connecting the patterns in screen flows. Visual design will be freed from tactical day-to-day business to pursue more strategic design approaches. And development's tasks change from creating new solutions over and over again to configuring the existing patterns, wiring together the solutions, and create new and even better patterns. (Basically, given a Business Process Design Time suitable for end-users, business architects can be empowered to plug together basic applications from the patterns – as described in Dan Wood's 2003 books "Packaged Composite Applications" and "Enterprise Services Architecture".)

So, adopting a pattern-based design approach not only changes the processes of product definition, design, and development, but also the responsibilities within the development organization. Change Management should be involved in every step to avoid rising levels of frustrations in a great number of departments.

Once you start using your pattern library as a framework for requirements gathering it gets really interesting. As your pattern library contains the boiled-down interaction design approaches about your design problem domain, you can create standardized interview guidelines using the patterns to structure your interviewees' responses. For example, if your pattern library contains a pattern "list of business objects that I must work on" and one pattern "overall list of business objects with advanced filter mechanism", your interview could touch questions like:

  • Do you have a list of things you need to do – are there objects you get at certain times and need to work on, and once you're finished with them, they can disappear from the list? Which ones? The objects mentioned now should be part of the "list of business objects that I must work on" pattern.
  • Do you need to access objects regardless of whether they are new, in progress, or done? Which ones? What are the criteria you use to find the relevant object quickly? These objects would be part of the "overall list of business objects", and the "advanced filter mechanism" can be parametrized according to the answers, too.

With the right set of questions, you can cover all your patterns and understand how they need to be set up to meet the users' requirements. But don't forget to listen for any hints at things missing, ideas and concepts not covered, or elements rather "squeezed into" the design system your patterns represent. It is possible (and, at first, quite probable) that you will learn that your patterns don't quite fit, that a new flavor or even a new pattern is needed. A pattern library is a living structure that will evolve over time, and so will your design thinking.

So, you might ask, where will this lead us? Once we have a pattern library in place, once we've streamlined our UI design and application development approach, what next? Let's take a look into one possible future.

Vision: Towards a competition of components

Apple's Mac OS X Automator.

Imagine a computing world that has got rid of monolithic applications – on the desktop, on the servers, everywhere. For every purpose, the best possible component can be chosen and just plugged into a framework supporting and living open standards. "Application development" means: business experts define the processes, and business architects select the appropriate components and parameters, following an approach as described above. Using an application design time much like Apple's Automator, elements can be plugged together and auto-negotiate their interfaces and data exchanges.

Part of this is true already. SAP's NetWeaver platform is the first to use the term "applistructure", a Forrester Research-coined term for the convergence of "application" and "infrastructure". And SAP is not the only one on the market with a comparable offering for enterprise software. But on the desktop, much remains to be done. A concept for a basically document-centric approach to desktop computing was presented by Jef Raskin in his book "The Humane Interface", contrasting it to the current (well, 20+ years old) "application-centric" approach. Raskin asks: Why force people to buy an office suite that is poorly integrated when they could rather buy the components they need – a text editor, a chart drawing component, etc. (Well, Apple tried to introduce this approach as "OpenDoc" in System 7.5 to 8.1, unfortunately, rather halfheartedly, and then killed it.) It would be up to the OS manufacturers to provide the necessary infrastructure. And it would be up to a great number of small software companies (Independent Software Vendors) to compete for the best possible components available for a given user need. This would create a whole new momentum on the market, out of which everyone would benefit – well, maybe everyone except for the companies producing office suites right now. But then, why not prove they've got all the experience to create the best competitive components?

And the fascinating thing is: It's started to happen on the Web already. Basically, all the Web2.0 hype is about people composing their "information and application cockpits" tailored to their needs, based on an open infrastructure and publicly available components. And I guess that's just the beginning.

On Eye Tracking – an overvalued technique

Recently our Hamburg User Experience Roundtable took place at the offices of the local market research and usability evaluation institute, SirValUse. Our hosts were happy to give an impressive and well-founded talk on one of the techniques they’re using – eye tracking (you can download the slides here – sorry, they are in German). As most of you will know, eye tracking is a technique used to track a subject’s focal point on a given visual stimulus.

It is assumed (and highly probable) that the focal area is also the area of (visual) attention and that properties of the stimulus in the focal areas are perceived, cognitively processed, and more or less consciously interpreted. When the focal areas are plotted over time, so called “heat maps” can be created that give insight on which areas on the stimulus seem to attract the users’ attention and thus are processed best. Now comes the interesting part: It is also assumed that the more attention an area gets, the higher the probability that the user sees, understands and acts upon a given property of the stimulus. So, for a screen design, if a given function is placed in a presumably hot area and that area stays hot during the re-test, everybody is happy.

This is something I don’t understand. For me, there is no direct connection between eye tracking (i.e., visual attention) and user action. Attention in itself is free of value, it is neither positive nor negative. The processing and the interpretation are the important things about stimuli. The fact that users see something doesn’t mean they will click on this thing, perform their tasks faster, or enjoy a better user experience. True, eye tracking can be used to see whether a given ad diverts the users from the content, or whether a certain link is in an area that’s likely to be scanned at all. But on the whole, visual attention just provides the data necessary for a user to decide on further activity. Thus, for me, eye tracking is a technique that can be used to maybe support a usability test or an expert review, but it’s not a usability evaluation method in itself – it’s great for research, and the result should be collected and made available in big books on human perception (just recently, Jakob Nielsen published a new eye tracking-based study in his Alertbox that is basically this kind of fundamental research). My colleague and friend Frank Ollermann, University of Osnabrueck, supports this point:

Basically this is about objectively assessing visual attention. No other technique can assess visual attention in such a timely accurate manner as error-free as eye tracking (provided the research design is sound). That’s what makes eye tracking so valuable for basic research, though less for usability evaluation – as it only provides indirect information on usability. Most information on usability can be assessed with other, less extensive techniques. For example for web design most of the time you’ll just find out whether a given element has been seen or not. (…) The question is whether this information could not have been gotten by easier, e.g. through an interview. In lots of cases the client insist on eye tracking because it’s ‘sexy’ and because you can impress other clients or the organization executing the project. So, I’d say: eye tracking is an indispensable technique, but it’s not, however, indispensable in the area of usability evaluation (personal communication, May 9, 2006).

The funny thing is that lots of researchers and practitioners know this fact. But few people say so. There is big money in eye tracking, and the heat maps are great for senior management presentations. I think that’s the biggest reason eye tracking is the latest hype in the usability field.

Prototype-based xApps Design Process

I've recently come across an article I wrote back in October 2003 for SAP Design Guild. The text deals with the xApps design approach we were following then; driving product definition and design through rapid prototyping. In the article I describe the process we were using – quite successfully, I'm proud to say. From the introduction:

In the following text, I describe the prototype-based design methodology used by SAP's xApps Design Group. I explain the prototype development life cycle, discuss the advantages and disadvantages of different prototypes and prototyping materials, and illustrate how the prototype approach fits into SAP's xApps software development life cycle.