Tag Archives: z?rich

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

A Country-Wide Exercise in Marketing

Switzerland is very beautiful. You've got the tremendous landscape – the distant Alps, the blue lakes, green meadows. And Switzerland is very prosperous. I've stopped counting the number of extremely expensive cars I've seen these last weeks (Aston-Martins, Rolls Royces, Ferraris, Lamborghinis). Zürich especially "breathes" money and stability. The quality of service is impressive – people are very conscientious, and especially the civil servants so far have struck me as very friendly. Plus, the quality of the edibles and ingredients you can buy even in the supermarkets is so far from everything we were used to in Germany that we regularly end up buying much too much because we want to sample everything. This, together with Switzerland's well-known neutrality, is expressed best through one symbol: the famous white-on-red Swiss Cross ("Schweizerkreuz"). The Swiss are (rightfully) proud of their country, and they show their pride everywhere. You cannot walk through the city without seeing at least a dozen Swiss Crosses.

There are some stores (like the "Schweizer Heimatwerk" on Bahnhofstrasse) that seem to offer only those articles that show the Swiss Cross. And there's quite a bit of them. Likewise, you seem to be able to get about every article where at least one brand has chosen to use the Swiss Cross as part of their design and packaging. The omnipresence of the symbol and its re-affirmation through all the high-quality experiences strikes me as one of the best-concerted exercises in marketing I've come across so far. The Swiss Cross symbolizes outstanding quality. Those employing it profit from it, but it also feels as if everyone using it it has subscribed to a certain voluntary self-commitment as well.

New Job, new City, new Country

Swiss FlagStarting today, I've got a new job. I'll be working as User Experience Designer in Google's European Engineering Center in Zürich, Switzerland[GP:GoogleZRH]. Quite a change: a new job, a new city, a new country – with a somewhat similar, but also rather different language. Germans can easily be fooled into believing that things in Switzerland work just like they work in Germany because of a common cultural heritage and the language. Switzerland is not a member of the EU, for example, which means that we had to get stay and work permits etc. Lots of things had to be organized (and some still have not been dealt with properly): relocation, stay permit, health insurance, all the other insurances. Google was very supportive with these things. I'm very much looking forward to all the challenging projects that lie ahead Smile, and I sincerely hope we'll manage to "arrive" and settle down in Zürich easily.