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

Designing the (AOL Phone) Box

AOL Phone Box (small image)In August 2006, AOL Germany launched the AOL Phone Box, an AOL-branded ADSL 2+ modem / router with integrated 4-port Ethernet switch and VoIP telephony functionality. When we started working on the AOL Phone Box project more than a year ago, the AOL Germany world looked quite a bit different: AOL was one of Germany's biggest ISPs, providing a huge number of customers with fast DSL Internet access (and a big number with slower narrow-band dial-up access); the web-based products like the portal, e-mail, instant messenger offered functionality on top. Now, the access business has been sold to Telecom Italia, and AOL is turning itself into a portal player, offering free e-mail, news, and other web-based services and content. Time flies …

The project had a number of goals, apart from just creating the Box:

  • Create an Internet Access Device that is simple and straightforward to set up – in order to reduce the number of support calls (setting up the access device is a major call driver).
  • Create a compelling, appealing user experience make people want to possess the box.
  • Build up in-house expertise on how to create hardware products for future projects.

After quite a bit of research, the project team decided on working with a German manufacturer, Bautzen-based Sphairon Access Systems. Sphairon had a hardware and software platform that looked very promising, and they had lots of experience working with various telecoms – they build DSL splitters, Internet Access Devices, ISDN NTBAs and other devices needed for telephony and Internet access. We started out from an existing product, but had it completely revamped to fit our ideas of what an AOL-branded device should look like. Nuremberg-based industrial design firm B/F Design supported us here – they created innovative rough designs, did fantastic renderings and great prototypes.

The Interactive Design sub-project had a couple of tasks:

  • Revamp the existing user interface to make it fit into AOL Germany's visual design language.
  • Check and improve the user flow to achieve a higher level of usability.
  • Control and manage external development and design efforts.
  • Innovate on new features and parts of the offering.

Where we were coming from

The closest relatives to our AOL Phone Box are the members of Sphairon's line of Turbolink devices. They feature quite a versatile, extendable hardware platform, but come in a rather plain, matter-of-fact shell. The IAD shown below was presented by Sphairon at the 2005 CeBIT.

Sphairon Turbolink

Likewise, the design of the configuration web interface was a bit plain, and we felt it could be improved a bit – it had to be adapted to our visual standards anyway. We therefore adopted a visual style that mirrored our AOL Germany portal design.

How we got there

First, a new shell was developed by B/F Design. It needed to reflect AOL's brand values – Human Individuality, Top Quality, Elegant Simplicity, and Inspiring Enjoyment – and look high-class. I think they did a tremendous job.

AOL Phone Box

Reversed-engineered Information Architecture for Web FrontendIn parallel, we reversed-engineered the existing browser-based configuration front-end – we created a site map containing all the places and functionality. We then compared this site map to our list of desired features and started moving functionality around, restructuring the configuration tool's organization. After deciding which functionality should be experts-only and which should be available to all users, the IA for the web configuration was finalized and wire frames for a number of screens were created to illustrate the arrangement of elements on the UI. To get the web configuration tool to sport our visual style, we developed a visual design style guide especially for this product and delivered all the necessary assets to Sphairon, together with a couple example screens. We then moved on to defining two new parts of the AOL Phone Box experience: the "Einrichtungsassistent" (setup assistant) and the "CD-Intro" (CD-based introduction to the product). The customers should use the CD-based introduction to get the cabling right; once everything had been connected properly, the setup assistant (resident on the hardware) should take over and lead the user through the basic configuration of the product. To the user, this two-platforms approach should feel like one seamless process. During the interaction design process, we especially focused on possible error conditions: We analyzed them and either tried to circumvent them, or we used them to help users identify what might have been the cause of their issues and to help them out (again, a way to reduce Call Center volume and thus cost).Extremely close collaboration in the team and with our development partner Sphairon helped us make great progress, and we took great pride in seeing our ideas get realized and the designs getting closer and closer to what we had envisioned.

Design and Usability Evaluation

After some time of working on a project, you lose the ability to actually assess a solution's quality. So, at two points in the development cycle, we conducted usability evaluation measures with our partner HCiconsult. Early on (with a rough version of the UI in place), a heuristic evaluation was done. Later, when the development was 2/3 complete, we had a usability test conducted with seven test participants. Both measures showed we were on the right track, but of course there was still room for improvement. The findings were discussed and incorporated into the design iterations.

When we started to think about packaging and printed material, we realized that it would be highly desirable to provide a consistent wording throughout all materials – be them on the configuration UI of the box, on the CD, on the packaging or on leaflets. So we provided the necessary wording and operated as wording QA for the electronic manual. While this was quite an extra work package, it nicely followed the philosophy of an end-to-end design responsibility.

AOL Phone Box packaging

A challenging and rewarding project

In the end, the Interactive Design team had contributed in the following domains: For Interaction Design, we had contributed Information Architecture, user flows, and screen layouts. As for Graphics Design, we had created Visual design standards and provided the graphics assets for the development partner. Wording of all customer-facing texts including Web Interface, packaging, and manual had been provided by us. We had had our say in the design of the packaging, and of course there had been the final sign-off of all materials by the Director Interactive Design.

The AOL Phone Box has proved to be quite a success. The expected benefits were realized, the customers love it, and we have not only delivered a fantastic product, but also learned a lot – and had quite a bit of fun.