Social Design workshop at UX Week San Francisco

Last week, Christian and I had the pleasure of doing our Designing Social Interfaces day long workshop as part of Adaptive Path’s UXWeek. We had a great time and had a terrific group of people participating. Super engaged and collaborative, we had a lot of cool ideas created during the day. We also got a chance to play the game.

Here are slides:

And some pics from the day:

Designing Social Interfaces workshop participants at UXWeek San Francisco, August 27, 2010-3.jpg

Designing Social Interfaces workshop participants at UXWeek San Francisco, August 27, 2010-5.jpg

Designing Social Interfaces workshop participants at UXWeek San Francisco, August 27, 2010-14.jpg

Designing Social Interfaces workshop participants at UXWeek San Francisco, August 27, 2010-15.jpg

Designing Social Interfaces workshop participants at UXWeek San Francisco, August 27, 2010-21.jpg

Designing Social Interfaces workshop participants at UXWeek San Francisco, August 27, 2010-24.jpg

Designing Social Interfaces workshop participants at UXWeek San Francisco, August 27, 2010-22.jpg

Patterns Talk for An Event Apart

Last month I was one of the speakers at An Event Apart, Minneapolis. It was a fantastic experience and I highly recommend it. If it’s at all in your budget, get thee to An Event Apart. One of the best conferences I have ever been too. But then I am partial to very geeky things and appreciated the fact that this was geared towards designers and builders.

My talk was, surprisingly, not a Social Design talk, but rather a talk about Patterns – or more specifically Patterns, Components and Code, Oh My!

Here are my slides. The details of what I said are covered in my last post about the various libraries coming together as a holistic toolkit for the full team.

Working With a Pattern Library Day to Day

[Part 7 of a series on Patterns. Working with a Pattern Library.]

Patterns, Components, and Code, Oh My!

Ok, so now you have a pattern library. Now what? Ultimately, you need to be able to work with this content on a daily basis. The patterns, in and of themselves, give you the tools to understand the variety of interaction problems and various contexts of use. They also explore the considerations you need to address and resolve for your particular context. The patterns should give you all the rationale you need, with research and examples, to back up your decisions and know that you are starting with a usable solution.

By itself the pattern library informs, builds consensus, and captures shared knowledge BUT it’s hard to use in the real world when designing against a deadline. What a pattern does not do, is give you a working object that can be plugged into your sketches, wireframes, prototypes or final solutions. You need to be able to drop these solutions into your specific context for prototyping, for testing with users and for final builds.

With that in mind, you should consider the pattern library as just one part of a master toolkit. The pattern library should be the foundation for the entire toolkit which can be used by the entire team, including developers.

So what goes into the toolkit?

  • a robust pattern library
  • visual design guidelines and brand examples
  • wireframe stencils of pattern instances or components
  • foundational elements like grids
  • related code components that map to the stencils and patterns

Each pattern in the library can be considered a hub around which all these other elements revolve.

The working objects that revolve around the pattern are specific instances of the pattern. Just like the sensitizing example in your pattern, which is an instance of the pattern in the wild, the code, component or stencil, css and specs are specific implementations of the pattern that can be used in your designs and even final builds. Ultimately, having this toolkit aids in adoption by the entire design and development team as it helps reduce inefficiencies and promotes reuse where appropriate.

In my experience, pattern adoption works best when engineers have reference and example code and can build solutions out of components just as the designers build experiences out of the patterns and stencil components.

Pattern + Stencil + Code = Very strong building block

So what do I mean by Component?

A component is a reusable, design system-specific chunk of a page.

Also known as modules, chunks, portlets, widgets, blocks, or other labels depending on the design context – are put together – like building blocks to create an entire page.

Components might have a specific application within a page grid, like a header or footer, and usually have prescriptive specifications for behaviors, formats, editorial, visual style, design rules and variable treatments needed for implementation. In the case of components that take advantage of ajax, they should include an interesting moments grid and behavioral guidelines.

In a pattern library, the component should be a reference design that follows agreed upon interactions and brand standards. For agencies, the component should be a generic, best case instance that can be skinned for various client needs.

Comparing Patterns and Components

Nathan Curtis, the expert on designing with components, has developed this matrix which defines patterns and components against a variety of points. He uses this to make a nice comparison between the two, which helps differentiate between them.

Distinction Patterns Components
Types Could be a page chunk (log in module), flow (shopping from product to cart to checkout to receipt), behavior (e.g., autocomplete), or something else Always a chunk of page or screen design
Specificity Globally applicable across a range of contexts, even if elements are similar Specific to one design system, including layout, color, type, and behaviors
Location Up to the designer to appropriately apply principles and locate within a screen design Targeted to specific location(s) within a page layout, based on approved usage
Style Abstracted from any specific skin, and flexible to adapt to many visual treatments Finished within one visual system, although variations may be defined
Editorial Perhaps some basic editorial guidance Specific data, formats, guideline, style/tone, and even defined feed
Markup & Code While starter code may be available, it needs to be tailored to fit the system Ideally represented by formalized html, javascript, and CSS if the library is built
How It Works Represents how a design should work, under preferred conditions (but may suggest how to cope with tradeoffs) Represents how a design does work, inclusive of the tradeoffs and constraints established during the design process

I don’t agree with his definition that a component has to be targeted to a specific location in the page. This may make sense as you are defining your grid system, i.e. Social tools widget always goes in the middle right column, etc. especially for a content CMS driven site. But the decision of placement as part of the definition of a component needs to be part of the design process and is related to the defining of your grid and module system and may not be appropriate at all for a web application or mobile experience.

In general, components may have location as part of their definition, but that location is dependent on the context of a SPECIFIC design system and not consistent to all design systems. You can develop components to use across projects, across clients or across different design systems for the greatest flexibility.

For designers, components might take the form of stencils that can be loaded as libraries for applications like Omnigraffle, InDesign, Axure, Fireworks etc. The Yahoo! pattern library team and others in the UX community, like Loren Baxter and Michael Angeles have released stencils that map to the patterns for many of these applications. Systems like EightShapes Unify bring a component based library set to InDesign.

All these solutions are used to aid in the design process and promote reuse while reducing the process of reinventing the wheel every time the designer sits down to work. Many designers I know have created their own personal, reusable set of stencils and design elements. The Toolkit formalizes this for use by an entire team. This is not unlike reusable code-libraries in use by development teams. It also means that designers can more easily share work and trade files with each other.

Code, code, code

Libraries like the YUI, jQuery, Silverlight and others are similar in concept to an interaction design pattern library. This is the part of The Toolkit that is most relevant to developers.

As seen by the rise of reusable AJAX libraries, code libraries are useful tools for developers to deal with standard and common interactions. Having a code snippet that maps to each pattern and component wherever possible means that teams can easily flesh out common interactions and rapidly prototype solutions.

Having a code library also means that your development team can focus on the more complex, unique interactions and features. They can spend time working on performance issues, database issues, crafting new code snippets to new patterns and other unique, one-off problems that often get short shrift because of the everyday, common features.

A few of the more common component libraries and frameworks include: Flex, Laszlo, Silverlight and 12 Ajax frameworks and toolkits: ExtJS, Dojo, YUI, Google Web Toolkit, Prototype/, JQuery, MooTools, MochaUI, SproutCore, LivePipeUI,IT Mill, Backbase. (list compiled by Theresa Neil and Bill Scott)

Each of these has a set of components, of which many might map to a common pattern library set. The 30 components reviewed and covered by Bill Scott and Teresa Neil, span across all these different libraries.

The most usable toolkit for your company or team, might be a mix of off-the-shelf and custom components collected together with associated patterns, visual specs, css and stencils.

Interesting Moments Grids

The interesting moments grid was developed and promoted by Bill Scott while he was at Yahoo! It’s a great tool to develop collaboratively with your development team. He describes it as a storyboard or document that should accompany an interaction design specification which explains what happens to each element at key moments of use.

Defining each of these moments means that nothing is left to chance and every moment and behavior has been designed for the best outcome for users and for the best performance for the web application.

The Interesting Moments grid may be bound to code-based events or user initiated actions. Whatever the event of action, they all need to be discussed and defined. [drag and drop story board template | inline editing storyboard template ]

These documents are a great opportunity for interaction design and development to collaborate together. Both at prototype time and development time, the exploration of these actions and timings are as much about the user experience as an understanding of what’s happening with the code in terms of load time and what can be supported efficiently.

Figuring out Where to Start

For any organization, the success or failure of the pattern library and associated toolkit is going to be in how to approach the collection and codification of these tools in the most efficient, usable way possible.

For some teams, that means doing the research and writing work needed to create a pattern library from scratch. For others, it means pulling patterns out of existing specification documents. For another, it might mean developing a code library and then mapping the patterns back to it with rationale to support long term use of these solutions.

You can back out of a component library into patterns as long as you remember which level each belongs on. Patterns don’t dictate look, location or placement. They have a generic feel to them and that gives them an evergreen quality. The problem, solution, when to use and rationale for the decisions made in the solution should be valid regardless of media or technology. Your component on the other hand will dictate a lot of specific design, like placement of elements, timing of animations and ajax motions, specific labeling and even finished look and feel.

Small teams should spend their time collecting patterns and components from the large number of libraries available open source and spend their time documenting the deltas between them and their specific needs. This will cut down on a lot of work reinventing the wheel and will force the team to make decisions about what is specific and important to their organization.

Regardless of how you start, remember that the most thorough and usable toolkit, will have pieces that can be used by designers and developers day to day, backed up by the deeper foundational work of the patterns themselves.

Next up: How Visual Design Works in the Toolkit

Organizing your pattern libary

[Part 6 of a series on Patterns. Organizing the pattern library for a design team.]

Organizing a pattern library is like organizing any other large body of content. You need to look at the content you have as well as the content to be developed and come up with a primary and a potentially a secondary mode of organization. When we developed the Yahoo! library we did some work in fleshing out a taxonomy and structure beforehand to help guide us in writing the initial patterns content. We did several batches of card sorting exercises after interviews with design staff to refine the corpus of potential pattern topics.

The structure you initially develop doesn’t necessarily need to be published, especially if it will be a while before it is all fleshed out. You might consider one way to organize at the beginning with another mode taking over as the content becomes more robust.

We found at Yahoo!, that alphabetical didn’t cut it because it stripped away the context of use. We later clustered the patterns based on topical groupings; social patterns, rich internet applications etc. This helps but it didn’t solve the cross context organizational issues.

Many patterns can fall into a variety of topics. Is Registration a form? Is Registration the start of an engagement process in social applications? Consider having both categories and tags so that patterns can be found across multiple facets. Finding methods might be a taxonomy browse, a search with faceted narrowing or clusters of links based on topics.

Organize based on a greater process.

Another option for organizing your patterns is to develop a framework in which they live based on user processes. For example, an onboarding process for new users might include a homepage or landing page pattern, a registration pattern, a welcome pattern, a new user engagement email pattern and then patterns for first time experience, 2nd visit and so on. This suite of patterns would be robust and would contain a lot of parts but ultimately would inform a whole cohesive process.

Robert Hoekman talks about designing in this way and calls them Frameworks. This is a good way to think about things in terms of their larger context and allows patterns to live in multiple contexts. It also maps to the user’s mental model of the larger problem they are trying to solve—here your user is the design team working with the pattern library.

Or they organize by action.

13 screen patterns from Bill Scott and Theresa Neil’s new book, Designing Rich Internet Applications. They use the screen patterns and 30 control patterns to create 100’s of options in the library.

Or Take the Alexandrian Approach

Approach the library as a language. Define the broadest concepts first. Sometimes these may called principles or best practices and are overarching concepts that can be applied to most topics across a variety of patterns or contexts.

Break it down to smaller components and mix and match as necessary.

Consider the human experience both in the organization of the library and in the patterns themselves. Ultimately it is about who will be using the library.

Whatever the philosophy, the pattern library needs to be organized in a way that all the designers using it can find what they need in an efficient manner.

Next up: Working With a Pattern Library Day to Day

Reviewing Patterns for Use

[Part 5 of a series on Patterns. Developing a quality system.]

Once you have a collection of patterns they should be reviewed by the team or designated representatives.

A review process is good for catching missing issues or considerations as well as refining the problem statement and context of use.

Additionally, the review process helps socialize the pattern across a team and helps get everyone on the same page.

The review is a chance to bring everyone into consensus around the solution.

At Yahoo! we evolved this process several times over the years. The first attempt (documented in the article at Boxes and Arrows) ended up being too heavy and time consuming for the organization. Without a strong directive from management, it was too cumbersome to wrangle people from across the company to meet on a regular basis about something that was only tangentially required. Over time, we evolved to a loose group of senior and principle level designers, who had influence over their orgs and cared about this stuff, and conducted the review process through email notifications with a deadline. After the deadline passed the pattern librarian had the right to move forward with the feedback even if some people didn’t respond. We took a “no comment” as “ok to proceed” directive that everyone had agreed to. In this case, the patterns that were most applicable to a specific designer’s work or interests were the ones they became more heavily involved with and in the other cases they were ok to defer to other experts.

One person should be designated the pattern librarian. This role can rotate among team members to spread the work around. They will edit draft patterns – regardless of who writes them and will decide when a pattern is “done” enough for review.

The pattern librarian role is responsible for pushing the patterns out for review. There should be a designated time frame for reviewers to read the pattern and give feedback. The librarian will then synthesize and integrate the feedback and edit the pattern to reflect that. If the feedback is highly polarized or controversial, the librarian will send the pattern back to the author to gather more rationale to refute the feedback or to reconcile it with the solution.

The process of reviewing patterns can be done by individuals or in group discussions.

As previously mentioned, pattern blitzes can be an opportunity for a group of designers to come together and review patterns together. The pattern can be read aloud and the solution debated, challenged and/or recrafted. The original design author can share relevant research as the pattern is discussed.

The ultimate outcome of the pattern review process is twofold.

One – the group has consensus on the pattern as a working solution to a defined problem in context.

Two -the group agrees on a level of adherence desired going forward by all designers working with the organization.

The review process guarantees that the pattern is really a pattern, is the most archetypal solution to the problem as AGREED upon by the organization and isn’t a duplicate or a detailed specification.

Next up: Organizing a Pattern Library

Go With the Flow

I gave a new talk today at Web Visions 2010. Called Go With the Flow, this talk covers ideas, techniques and optimization recommendations for customer acquisition, onboarding, engagement and virality in growing social sites. The second half of the talk covers ideas for bridging the gap to real life – using social tools to create real life gatherings and then collecting the artifacts of these real life actions to bring people back into the online experience.

I think the talk went well but I felt like there was not a good segue from the first section to the second section. I think, for future incarnations, I will probably turn this into two talks and flesh each section out with specific patterns interspersed with the real world examples and ideas.

The Future is Already Here: Three Trends in IA

Below is my opening keynote slides and the talk I wrote out which I gave at the German IA Conference in Cologne, Germany May 14, 2010. I speak about experience design, social design and service design. The theme of the conference is Service. Design. Thinking. What I actually said may have been slightly different than the text here but the intent was the same.

Hi I am Erin Malone. Thanks so much for inviting me to speak to you all today.
I want to talk about some of the trends in the IA practice I have been seeing and how I believe they are leading us to a time of convergence.
[slides about me]


We are all experience designers

Regardless of our titles, regardless of the arguments.

Last year at the IA Summit in Memphis, Jesse James Garrett gave the closing plenary. He rocked the house by making a bold statement that we are all Experience Designers and that the title of Information Architect needed to be left behind.

He claimed that there are no Information Architects, there are only User Experience Designers.

I am not sure I agree with him, but he was right about one thing. Today’s IA, needs to be aware of and even engaged in the overarching user experience design of the projects he is working on, REGARDLESS OF HIS TITLE.

I am not going to get into a debate here about titles or tell you that your title is wrong. Frankly I don’t care about that. I care about what we do.

“Designing with human experience as an explicit outcome and human engagement as an explicit goal is different from the kinds of design that have gone before. It can be practiced in any medium, and across media.” Jesse James Garrett, IA Summit Closing Plenary 2009

Others have a similar definition – User-experience design—a sort of architecture for information that Web viewers see—is another emerging field. Jobs there include experience specialists and product designers at firms ranging from computer-game companies to e-commerce Web sites.
Diana Middleton, Wall Street Journal 12/28/2009

IA doesn’t live in a vacuum. It exists in the context of a content strategy. In the context of a brand. In the context of interactions and coded interfaces. The more successful and adaptive IA already understands this and has evolved his practice to embrace an understanding of the holistic user experience.

To stay viable and relevant and engaged, we don’t abandon what we know and practice, we expand what we understand.

We add to our toolsets.

Tim Brown, of IDEO, said in a Fast Company article, “T-shaped people have two kinds of characteristics, hence the use of the letter “T” to describe them. The vertical stroke of the “T” is a depth of skill that allows them to contribute to the creative process. That can be from any number of different fields: an industrial designer, an architect, a social scientist, a business specialist or a mechanical engineer. The horizontal stroke of the “T” is the disposition for collaboration across disciplines. It is composed of two things.
First, empathy. It’s important because it allows people to imagine the problem from another perspective- to stand in somebody else’s shoes. Second, they tend to get very enthusiastic about other people’s disciplines, to the point that they may actually start to practice them. Tshaped people have both depth and breadth in their skills. ”

We need to be understand and speak the language of business. We have to understand the language of content and brand and understand enough of the paradigm of software to engage with developers in meaningful ways.

And ever increasingly, we must think about physical spaces and about person to person – social – interactions whether mediated by a computer or mobile device or in real time. Information is woven into and throughout these experiences.

We must do all these things all while understanding and championing the people who will use these spaces.

As architects of information, we are now, more often than not, designing information frameworks. We are designing the spaces and experiences that house the data and information we shape and THAT is designing at a meta level. Being engaged at the meta “Experience Design” level gives us the mindset to be successful as we become more immersed in designing social and service experiences.


Everything is social.

Thinking about frameworks and designing for a Meta context puts us in the right frame of mind and space to be designing social into our work. It’s everywhere and everyone wants it. It is inescapable.

You may already be designing social and not even know it.

So what does that mean?

Just what is social? We hear the terms social network, the social graph, social media and social object.

The social web means that the awkwardness of human interactions and relationships are now happening online. People are unpredictable and will stretch and push the boundaries of what they can do within the digital frameworks.

So how can you be successful integrating social into your work.

Social is organic. It’s emotional. It’s about relationships. It exists along a continuum and over time.

The information architecture needs are different than what has come before. Now more than ever we are designing for things to come. For user generated content that doesn’t exist when you are creating your solutions. For relationships between people that aren’t manifested until after your work is complete.

It’s important to understand the principles behind good citizenship in social environments. You need to be aware of the tradeoffs required for shipping social interfaces fast. It means thinking about things like privacy, norms, citizenship, and designing the spaces for interaction to be created. It means giving up control within a controlled environment.

There are a handful of principles we talk about in the book (DSI). In many ways these are not specifically about social, but they have greater importance in the social environments.

5 Principles

Pave the Cowpaths
When designing social spaces or the social framework, remember that you shouldn’t or needn’t design out every feature. Create enough structure for the community to then create their own experiences. Over time, you will find that your users will create their own features, their own shortcuts.
Dogster is an example, when the company saw that people were sharing pictures and talking about their dogs, they changed the interface to accomodate the activities people were already doing.

An example of this in real life is the RT feature in twitter. Users created a meaning for RT and process for what that meant. The company later added a formal feature to support this. The implementation isn’t necessarily what everyone wanted but it addressed one definition of how people were Retweeting.

Talk Like a Person
This advice is to talk like a real person. Not like a computer. Not like a marketing person. Not like a giant corporate hairball. It’s about being authentic. About being real, while true to your brand. It’s about taking the blame for errors.
It also means keeping jokes to a minimum – they don’t translate across cultures or often across demographics so its safer to stay away from them.

Be Open
Being open doesn’t have to mean giving everything away. It can mean being open to the idea of letting people bring their data in with them. It can be as open as letting people take their data away or some combinations of the two.
It’s worth exploring options where you don’t have to design everything from scratch.

Learn From Games
Amy Jo Kim, who wrote the book Community Building on the Web in 2000, is now working on social games and has collected and presents a list of game mechanics. These are very powerful in game situations and are as powerful in social situations.

Game mechanics:

Collecting give people bragging rights and encourages them to complete tasks or activities in order to get every item that can be collected.

Feedback, from the system or another person, lets that person know they are not alone.

Points drive competitive behavior and for some people the desire to win or always be first. Points are tricky, in that they often drive quantity rather than quality. Teamed up with other features though and they can be strong driver for engagement.

Exchanges, like gifts, and other items from person to person often gives a sense of value to the relationships between people and are a passive way to strengthen bonds.

Customization, allows people to make their experiences personal and once someone feels like they own it, they are more likely to be a return user.

Respect the Ethical Dimension
There are often a lot of ethical questions and issues to address when designing social spaces. These can be as simple as developing a licensing system for the user generated content and as complex as who owns what data that is emergent by behavior and activity.

There are tradeoff that need to be made and they can’t be ignored when thinking about the whole ecosystem of a social environment. It is important to think through and make decisions before building a community, than after something has happened.


5 Practices

Give people a way to be identified and to identify themselves.
Identifiable information – names, avatars, contributions, all build a person’s reputation on line and help others differentiate between people with the same or similar names.

Giving people a way to identify themselves lets them check in on how they are perceived by others. It’s just like checking the mirror before heading for night out on the town. You want to make sure you look good.

Make sure there is a “there” there.

People should be able to have an affinity – through interest, passion, background etc. to the offerings of your social service. The social object – the thing which draws people together and around which they interact, communicate, build relationships etc. – should be clearly articulated. It’s not about building social for social’s sake, but to create a “there” there.

Give people something to do.

Because people are different, and their engagement is going to happen along a continuum, based on their interests and passions, there needs to be options for varying levels of social engagement. In other words, it’s ok if some people are just watching.

Enable a bridge to real life.

Provide tools for people to find each other, plan and organize, meet in real life and bring the stories and pictures and follow up conversations back on line again.

Let the community elevate people and content they value.
When there are too many people in a community, especially one that is vocal and active, people will get lost. There is too much noise and not enough good content gets to the right people. Once a community crosses over that critical mass sweet spot, you need to either add tools to allow users to help surface the good stuff, find their friends and create their own sub-groups or you need to calve off areas into sub-sections or sub-groups that may be more formal.

Create the spaces for people to make things happen.

These ideas and ways to respond are part of the challenge of designing social experiences. The framework needs to be flexible enough to adapt and evolve as the needs of the community change and evolve.


Service design is the new old frontier.

In my opinion, Service design is the culmination of Experience Design and Social Design. It is the merging of information with brand with real life and real time human interactions. It’s how people interact with an entire system over time.

The difference between products and services is more than semantic. Products are tangible objects that exist in both time and space; services consist solely of acts or process(es), and exist in time only. The basic distinction between “things” and “processes” is the starting point for a focused investigation of services. Services are rendered; products are possessed. Services cannot be possessed; they can only be experienced, created or participated in. Though they are different, services and products are intimately and symbiotically linked.
1982 article by G. Lynn Shostack entitled How to Design a Service:

Services are choreographed interactions. Service=performance. There is a performative aspect to designing the holistic service experience.

Does this diagram look familiar? We have the tools already in hand to lead the way in evolving and improving the services of our everyday lives. We do ethnography and watch people to understand behavior. We tell stories and develop scenarios to understand and model how people move through an experience over time. We prototype to experience what we design in real life. The new aspect lies in expanding our horizons beyond the computer and towards understanding and designing the holistic system.

We have no control over how are users access our offerings. They come to us from all angles… from our website, some else’s website, from the phone, a kiosk, from a bricks-and-mortar lcoation, through a help desk or someone else’s site like Get Satisfaction, and through social media channels. People will go wherever they can to get the information they need or to complete a transaction. From their point of view, they’re just interacting with our brand, our company. And they don’t care about what channel they’re using.

Brenda Laurel, an early experience design practitioner, who studied theater as well as computers, uses improv and acting to show designers and engineers how to think about the people that use their products and services. She shows them how to use enactment and acting to inform design.

There are at least two reasons, Laurel writes, for considering theatre as a possible foundation for thinking about and designing experiences:

“First, there is significant overlap in the fundamental objective of the two domains — that is, representing actions with multiple agents. Second, theatre suggests a basis for a model of human-computer activity that is familiar, comprehensible, and evocative.”

While the actor uses empathy to perform dramatic characters in scripted situations, the designer uses empathy to perform design solutions that are drawn from deep identification with real, individual people in specific situated contexts in the real world. Brenda Laurel, Design Improvisation essay in Design Research Methods and Perspectives, 2003

Techniques like body storming, scenarios and storytelling are tools we already have to act out these new experiences.

People want more information and have higher expectations. People want better information tailored to them.

“Starbucks has always been designed to provide customers with a third place; a place between home and work where they can relax or meet with friends.”
– a company spokesperson

“… the essence of Starbucks is not about the coffee, although it’s great coffee. It’s about the coffee-drinking and the coffeehouse experience,” says Hayes Roth, vice president of marketing at Landor Associates, a consultancy that has advised Starbucks on branding strategy.

From Judy Stokes, Sutter Health, My Life Stages staff member
“Inside the café, I had witnessed numerous others conducting their business on the tiny Starbucks tables or settled into the couches.
Others were there with friends, children, spouses. Friends greeted friends when they arrived – clearly a place where, for locals at least, “everybody knows your name.”

Later that day, I spoke with my 19-year-old son about the experience. He pointed out that HIS friends also use Starbucks as THEIR meeting place. The barista knows Ian’s name and his favorite drink. His cycling friends meet there to plan their next ride. He uses their WiFi connection to conduct his important business.

While I have formerly dissed Starbucks as a conglomerate that tends to push out the local coffee shops – I am softening my view. Starbucks has built something that we, as Americans, are responding to! And it’s larger than the cup of expensive coffee. It’s a cultural phenomenon – the creation of neighborhood gathering places that are becoming part of our lives.

Is that true for you, too?”

Apple raises the bar with the choreographed experience at the genius bar. The staff have a specific role and process. There is a rapid transactional, purchase process and all of this is designed to accompany the environmental design and the product design of the items they sell.

“As service designers we are engaged in meta-design—designing design—and are producing resources for people to creatively engage with a service.” Dubberly Design, Designing for Service

This idea of designing design, reinforces my statements about our need to be designing at the framework and systems level.

A great example of a simple design change in the overall service experience of security can be seen when comparing the security check point and processes at the International Terminal in Stockholm, Sweden versus the security checkpoint system at San Francisco International.

In San Francisco, the trays are on a rolling cart at the end of a straight table. People get backed up grabbing and unstacking the trays, They have to slide the trays and their belongings (often numbering up 5 or 6 items and trays per person with shoes and coats and laptops and bags) across a flat metal table. Once they go through the scanner, they retrieve their belongings and the empty trays are placed on a rolling cart by the TSA people. Only when there is a shortage of trays at the other side are they rolled back or sometimes carried back by hand, to the front, requiring both someone to pay attention to the inventory and for someone to restock the trays.

In Stockholm, the “table” is an oval rotating conveyer belt. The trays for shoes and items are stored beneath the rotating conveyer belt, so that as items are scanned and retrieved, the trays wind their way back to the people in line needing trays. No extra people needed to move the trays.

The simple difference at the Stockholm airport means less time in line for passengers and more focused security staff who could pay attention to security and not tray inventory.

This different system was designed by someone and the impact it makes on the stress level of customers is immeasurable. By contrast, most customers at SFO are stressed out and frustrated before they even get to their gate.

I share this story because it is an example of a small design change that can have a big impact. It takes people like us, with skills at observation and imagining a different outcome, to design these changes.

As certain experiences (entertainment, restaurants, shopping) get better through design, people come to expect it in all facets of their lives. With everything moving into the digital realm and information informing personal interactions for things like healthcare, fitness, sales, shopping, travel and a myriad of other contexts, the need for thoughtful, cross channel, choreographed experiences by the people in this room becomes more important than ever.

“In order to feel connected, important, and understood, people need meaningful experiences.”
Pierre Bourdieu, Sociologist

Ultimately, it’s about convergence and making meaning within contexts. Understanding our role, our expertise and how all the disciplines work together will only enhance our ability to change behavior with the tools at hand and will make us successful in designing these spaces, whether digital, social or as part of a larger ecosystem of services.

Thank you.


  • Jesse James Garrett, Closing Plenary, IA Summit 2009
  • Diana Middleton, Wall Street Journal 12/28/2009
  • William Gibson, in an NPR interview (30 November 1999 Timecode 11:55
  • Web project roles diagram, via via, updated by Erin Malone
  • A Timeless Way of Building, Christopher Alexander
  • Designing Social Interfaces, Christian Crumlish and Erin Malone, 2009, O’Reilly Media
  • Power law of participation diagram, Ross Mayfield, founder SocialText, 2006
  • Design As Theater, Brenda Laurel
  • Design Research Methods and Perspectives, 2003, Brenda Laurel
  • How to Design a Service by G. Lynn Shostack, 1982
  • Strategy by Design, Tim Brown, IDEO, Fast Company, June 1, 2005
  • Designing for Service: Creating an Experience Advantage, Hugh Dubberly and Shelley Evenson, February 1, 2010,
  • Service Design Iterative Process by Shelley Evenson, Dubberly Design
  • Ubiquitous Service Design, Peter Morville, Semantic Studios Blog, April 19, 2010,

The news is out – Yahoo! Pattern Library finding a new home

The Yahoo! Pattern Library, that I founded, thanks to the insight of Irene Au (now at Google) will be moving homes from the Yahoo! Developer Network to (and a redirect from – which already has some of the content there from an experiment I did last year) sometime in the next couple of months. Bill Scott, myself and Christian Crumlish are going to be curators / shepherds to the library, making sure it has a life beyond Yahoo! and will be looking for others to collaborate with.

What was needed while I was at Yahoo!, has matured and been embraced into the culture and now is no longer owned by one person or one group.

With that, we are working with the folks at Yahoo! both in the Developer Network and in the UX team to move the content to the new host. Before going live, we will be rebranding it and coming up with ways to annex and open our space to host, point to and embrace other libraries. I consider our own Social Patterns suite one of the libraries that we will try to figure out how to integrate – even if only at a pointer level – but hopefully in a better way than just a pointer (especially since some of the patterns were already folded into the Y! Patterns).

We are not sure what all the work will be and how it’s all going to play out, but after 6 years of caring and feeding, through myself and 3 curators (Matt Leacock, Bill Scott and Christian Crumlish) it is nice to see that it won’t just be killed. I believe it adds value to the community and believe that others have ideas to contribute to its continuation in whatever form it takes.

If you are interested in participating let one of us know. We will probably add a wiki or a forum to the site for conversations and ideas.

Off to Germany – 05/13 – 05/15

Heading out to Germany for the German IA Konfernz in K̦ln. I will be leading a workshop on Designing Social Interfaces Рbased on material from the book Рon Thursday and will be the Keynote speaker on Friday morning. I am really looking forward to this.

I am attempting to go early to spend a few days in Berlin sightseeing. So far though, circumstances have gone against me and I am still here in SF – flight will try to get out of here today.

Hope to see you there.

Web 2.0 SF – O’Reilly Book Authors Meet and Greet 05/05/10

Yesterday I led a 3 hour workshop on Designing Social In – Using Patterns, Practices and Anti-Patterns to Create Meaningful Social Experiences – at Web 2.0 in San Francisco. Slides posted here.

Christian played assistant this time since he was prepping for a big talk today.

I think it went well (although you have to ask the participants) and we had a lot of great conversations and group engagement in the activities. The format of the room left a lot to be desired but we pressed on anyway.

We will be at the O’Reilly booth tomorrow for the booth crawl and the author’s Meet and Greet. If you want to ask questions about the book or have your book signed, come on down at 4:30.

See you there.

How to write an interaction design pattern

[Part 4 of a series on Patterns. How to write patterns once you have identified them.]

Writing interaction design patterns can seem easy on the surface. After all, aren’t you just documenting an interaction snippet or module or component?

Sort of.

It looks easy on the surface, but the actual process of writing the pattern can be difficult because it forces you, the author, to ask a lot of serious questions about the nature of the interaction solution and whether or not that solution is the best or the most archetypal solution to the design problem at hand.

The interaction design pattern template can be broken down into five basic key components:

WHAT: What does the user want? This is an explanation of the design problem from the perspective of the user and their motivation or task needs.

EXAMPLE: An archetypal example of the solution. They say a picture is worth 1000 words. A picture or, if used on the web, an animated gif or quicktime movie, can quickly help the person using the pattern know that this is the right one.

USE WHEN: When to use this solution. This describes when this particular solution, as described by this pattern is appropriate. This is the context, and is one of the most important sections of the design pattern to define.

HOW: How to meet the user’s needs. This section is the bulk of the interaction design pattern and is the solution. This section may also contain considerations for Accessibility, Internationalization, Mobile constraints and other related topics that affect the decisions for how the problem is solved.

WHY: Why is this a good solution? And why this problem should be solved in this way.

Other topics that may be of interest in fleshing out a design pattern include: Related research, Sites or Applications where this solution has been successful, links to code examples, links to visual design rules, links to related components, full specifications, co-requisites, sibling patterns, related patterns, a history of how this solution has evolved (whether in your organization, in software or on the web in general), links to a discussion area around this pattern, a library of examples, and other literature or resources related to the topic.

Defining Your Pattern Template

There are several pattern collections available on the web and in pattern collections in books and each has it’s own variation on the template.


Most of the differences in the various libraries is in terminology and how much or little to include in the pattern.

Remember though, that the interaction pattern is not intended to be the last word on the topic. We all know that over time, solutions will be nuanced, user research may expose something new or unseen and users’ growing sophistication with interfaces will dictate changes in the solution.

So just how do you get started?

First draft a list of the types of user problems you are interested in documenting. These can be things like a carousel, a calendar system, large amounts of data, sign in, search, registration etc. You probably have a list in your head of the things that tend to come up again and again. Even if they don’t have a formal name, capture the idea.

Then do some research. Research to get started on the pattern can come in several forms. This can be formal research findings from ethnographic studies or usability studies. Look through any and all research reports, usability and market, that may have looked at interactions similar to the topic you are pulling together.

Additionally, if this is a known user problem in software or the web, do competitive audits. A lot of designers do this anyway when they start a project. Take screenshots and notes documenting how other people have solved this problem.

Are you starting to see common interaction solutions?

Another place to pull ideas from is the product specs. How have the development or product teams or other designers defined the problem and solution?

From these materials, start to make a bulleted list. A “to-do” list if you will for the solution.

As the “to-do” list is forming, note the items that are an absolute must have for this solution to be successful and which are optional or nice-to-have.

Once you have this mental model of the must haves for success, compare the list to any solutions you may have already as well as ones you have seen in the wild while you were doing your audit.

Take a screenshot.

If nothing seems right, draw a wireframe.

This will become your example.

Referring to the list again, try to articulate the user need that is being solved. This will become your What statement.

Some example statements are:

For a Registration pattern
A user wants to access parts of a site or application that requires creating or saving personal information. A user wants to contribute content to the site’s community and have it attributed and saved for later.

For a Sign In pattern
User wants to access their personalized information or an application that is stored on the host site.

For a Breadcrumbs pattern
The user needs to be able to navigate up (towards the root page) and have an understanding of where she is in relation to the rest of the site.

For a Tag an Object pattern
A user wants to attach their own keyword or set of keywords to an object for organization and later retrieval.

For a Drag and Drop Modules pattern
The user needs needs to re-arrange the layout of modules on a web page directly with the mouse.

Get the idea?

These statements are usually quite short and succinct. They generally describe one need a person may have as part of their overall experience with a piece of software. After writing these in various ways, the team at Yahoo! evolved to the perspective of “user needs” in order to better define what it was that we were trying to solve with an interaction pattern.

Sometimes the what statement may reflect something the system needs to have happen or something the designer wants to happen for the user, but most often the perspective should be based on who is going to use the system.

Next think about the context. When is it appropriate to use this solution? How is this different than similar patterns?

Once you have all these parts, come up with a title that will be meaningful to your audience and will be findable within the larger collection.

That’s about it for the basics.

More details can be added later to flesh out the solutions, provide research based rationale and other optional sections. Don’t forget to cross reference related patterns.

Remember though, a pattern is not a spec. It is not the detailed specifications of how every part of the interface works, looks or is built. It is a high level description of the solution that can be applied in various contexts. The questions to consider that should be documented usually are about differing contexts and situations.

At some point you will want to make note of open questions and special cases. This may happen after user testing with projects containing the solution or when documenting other patterns.

Pattern Blitzes

Some people who have written patterns have found that it can be too time consuming or difficult to write them alone.

In 2009, the team at regularly held what they call pattern blitzes. This model brings the team together on a regular basis to work through a handful of patterns at a time. They collaboratively write and discuss the problems and solutions.

At the end of 2 hours, they have most of a few patterns documented. An additional benefit is that the team has consensus on the approach and the solution.

This approach can be done on a regular basis or at the beginning of the library project to kick start the process and quickly develop a handful of the most important patterns to document.

Practice Makes Perfect

Don’t be dissuaded from crafting a set of patterns for your team or company. While they can seem easy on the surface and are hard to write, with practice they become easier. The trick is the distillation of information down to the universal truths that lie within the solution.

After 4 and a half years at Yahoo! running the team responsible for patterns, it wasn’t until I was faced with writing some 60+ patterns for the Designing Social Interfaces book that I really became skilled at distilling the essence of the problem and solution. And even then sometimes it was a struggle. Like finding the end of the thread in a tangled knot of string. I encourage you to keep at it – it does get easier.

The power of a pattern is in its ability to be applied to similar situations regardless of the codebase or the branding requirements. And that means your attention can be placed on harder, less common and new design challenges.

Evolution of a diagram – the IA Summit poster

Our poster during the poster session
At the recent IA Summit 2010, we showed a poster rather than giving a talk. The poster, describes visually, the evolution of our social taxonomy and the influences from others on that and the eventual diagram we have been showing.

For folks who weren’t there, here is the diagram in all its glory. If you want to download it (2.3mb pdf) feel free – just credit us if you decide to use it, and credit the other authors if you decide to use any of the other elements.

From left to right, the top section show some concept models on Identity and Reputation made by Matt Leacock back when we were working on the social platform at Yahoo! The middle diagram is a concept cloud of all the ideas for social generated from a collaborative brainstorm at a barcamp that Christian led. Below that are two evolutions of a conceptual illustration by Bryce Glass showing the ecosystem as it revolves around the single person. We showed these last year in talks and at SXSW. The other items are sketches and lists that we made as we worked.

The right side of the poster is the social ecosystem I diagrammed a few months ago and we have been using this in our talks. You can download that diagram (pdf) by itself if you are interested. I wrote about the evolution a few months ago.

The bottom panel shows all the diagrams that influenced our organization and thinking over the last several years, from the honeycomb model by Gene Smith which came out of thinking by Stewart Butterfield (founder of Flickr) all the way to the fractal social model that Christina Wodtke uses in her social design workshops.

We wouldn’t be where we are in our thinking without all the other thinking to build on and I expect that our diagram will evolve as others come up with interesting new ways to think about these concepts.

How to identify interaction design patterns

[Part 3 of a series on Patterns. Understanding the concept of the reusable solution.]

Identifying patterns in architecture

The first thing you have to do before you can write an interaction design pattern is to understand how to identify patterns in the wild. When is something a pattern, when is it a principle or a best practice. What about guidelines or style guides or standards? Many of these terms are used interchangeably. Keep reminding yourself of the definition of a pattern.

A reusable, proven solution to a problem in a context.

Since we adapted the idea of patterns from a language in architecture. Let’s look at some examples from architecture before thinking about patterns in interaction design.

Here is a simple architectural item – the arch. According to the Oxford English Dictionary, the basic arch is a a curved structure spanning an opening or supporting the weight of a bridge, roof, or wall.

We see through the ages that this architectural solution is a reusable and repeatable solution in a variety of contexts.

For example:

top: Coliseum aka Flavian Amphitheater, Completed in 80AD

bottom: Pont Du Gard, old roman aqueduct near Nimes France. Built app. 19 BC

In ancient rome, the coliseum as well as the aqueducts, were constructed using a series of connected arches. These supported the walls, the floors above them and provided openings for people to come through.

The use of the coliseum was quite different than an aqueduct, their contexts different, yet the solution, the reusable pattern of the arch is the same.

left: Notre Dame Cathedral. Amiens, France (National Photo Company Collection (Library of Congress)
right: Reims Cathedral – Notre-Dame de Reims Photo © Claudio Giovanni Colombo / iStockPhoto

In pre-gothic europe, the great cathedrals being built utilized the arch in a unique way by combining two to four of them intersecting around a circle to create a vaulted interior of grand space.

Again, a very different use than the coliseum or aqueduct but using the same architectural pattern to solve a uniquely different problem.

In modern times, with the advent of building with steel, most buildings now only use the arch as a decorative rather than a structural element.

Nayabashi Bridge 納屋橋, 1913, Nagoya, Japan

An exception to this can be found in Nagoya Japan, with the Nayabashi Bridge. Originally built over a canal excavated in 1610 and then stone using the arch as a major supporting structure, it was rebuilt in 1913 with steel utilizing the same design, using the same architectural pattern of the arch to solve the problem of supporting the bridge across a span.

These examples show of a variety of contexts with different problems to solve. You can see how this repeatable and reusable item – the arch – is a pattern that can be used to solve each of these specific problems.

Identifying patterns in software and on the web

In interaction design, we can point to similar types of reusable and repeatable solutions that can then be labeled interaction patterns.

There are many times when a person has a large amount of data to deal with and they need to be able to easily navigate and act on it.

For example:
iTunes has containers in the left pane and the list of objects from the container in the right panel.

Susy has a lot of mp3s. She wants to be able to browse them and sort through them by different attributes (i.e. title, artist, year, album etc.). Additionally she wants to be able to group many of the songs together under different names like Good Driving Songs or New Year’s Eve Party Songs.

An interface that has a constant left pane for organizing groupings and a right pane that shows the contents within a grouping, with all being the default would address the user need described above.

A common mail application shows accounts and folders in the left pane and the contents of an account or folder in the right panel.

Joe receives a lot of mail. He wants to organize his mail by accounts and into groupings that are meaningful to him.

The same model of interaction as described above, a constant left pane for organizing and right pane for revealing the contents of a group would address this problem. A variant would add a third bottom pane showing the contents of an individual item from the list.

Google Reader, an RSS feed reader show feed sources on the left and the contents of the feed in the right panel.

The interaction pattern here is the left pane / right pane solution and it can be applied to various contexts equally successful. This is what makes it a pattern. The specifics change, the visual implementation may change, the code underneath may change but the inherent interaction model is the same.

Let’s look at another example.

A user wants to sign into a web site to gain access.

Sign in is a pretty common interaction across the internet. Most sites however only have one sign in form but the interactions are common when looking across the internet as a sample set.

At a minimum the user needs to provide some sort of unique identifier and a password. There is a method for submitting the sign in data whether it’s a unique button or just hitting return on the keyboard. This is the basic interaction that a user would go through.

This solution, a unique identifier field, a password field and a method to submit to the system, can be defined as the basic interaction pattern for sign in.

There are variants and optional items that can be added to this pattern but we will discuss that later when we talk about writing interaction patterns.

To recap, here is the definition of a pattern again:

an optimal (or proven) solution to a common problem within a specific context

Patterns are used like building block or bricks. They are fundamental components of a user experience and describe interaction processes. They can be combined with other patterns as well as other pieces of interface and content to create an interactive user experience. They are technology and visually agnostic and we do not prescribe either of these. Interaction design patterns give guidance to a designer for how to solve a specific problem in a context in a way that has been shown to work over and over again.

A pattern also captures the situation, competing constraints and provides a canonical solution.

It is repeatable and is an archetype.

Next: What’s all this I hear about Anti-Patterns?

Where did the idea of patterns come from?

[Part 2 of a series on Patterns. Parts of this post excerpted in part from my work in chapter 1 of Designing Social Interfaces: Principles, Practices and Patterns for the Social Web]

A brief history.

patternlanguageThe notion of using interaction design patterns in the user experience design process follows the model that computer software programming took when it adopted the concepts and philosophies of Christopher Alexander. Alexander, an architect, wrote the book, A Pattern Language (1977) and A Timeless Way of Building (1979). In his books he describes a language, a set of rules or patterns for design, for how to design and build cities, buildings and other human spaces. The approach is repeatable and works at various levels of scale.

Alexander says that, “each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

In addition to developing this language of elemental repeatable patterns, he was concerned with the human aspect of building. In a 2008 interview, he says that his ideas “make them (homes) work so that people would feel good.” This human approach and concern for the person (as user) is part of what has appealed to both software developers and user experience designers.

The idea of building with a pattern language was adopted by the computer software industry in 1987 when Ward Cunningham and Kent Beck began experimenting with the idea of applying patterns to programming. As Ward says, they “looked for a way to write programs that embraced the user, where users felt supported by computer program not interrogated by the computer program.”

designpatternsThis approach took off and in 1995 the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as Gang of Four) was published.

In 1997, Jenifer Tidwell published a collection of user interface patterns for the HCI community based on the premise that capturing the collective wisdom of experienced designers helps educate novice designers and gives the community as a whole a common vocabulary for discussion. designinginterfacesShe specifically called out that she was attempting to create an Alexandrian like language for interface designers and the HCI community. The evolution of that site and her work became the book Designing Interfaces, published in 2005 by O’Reilly Media.


The book, Design of Sites, by Douglas K. van Duyne, James A. Landay and Jason I. Hong and published in 2002, was one of the first to explicitly detail a collection of patterns for use by designers. Other, more specialized books, like Designing Web Interfaces, by Bill Scott and Theresa Neil, about rich internet applications, Designing Gestural Interfaces, by Dan Saffer, Designing Social Interfaces, by Erin Malone and Christian Crumlish and the latest book by Peter Morville and Jeffrey Callender, Search Patterns, exemplifies the spread of resuable design concepts into the design practice.

Several others published collections on the web including Martijn Van Welie, a long time proponent of patterns in the interaction design realm, which in turn inspired my team at Yahoo! to publish portions of our internal interaction pattern library to the public in 2006. The Designing Social Interfaces wiki has a whole list of online collections.

The notion of having a suite of reusable building blocks to inform and help designers develop their sites and applications has gained traction within the interaction design community as the demand for web and mobile interfaces has become more complex. When the web was mostly text, there wasn’t a whole lot of variety to how a user interacted with a site and the toolkit was small. The complexity of client applications was difficult at best to duplicate online. But that was then.

Now, whole businesses and industries rely on easy-to-use web based software to conduct their business. There is more need than ever to have a common language for designers and developers. And as the web is the OS and becomes integrated into every facet of interactive experiences, it is important to put a stake in the ground around just what those pieces should be and how they should and shouldn’t behave.

Next up: Identifying Patterns