Let’s Talk Design Patterns – produktbezogen im Gespräch mit Peter Boersma

Wie ihr sicher aus meiner Artikelserie Bauanleitung für eine Pattern Library wisst, beschäftige ich mich ausgiebig mit dem Thema Pattern Libraries, Design Systems und Styleguides. In diesem Rahmen treffe ich auch immer wieder auf interessante Experten. Einer dieser Experten ist Peter Boersma, der vielen aus der Szene sicher von der ein oder anderen Konferenz bekannt ist. Peter beschäftigt sich schon sehr lange mit dem Thema (long before it was cool) und ich freue mich, dass Peter die Zeit für ein Interview gefunden hat.

Lest nachfolgend über seine Erfahrungen zum Einsatz von Patterns im Unternehmens- und im Agenturkontext, was er von den unterschiedlichen Bezeichnungen von Styleguide bis Design System hält, wie man Management und Kunden vom Mehrwert überzeugt und einiges mehr.

 

Hey Peter. It’s great to meet you. First of all, please tell us a little bit about yourself.

Well, I’m a Dutch guy who grew up around the time computers made their way into people’s houses. I spent quite some time with my Commodore-16, creating games for myself and my brother, and then creating tools to make that work easier. A couple of years later I found myself studying Computer Science but realizing I found it much more interesting to make the right things for people than to make computers faster. I started adding cognitive ergonomics classes to my doctoral program, followed by business classes and educational science classes, and graduated as an information ergonomist in 1995. Since then, I have been working on concepts for information systems, mostly interactive websites, for agencies, software companies and, most recently, the City of Amsterdam. I also live in Amsterdam, with my wife (who is from Germany) and my two sons (who spend half of their time with us).

 

People told me that you are a real design patterns maven. How did this topic catch on with you?

I’m quite sure I’m not the world’s expert on design patterns, but I do have some experience with them. When I was working for Satama Interactive, around 2000, both our client Nokia and our own teams realized that we kept repeating ourselves when we designed new parts of their large, international collection of websites, but that we did’t have a way to capture previous design decisions. So we started a system for that and it tuned out that a pattern library was the best shape. At this time we had Martijn van Welie on our team, who was developing the Pattern Library for Interaction Design which can still be found at http://welie.com, and who helped us shape our thoughts. With a small team we devised a layered structure for patterns that ranged from Nokia’s business and brand levels, via experiences and interactions, down to working HTML code.

A few years later, at the 2006 edition of The Web and Beyond, I interviewed Martijn and Bill Scott – who was at the time curator of the Yahoo! Design Pattern Library – and in preparation for that I researched different pattern libraries. Around that time I realized that design patterns could potentially be linked to (design) process patterns and got the idea that the process patterns could be documented in potentially similar libraries. I presented this idea at that EuroIA where my biggest question was: what would a design process pattern library look like?

And of course, at most of the agencies where I worked as a designer, we started pattern libraries, either “white-label” best practices oriented at re-using front-end code, or explicitly branded ones aimed at visual design, or collections aimed at creating interactive prototypes faster.

 

A Process Pattern Library sounds very interesting. Tell me more about this Idea of yours. Did you end up building one?

I challenged the audience to start designing “a database on infospaces’ design patterns and process patterns.”. Unfortunately, this never happened at the scale that I would like it to happen.

I myself tried it once more, when I worked with a colleague at SDL on the “SDL Customer Model” in which we planned to document patterns for, amongst others, content management related work processes, which would then be built into our content management software as prescriptive models, turning it into so-called ‘opinionated software’. (See more on that on slide 81-90 of this slide deck: SDL added strategists to a UX team).

More details about the idea of a process pattern library can be found in this slide deck: Processes + Patterns. The main question starts at slide 55 (“What if we could”) and on slide 60.

 

A couple of years ago pattern libraries were – sort of – “old news”. Why did this topic gain so much traction during the last years?

Well, I think Twitter Bootstrap (now simply “Bootstrap”) certainly helped! When that arrived in late 2011, along with the whole responsive design movement, suddenly a lot of front-end designers and developers saw the benefits of a well-documented and consistent user interface design library. And when people started creating their own libraries, they realized the benefits of making the code visual by adding examples.

 

What’s a bit confusing are the different names in use. Some people are talking about Pattern Libraries, others about Styleguides and quite recently we heard about Design Systems. What’s your interpretation of those three things? Different words for the same thing?

Style guides are the type that have been around the longest and they are traditionally made with a focus on visual design aspects: they contain specifications for font sizes, colours, margins, etc. but also types of images and visual effect filters that should be applied. Later, you saw a broader type of style guide appear, with interaction patterns, navigation rules, and editorial or content principles, aimed at more interactive websites that were iterated on a lot and could use a documented system of already-established design decisions.

Pattern Libraries are, at the core, “just” a format for documenting patterns. But when done well, it is a very powerful format that can be expanded infinitely, and can exists of many layers, each focusing on other details of a solution, ranging from the business reasons (“why should we build this?”), via the functional layers (“what do we normally build?”), to the front-end or even back-end code (“how does it work?”). In practice, they focus on either the functional layers, when interaction designers control them, or the code layers, when front-end developers control them.

Design Systems are supposed to combine all of the above, maybe with the exception of the business layer. And they’re supposed to cover all of a companies’ product and service touchpoints, definitely the standard interactive ones that come in small to big screens around your desk, but ideally also big touch-tv’s, point-of-sale kiosks, and maybe even Interactive Voice Response systems and the parking meters at HQ too! History will tell if Design Systems simply become the new name for the combination of not-just-visual Style Guides with multi-layer Pattern Libraries, or something more.

 

As I could see in your resume, you worked for agencies but also companies and organizations. Is it different working with patterns from an agency vs. an in-house perspective?

I can say “it depends” once, right? ;-) Because it does depend, and mostly on the range of products that need to be designed.

When I worked at EzGov, we did most of our work for one client: The UK’s Inland Revenue (now HM Revenue & Customs) where we designed interactive applications that were often “transaction based”, which is a euphemism for “it consisted of a lot of online forms”. Over time, we were able to create a style guide for our interactive prototypes that allowed our information architects to create screens that were almost 1-on-1 copies of what was later designed and implemented by the front-end and back-end developers. So, for that one client, we created a comprehensive, branded style guide aimed at navigation and interaction patterns. For our other clients, we could re-used some of the interaction patterns, but the visual style and therefore the front-end code had to be done from scratch, making the pattern library useless for those projects. The pattern library for Nokia was similar, in that sense.

At Blast Radius Amsterdam, a marketing agency that did a lot of its work for two clients (Michelin and Nikon), we were never able to benefit from a style guide, even though we made many iterations of the same type of sites for the same client: the tyre selector for Michelin and the catalogue pages for Nikon. The reason for this was that we were doing marketing projects where doing the same thing again and again does’t work: you have to innovate, be creative, think out of the box, and create memorable experiences that “wow” prospective customers. Our applications had to look and feel different with every major release. The closest things to patterns that we had for these clients were a set of test-patterns for Michelin (certain cars or combinations of seasons and tyre-sizes yielded non-standard results that had to be dealt with correctly by the tyre selector) and a set of business and design principles for Nikon (“be the guide to aspirational photography”, “increase pre-purpose consideration”, “provide engaging post-purchase experiences”).

And finally, in my latest project for the City of Amsterdam, we have created a pattern library that can be shared with 3rd party suppliers who design and implement parts of the “My Amsterdam” eco-system that we envision. The audience therefore is not our own team of designers, and there is absolutely no back-end code involved. But we have to deliver it in a way that allow us to control future updates to the visual style and layout of screens, forcing us to think about the delivery mechanism and the life-cycle management of the library.

And all of these aspects, white-label vs. branded, the different layers that one can focus on, to the way the patterns are delivered to the users, can all become relevant at consulting agencies, in-house teams, and non-profits alike. The world of patterns has so many facets that it will always be an interesting topic to discuss and work on for designers of interactive products!

 

Building the right pattern library for the right job is quite challenging. But it is not the only big challenge that comes with it: How do you convince the customer / your management to invest into building a pattern library? (Remember, you already said “it depends” ;)

Investing is overrated :-) I’ve noticed a tendency to overthink the technological choices, maintenance issues, and governance models. Most of the real work goes into reflecting on work and deciding what is and what is not a pattern. An atomic CSS structure is not a design pattern. A dedicated DevOps team and GitHub library does not mean you create great patterns. A pattern library is a curated, interlinked set of generalized, proven solutions that each fit a certain class of problems, documented in a structured fashion. There is no need to “invest” in building that; it’s what good designers do.
The investment comes when you want to share that set with others, in a reliable and repeatable way. But by that time, your design team should have saved up time and money to make it worth it.

 

You said above that in marketing driven design a pattern library might not be a big help. Are there any more cases where you wouldn’t recommend implementing a pattern library?

I’d say that unless a startup is designing a lot of similar interactive products, one shortly after another, it is probably not a good idea for them to focus on implementing a pattern library. Another is where you are building some bigger system, but you have no feedback from real users yet; you may be working on the most consistent design ever, but if it proves to not work for the users, you need to change it first before you document it in a library. And finally, if all your patterns are documented in other people’s libraries, I’d simply point your designers to those.

 

Last question: Tell us about one thing or one person that inspires you?

Jared Spool inspires me. He’s been active in the field of user experience for a long time, and all of his work is based on proven “patterns”, backed up by research, packaged in understandable formats, presented in funny and memorable ways, at junior colleges and business-leader conferences and on top of all that, Jared is a wonderful person to hang out with!

Thank you for your time and ideas, Peter!


Ihr habt auch Fragen an Peter? Schreibt sie einfach unten in die Kommentare. Ich habe Peter gebeten, gelegentlich mal vorbei zu schauen und vielleicht weiß er ja eine Antwort. Er versteht auch ganz gut Deutsch.

Über Wolf Brüning

Wolf arbeitet als Executive UX Designer in der Abteilung User Experience der OTTO GmbH & Co KG und kümmert sich hier mit seinen Kollegen um Konzeption und Interaktionsdesign der vollständig inhouse entwickelten eCommerce-Plattform des Konzerns. Vor seiner Hamburger Zeit hat Wolf in verschieden Web- und Usability-Agenturen gearbeitet und in Magdeburg Computervisualistik studiert. Wolf ist Mitgründer von produktbezogen.de und kümmert sich neben den Inhalten auch um Design und Technik des Blogs.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mit Absenden des Kommentars stimmst Du der Speicherung deiner persönlichen Daten (Name, eMail-Adresse, Webseite und Nachricht) durch uns bis auf Widerruf zu. Zur Vermeidung von Spam und zur rechtlichen Absicherung wird deine IP für 2 Monate gespeichert. Ebenfalls zur Vermeidung von Spam werden diese Daten einmalig an Server der Firma Automattic inc. geschickt. Zur Darstellung eines Nutzerbildes wird die eMail-Adresse im pseudonymisierter Form an Automattic inc. übermittelt. Wenn du einen oder beide Haken für die eMail-Benachrichtigungen setzt, wird deine eMail-Adresse bei Automattic inc. gespeichert. (Datenschutzerklärung)

Du hast noch viel mehr zu erzählen?

Dann schreib doch einen eigenen Artikel auf produktbezogen.

Artikel vorschlagen →