Much like genres (see previous post: Can we describe interfaces as genres?), design patterns aim to create a classification scheme. Alexander created his methodology, in response to his feeling that designers in a post-industrial society lack the knowledge of materials and construction methods that people in a pre-industrial society have, via tradition. The slow evolution of tradition allows humans to adapt, slowly, in context, therefore identifying optimal solutions (optimal for humans, optimal for nature and the materials in use). To compensate for the lack of tradition in new materials and construction methods, Alexander described a methodology that consolidated research about human behaviour and the form that is required to support that behaviour into a hierarchical ‘language’.

He describes his methodology as a language with elements that have an explicit relationship up and down the hierarchy: in a way that the syntax of a language might work. Users of the pattern language identify the pattern (unit of the language) most relevant to their design problem (perhaps designing a house). They should look up and down the hierarchy to identify the other patterns (designing a street of houses or designing a kitchen) that also have an effect on the problem. In this way the designer can discover the entire context in which the problem sits and circumvent the lack of tradition.

Often with patterns the issue of stifling creativity is raised. Patterns are created and presented in a way that present the context, form and a high level solution to a problem without specifying the detail. Alexander went so far as prescribing the way patterns should be communicated: relying on clear labels, open descriptions and what he calls constructive diagrams (diagrams that appear in sketch format, describing the solution at a high level) to describe the pattern. Patterns can be used to speed up the design process, ensuring that designers do not reinvent the wheel with every new project they undertake. A designer can focus on adding to our body of knowledge and tackle new, more demanding problems when familiar and common problems clearly are described.

The question is whether we, as interface designers, can create languages that apply to our design problems? Interfaces have a history of only approximately 40 or 50 years; design patterns would definitely help us overcome our lack of tradition. There are reoccurring problems that occur. My opinion is that, yes, we could create a pattern language for interfaces if the focus of that language was user behaviour in reaction to a context and not specific interface layout.

Many people have created pattern languages for interfaces. Among the most referred to are: the Yahoo! pattern library and Tidwell’s Designing Interfaces. Both are interesting and provide insights that add to any design challenge. However I find them quite prescriptive. There is a lack of overt hierarchy and solutions seem to be specific where writers have chosen to include individual examples rather then stick to the high level constructive diagrams that Alexander described. I did find one example (after an inexhaustive search: other examples are welcomed) that I found to be true to his methodology and useful to me. The Design of Sites, although potentially out of date now, provides an almost hierarchical organisation scheme and describes the relationship up and down that scheme; informing the designer of contexts and reactions to them. Solutions are described using constructive diagrams, allowing for creativity.

I think that we are only beginning to conduct enough research to create a true pattern language and all interface pattern languages should be regarded as works in progress as there are many more contexts to understand thoroughly. We will get there however; it did take Alexander 10 year and he had many collaborators to provide us with his one example.

I was invited to talk to the students at the Akademie Fur Kindermedien in Germany on the topic of classifying interfaces. Two other speakers also spoke: Mario Giordano and Nicole Kellerhals (a consultant script writer).

We were asked: how can the rules of genre help define the creative and productive process. Immediately this statement made me uncomfortable. The use of the word genre seemed inappropriate as it promised more then we currently know. The definition of genres, in writing, film, theatre etc., has developed over a long time. When a particular genre is mentioned, instantly we (the general public) have an idea of what it refers to; take a thriller film as an example. The thriller genre has a fast pace with frequent action; they are full of suspense and often end in cliffhangers. In this way films can be arranged into clear categories, genres, which the audience understands. Producers and publishers exploit our understanding of genres in order to market new releases.

Genre is used as a tool during the creation process where authors can use the rules of a particular genre to guide them. Nicole Kelerhals spoke about this: describing the commonly understood elements of many film genres, she showed how each have their own distinctive elements. Mario Giordano gave authors instructions based on Raymond Chandler’s rules of crime stories. For example: do not give the detective a love interest as it detracts from the main story line, the mystery.

Interfaces, I feel, do not have such clear definitions or rules. I use the IA organisational schemes, taxonomy versus folksonomy, as metaphors to describe the difference:

• A producer or publisher identifies an item as it is released into a genre much like an information architect creates a taxonomy.

• Interfaces are created and released without explicit association with a type. The creators of interfaces vote for types by choosing to create them.

Genres are created in a top down method while interfaces, unconsciously, are created with a bottom up approach.

If the objective is to identify a model to aid the creative and productive process then we do have such things, but they are not genres. Without the years of development that it has taken for genres to form we need to learn about the context of use. The tools that I use in order to do this are: research, iterative design, design patterns and personas and scenarios.

Much like genres, design patterns aim to create a classification scheme via which we can aid the creative process. They do not talk about rules but outline the context, form and solution of the problem allowing the designers to resolve the problem. I talk about my understanding of UI Design Patterns in the ‘Are design patterns a truly useful design tool when designing interfaces?’ post.

Mario, Nicola and I had a discussion where they suggested that patterns were genres by another name. Could it be that in order to identify a genre the patterns for that genre need to be clear (fast pace, frequent action, suspense, cliffhangers)? Interfaces do not yet have genres, as we have not yet identified complete pattern languages for them. Each practitioner is consciously or unconsciously identifying patterns as they work. In time perhaps we will have UI genres when we amalgamate and rationalise our patterns, but we are currently too young for that as we are only just discovering the patterns.

Simon Johnson and Martina Schell, two of Flow's user experience consultants, recently ran a presentation and discussion about personas for the Usability Professionals Association. A really interesting question came up, which we think is worth discussing more, here on the blog:

How can I be sure that my entire user base is represented by just a few personas, when I have 5 million users scattered around the world?

Quick personas refresher

Personas are a key tool in the user-centred design toolkit. They help design teams to reach consensus about who they are really creating a product for, and to generate and sanity-check new feature ideas. Personas are fictional characters, defined in some detail: names, faces, habits, personalities. The idea is to generate as few of them as possible - ideally just one or two.

To find out more about personas, try:

• Cooper design, persona pioneers
• Wikipedia page
• Book: The Persona Lifecycle

2 personas vs 5 million users

So - user-centred design teams boil down their knowledge of their user base to a few personas. But can you really represent the need of 5 million diverse customers this way?

Answer 1: It's the best way we know

The point of personas is to reduce your user audience to a small and manageable set in order to provide a useful design tool to your designers. Designers are humans and can only handle a finite amount of information at a time (they unconsciously disregard the rest - see Christopher Alexander for more on this).

Sometimes, a customer's behaviour won't be represented in the persona set. Maybe she is the black sheep of your users. So be it. Personas are there to represent most of your users. They are based on research with a range of people from your target audience. They are a practical way of telling your team who they are designing for - because 5 million people is too many to consider at any one time. Missing out on designing for particular user behaviour is a risk, but it's a much smaller risk that designing without personas at all.

If you choose not to use personas, what are the alternatives? Designing for yourself (one, rather unrepresentative user), designing from a technology-led feature list, or designing from an overwhelming and impersonal collection of data. The odds for overall success are MUCH greater with personas than without.

Answer 2: Define the user base by its edges

You do not have to ensure that every real life user you ever encounter fits neatly into the persona set you create. Almost every one will not fit. But their behaviours will probably be represented throughout all of the set of personas - one behaviour in 'Ann', another in 'Paul' and another again in 'Stephanie'.

The trick for representing a large user base with a small persona set is to choose personas who represent the biggest challenges to the system. If you choose personas are to represent the users who are the hardest to satisfy, while capturing a reasonable subset of the average user's needs as well, you'll set yourself a meaningful design goal. Think of personas as a complex venn diagram of needs. If you focus on the average users, you only get the center of the diagram. But if you focus on the reasonable extremes, you get the outer rings of the diagram as well as the overlapping middle.

Answer 3: Don't try to design for everyone

Solutions designed for everyone are usually not particularly good for anyone. To design for everyone, you'll need to make a system that caters for opposite needs and expectations at every point in the interface - because your infinite user base want an infinite variety of options. At every point the product will rely on the user to completely decide and define what they want to do, and this will make it impossibly hard work to use - useless, in fact.

On a less philosophical level, products with a broad taregt audience can find it increasingly difficult to retain customers. Any competitor coming along with a tightly defined, easy-to use product will steal a proportion of your braod user base - because their offering will that proportion's needs far better than yours can. More competitors can cater for other niches - and soon your entire user base has been fragmented and enticed away to narrow products that better suit their individual needs.

Narrow your potential usebase, but make sure you really satisfy their needs. That's a recipe for a well differentiated product, and loyal customers.

Penguin Books and Dorling Kindersley have just completed a user-centred re-design of their websites. We're pleased and proud that they chose Flow to work with them on the projects.

Penguin and DK's teams told us that they wanted to do some significant rethinking about the purpose of the sites, and the needs of target users. We started with contextual research to build a genuine understanding of what target users need from publishers' websites, and to examine the user experience offered by the current Penguin and DK sites.

From there, Flow conducted workshops to help the teams work out a new user experience strategy, build personas and scenarios and create new site concepts. We consulted to the in-house design teams during the detailed wire framing process, conducted the usability testing, and provided information architecture support for the new facetted classification engine.

Anna Rafferty, Penguin's digital marketing director, has written a blog post about the process.

"Months of workshops, designing, testing and re-designing later and we're happy that we've shifted our site from being a company on broadcast to being genuinely reader-centric."

And Jeannette Angell, Penguin and DK's online development manager has just been interviewed about it by e-consultancy.

"If there's anyone reading who hasn't yet sat behind mirrored glass, watching your visitors try and fail to do what seems to you to be the most obvious task, I urge you to experience it. The lessons learned from this experience can be staggering!"

Congratulations to everyone on the Penguin and DK teams on embracing the user-centred approach, and delivering the sites after so much hard work. And thanks for working with Flow!