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