5 Steps to Building Social Experiences

by:   |  Posted on

Nowadays everyone wants social in their sites and applications. It’s become a basic requirement in consumer web software and is slowly infiltrating the enterprise as well. So what’s a designer to do when confronted with the requirements to “add social”? Designing social interfaces is more than just slapping on Twitter-like or Facebook-like features onto your site. Not all features are created equal and sometimes a little bit can go a long way. It’s important to consider your audience, your product—what your users will be rallying around and why they would want to become engaged with it and each other, and that you can approach this in a systematic way, a little bit at a time.

These concepts derive from a book I wrote recently with Christian Crumlish, “Designing Social Interfaces“. They are quick and easy things to remember when infusing social into your site. Each points offers some simple suggestions and points to consider when designing. Potential design patterns are recommended (and linked to) as examples for what could be done in your interface as you design and grow your service. Keep in mind that your context will dictate different specific solutions but the questions and concepts to think about will still be applicable.

Step 1 – What’s your social object? Make sure there is a “there” there. Give users a reason to rally. Why would someone come to your site?

Most people are drawn to a site based on their particular interests, in hopes of learning more or meeting others like themselves. They may be looking for information or they may have information to share. They have a passion—such as making handcrafted jewelry or taking landscape photographs—and at some point, they will want to share that with other people. That passion, that thing that people rally around is often referred to as the social object. It’s the object around which conversations emerge and thrive.

Remember that sometimes, the social object is a person – or the conversations between people. But don’t forget history (remember Friendster? or SixDegrees?), if the only thing to do is build a profile, people will eventually go somewhere else to have conversations or to do things around objects of interest.

Step 2 – Give people a way to identify themselves and to be identified.

This can be as simple as an “attribution” line when contributing and signing content.

Attribution of a comment on flickr
Attribution of a comment on flickr

It could be an “identity card” that shows a little bit about the person and is attached to every thing they do or can be as robust and complex as a “full profile” that is linked from all their contributions. The method can start out simple and grow over time.

Identity or Contact card as seen on FriendFeed
Identity or Contact card as seen on FriendFeed

It’s important to give people credit for their words and contributions. It helps others recognize their friends and disambiguate them from other people with the same name and builds a “reputation of quality” or lack thereof for their participation on your service.

Public display of relationships allows viewers to find others they might know by allowing them to browse contacts for the person whose info they are viewing.

Public display of relationships allows viewers to find others they might know by allowing them to browse contacts for the person whose info they are viewing. Module shown from MyBlogLog
Relationship module shown from MyBlogLog

Once you have given people the ability to identify themselves, allow them to “find each other” and claim their tribe. “Relationships” make the world go round and online it’s no different.

Step 3 – Give people something to do.

Provide a path for participation so lurkers as well as early adopters can be engaged at the level of effort that is appropriate for them. Things like ratings (“1-5” or “thumbs up“) are easy ways to get low participation people involved by letting them quickly register their opinion with little effort.

Thumbs up and down ratings for restaurants on GoodRec let people quickly register their opinion with little effort
Thumbs up and down ratings for restaurants on GoodRec

Allow them to “share items” they find interesting with their friends or family and “curate and collect their favorites“. The latter requires a little bit more effort, but lets your users have ownership over what they find meaningful.

Flickr allows users to “favorite” images they like and collect them for display to others.
Flickr allows users to “favorite” images they like and collect them for display to others.

At the other end of the spectrum is full authorship of content with “reviews“, “comments“, “blog postings“, and “wiki entries” all the way through to participation as a moderator or guide in your service.

Wikimedia allows collaborative editing of content on sites built with the software.
Wikimedia allows collaborative editing of content on sites built with the software.

Start simple, with light features, and gradually add more complexity if it is really needed. Keep the structure flexible enough for your users to mold and adapt to their needs. In the book, we discuss several principles related to this including “Deliberately Leave Things Incomplete“, which reminds designers to allow features to emerge from the community behavior rather than forcing behavior to fit the UI and “Strict vs. Fluid Taxonomies” which merges a strict taxonomy like your site navigation with user generated groupings and organization with features like Groups, Message Boards, Tagging, etc.

Allowing behavior to guide your features and giving your users ownership of the structure make the site much more personal for them which in turn encourages repeat and longer term usage.

Step 4 – Enable a bridge to real life (groups, mobile, meetings, face-to-face).

Don’t be afraid to build in tools that allow your users to bring their community into the real world. In many online groups, a majority of people know each other personally.

Upcoming shows local events and allows people to add events to their calendar and view events their friends are interested in.
Upcoming shows local events and allows people to add events to their calendar and view events their friends are interested in.

Providing tools to help plan face-to-face meetings and then archive those happenings will strengthen your site and the community. Consider incorporating “geo” features like “GeoMapping“, and “GeoMashups“.

Additional features might entail creating “subspaces (groups)” and coordinating real time “face-to-face meetings” and gatherings among users of your service.
Meetup lets people affiliate with groups of interest and the site helps coordinate real life - in person meetings and gatherings between members.
Meetup lets people affiliate with groups of interest and the site helps coordinate real life – in person meetings and gatherings between members.

Step 5 – Gently Moderate. Let the community elevate people and content they value.

This can be through simple things like ratings or “reputation labels“.

Reputation labels on the intranet at Yahoo!.
Reputation labels on the intranet at Yahoo!

The community can help you surface contributions of quality which in turn should help attract future participants and will help keep the interactions lively. This process also helps push bad quality content down and out of sight.

Keep an eye on the community, participate yourself, welcome people as they join, set yourself up as a role model.

Hunch founder, Catarina Fake, acts as a role model for the community being built on the site.
Hunch founder, Catarina Fake, acts as a role model for the community being built on the site.

Notice who is passionate and who is potentially causing trouble. Conversations should run their course. Let the “community moderate itself” and provide tools to allow them to do that, like allowing them to mark content as spam or block trolls or “report abuse“. Step in only when necessary.

Report Abuse is available on every comment in Yahoo! Answers and allows users to moderate the content quality.
Report Abuse is available on every comment in Yahoo! Answers and allows users to moderate the content quality.

Make sure people are aware of the “terms of service” and “license” implications of content they create – both as it relates to your site as well as what they can permit others to do with their content.

Go out and get started

These are a few of the things to consider when building a social application or when adding social features to an existing site. There are a lot more features and concepts available within the social ecosystem but these should get you started and will build a good foundation from which more robust and complex features can be added to.

It is important to remember that you don’t have to do it all at once. You can apply features sparingly and let the community tell you when you need to expand. Consider the bare minimum while fleshing out your infrastructure. Add complexity as your community grows and scales. Remember that you are building a container for activity and conversation and that you don’t have to have everything figured out. The people will create their own paths of interaction making their own meaning and experience.

So You Think You Want to be a Manager

by:   |  Posted on
“Your decisions shape an organization, and they help design someone else’s career. The choices and combinations of people you put together for a project is as much design as the process of fleshing out type or color or an interaction widget choice.”

When I made the shift from designer to manager, I had no idea how to make the transition nor did I have anyone to guide me through the changes to my role. I didn’t know that to be a successful design manager I had to change more than my title; I had to change my mindset and look at design differently. I made a lot of mistakes, but, thankfully, I have had staff who have been very forgiving as I have grown into the role of being a manager and a leader.

With that in mind, I want to share some tips and thoughts about managing that I wish I had known as I made the move from one aspect of design to the other.

You can’t design anymore

Big surprise. Just as you get to a point of comfort and expertise as a designer, you are promoted to a manager—right out of the role you are really good at—into a role you know nothing about. Now other people do the design, but they look to you for guidance. As a manager, a big part of your job is to delegate and early on, it will be hard. It will take longer to explain a project or task to an employee than just doing it yourself, but you have to remember that your job is not to do, but to guide. It’s uncomfortable and awkward at first, but that goes away with time.

I had a great employee early on (an individual I considered a peer) who would question any project or task that I took on myself, and ask, “Isn’t that something you should or could delegate?” As a new manager, I kept forgetting that I didn’t have to-and shouldn’t do-all the work myself. Every time you sit down to do a task, ask yourself, “Can this be delegated?” “Is someone else on my staff better equipped to do this?” “Would this exercise be a great growth opportunity for someone on the team?”

Giving orders is costly

As a designer, you are responsible for all the little pieces and all the big decisions that go into producing a successful solution. You had a specific way of working, and that process made you successful as you moved up and gained experience. Now this is all out of your hands. You must cede control over all these little decisions and think about the big picture.

As a manager, you must remember that your way of working is not the ONLY way of working. It’s easy to fall into the trap of telling someone HOW to do her job rather than offering guidance and feedback on the outcome of the work or to create the vision and space whereby your team can succeed. If you micro-manage your team, they will resent you. They won’t learn and grow, you won’t learn and grow, and you will see a turnover rate that isn’t healthy for the business. Remind yourself of the golden rule: treat others as you would like to be treated yourself.

You are always sending a message

It’s hard to let go of the design work, but you have to remember that employees look up to you for guidance and a framework within which to do their work. You empower them to be successful and to do great work. They can learn from you. But it is also important to remember that they bring their own experience to the table and they may just teach you something new if you let them. Let them teach you.

A good manager lets go. It isn’t about CONTROL. Success is about giving your team the space to be brilliant. Your job is to create that space and to deflect and filter the distractions that could create roadblocks.

Shaping careers

As a designer, you are responsible for advancing your own career. No one is going to do that for you. As a manager, it is part of your responsibility to help your design staff craft and grow in their careers. Even though I just said the designer is responsible for her own career, many often float from one job to another without thinking about actively shaping it. Despite that, designers can be poked and prodded and guided into taking that responsibility.

Ambitious people will already be doing this, but other folks will just muddle along without thinking about where they are going, or how this job moves them to the next or the one after. They need to be thinking about what will they be doing in five years, and you can help them craft a plan to get there. Of course, decisions such as projects, conferences, and training should line up with both the company and employee goals.

In addition to quarterly and yearly goals aligned to the business goals, I ask my team to also develop personal goals that help them to continue to grow and contribute back to the team. Additionally, I challenge them to think about their five-year goals, then partner with them to make choices and provide opportunities and projects that can help them achieve those goals. This is important because you want your team to stay fresh and continue learning. I believe this curiosity and desire rolls back into the work.

You are still designing

When you practice as a designer, you are solving a client’s problem, fleshing out an interaction to address a user task, or creating a communication vehicle for a message. When you practice as a manager, you influence these things but you also are designing something different. Your decisions shape an organization, and they help design someone else’s career. The choices and combinations of people you put together for a project is as much design as the process of fleshing out type or color or an interaction widget choice.

Just as you need to understand the media you work in as an individual contributor, you must understand personalities, temperaments, skill sets, and other factors about the people you have to work with. That understanding is critical to put together a good functioning team that will be successful together as well as individually. I find this aspect of design to be quite challenging as well as rewarding. When one of my teams creates a great design that they are happy with, our users are happy with, and the other cross-functional teams are happy with, and the process was smooth, then I know I have done a good job in my design role.

Managing versus Leading

So you are asking yourself, do I want to go into management? Is this the only way to move ahead in my career?

The answer is no.

You can move into very senior individual contributor roles. Many organizations have principal designers or design strategy roles that allow individual contributors to have an impact and affect business and product design at a broad, sweeping, strategic level without actually having to manage people.

You can be a team lead or an art director and lead a team and design projects without actually having to manage the other people on the team. In these cases there is sometimes project management in terms of setting expectations and milestones and providing design feedback as necessary, but not direct people management.

Managing versus Leading

No this is not déjà vu. It’s important to remember that as you move into a management role you are actually accountable for a couple of different facets of the job.

You need to be a manager-managing projects, schedules, people, careers, and so on. You also need to remember that you are a leader. You are leading this group of people you manage, and you need to remember that leading is done through example and by having vision and strength. This is the hardest part of the job.

Sometimes it is a lot easier to just manage the day-to-day, push the papers, write reports, and go to meetings than it is to really lead the team and have a vision that inspires them to do their best work. It’s harder to inspire people to rise above the crap that often accompanies us in the real world of work.

Keeping sight of what success looks like, creating the space for brilliant work, and inspiring your team are all part of what it takes to be a leader. It also means making hard decisions based on what’s right for the business and the overall company vision. Sometimes your team might not like those decisions, but it’s important to help them understand the context behind the bigger picture. Sometimes it means standing up for the right thing, for the product, or user even when your boss or other executives don’t agree. It’s important to back your team up and stay true to your ethics.

You can be successful in the most challenging environments, and you can nurture a talented and successful team.

In the end…

It is important to realize that you can progress in your career without ever having to manage people. And that’s OK—lots of people do it and are very successful. But if you do decide to make the move, do it consciously and thoughtfully and with as much grace as you approached your role as an individual contributor. Remember the advice I have shared, seek out your own mentors, and embrace the ambiguity and discomfort of your changing role. It will reward you significantly in the long run.


Also check out “Three Pronged Fork” to learn more about career choices.

Leaving Las Vegas

by:   |  Posted on
“Now here it is: four years later. We are part of the landscape and a resource that is often referenced. Everywhere I go, folks refer to an article they read on Boxes and Arrows. We are expected to be here.”As we near the fourth anniversary of the crazy idea that Christina had, I find that it’s time to look to other priorities in my life.

When Christina first approached me four years ago, it was to be a writer for this new secret project of hers. I was honored and of course immediately said yes. Within a month of that request, she and George Olsen approached me about being co-editor, and with that I was pulled into the fold. Several people were working furiously trying to craft and shape and design a place that information architects could have a voice. This was to be a place to share and learn and not be encumbered by the baggage of academic language or obscurity. This was to be a place of practice, craft, and open arms as we sought to find our home in the greater universe of the user experience realm.

George and I worked diligently to define types of articles and features we wanted—what would be regular columns and what would be monthly features. We aspired to a lofty goal of two articles a week plus a monthly “Welcome.” On a volunteer basis with two editors, that was lofty indeed. We made lists of people whose writings – from articles, books, blogs, and list postings – that we liked, admired, or just plain suspected would be thought-provoking or controversial. We approached people to write for us.

When we launched at the 2002 IA Summit a few months later, it was with a full stable of articles, a planned calendar, and a queue full of works-in-progress. At the Summit, Christina said, “I’ll be happy if we last six months.” Little did we know. It was a few months later, when George resigned, that I took on the mantle of editor in chief.

Now here it is: four years later. We are part of the landscape and a resource that is often referenced. Everywhere I go, folks refer to an article they read on Boxes and Arrows. We are expected to be here. The last few years has seen a dot-com bust and gradual rebuilding. Folks have been out of work, freelanced, became entrepreneurs, and finally joined staffs and rebuilt organizations in-house. This cycle has also affected Boxes and Arrows. As a volunteer organization, we have seen the cycle of authors, of volunteers, and of readers rise and fall as people became employed again and became engaged in a myriad of activities. The landscape, too, has gotten more crowded as more people have found their voice to share. Yet, despite the pressures of jobs and life, we continue to have a flow of great people interested in writing. People want to share their experiences and their practice. I am continually amazed at how open and giving this community is.

Over the years I have had the pleasure of meeting some great folks and of working with very dedicated people. George Olsen, Ryan Olshavsky, Brenda Janish all gave their time and effort. Our current editorial staff—Dorelle Rabinowitz, Liz Danzico, Javier Velasco, Jim Kalbach, Jorge Arango, Elisa Miller, Pat Barford—all eager and working behind the scenes to keep the knowledge flowing. Our copywriters Lara Ferguson McNamara, Emily Wilska, and Kirsten Swearingen always ready at a moment’s notice to turn something around in 24 hours. Thanks.

It is with this reflection that I announce my resignation as editor-in-chief and the appointment of new leadership. It is time for new voices and fresh eyes.

I am confident that Boxes and Arrows is going to be in great hands and am proud to pass the baton to Liz Danzico as the new editor-in-chief. And Javier Velasco has accepted the first ever managing editor role.

I’d like to thank Christina for the opportunity that she gave me—without really knowing me at the time, and for our readers for being there and continuing to come back.

Most of all I’d like to thank all the authors that I have worked with over the years. Some of the work was hard (you know who you are) and some of it was easy, but because of all of it, I am a smarter person because of what you have shared.

Thanks for the privilege of working for you.

Erin Malone

Erin Malone is currently Director of Design, Platform group at Yahoo! Her team is currently responsible for developing tools, brand guidelines, cross-network research and a knowledge management system for Yahoo! Design Standards and Best Practices for the entire User Experience group. Before Yahoo!, she was a Product Design Director at AOL (America Online) and worked on such applications as AIM, WinAmp, AOL Radio, AOL Media Player, AOL Wallet, My AOL, various Community products and other things deemed important to the company. Prior to AOL, she was Creative Director at AltaVista, where she managed a team of Information Architects and Designers working on the AltaVista Live portal and various other web applications. Other work has included being the first and only IA/Interaction Designer at Zip2, working on the first generation Adobe web site, redesigning the San Jose Repertory Theatre web site, as well as designing GUI for several projects at Eastman Kodak company and early AOL Greenhouse partners. She has plied her trade in interactive and digital information spaces, including the web since 1993. Prior to that she worked in some crazy field called Advertising where she was indoctrinated into the world of Brand and Marketing.

Erin has a BFA in Communication Design from East Carolina University, Greenville NC and an MFA in Graphic/Information Design from the Rochester Institute of Technology, Rochester NY.

As an editor she spends a lot of time reading these articles and wrangling writers. In her spare time, she cycles, takes a lot of photographs, plays guitar and keeps multiple websites including The Dr. Leslie Project a web interpretation of her Masters Thesis; a Photolog and Design Writings, in which she talks about Design, Design History, Information Architecture, Design Theory and Design Criticism.

Implementing a Pattern Library in the Real World: A Yahoo! Case Study

by:   |  Posted on
“We recognized that the “warm, fuzzy feeling” that people get when contributing to the greater good would wear off once the designers recognized the amount of time writing a good pattern requires.”

Our problem

Yahoo’s multiple business units, each containing decentralized user experience teams, have a natural tendency to design different solutions to similar problems. Left unchecked, these differences would weaken the Yahoo! brand and produce a less usable network of products. Designers and managers have discussed “standards” as a way to solve this problem but this standards content (often contained only in the memories of designers) has never existed in a commonly accessible format.

Our goal

Our first goal was to find a way to communicate standards for interaction design to increase consistency, predictability, and usability across Yahoo! with the ultimate intention of strengthening the brand. This aligned with the business goal of increasing both the number of return visits and the average number of products used per session. Our second goal was to increase the productivity of the design staff by reducing time spent on “reinventing the wheel.” If we were successful, other designers could re-use the solutions contained in the library, reducing development time.

Our solution

We designed and built a repository for interaction design patterns, created a process for submitting and reviewing the content, and seeded the resulting library with a set of sample patterns. We organized the content to make it findable, structured the content so it was predictable, and tested and iterated the design of the user interface of the tool to make it usable. Throughout this process, we introduced incentives for participation for both the contributors and management to encourage submissions and support.

We took the following approach, broken down into the following stages:

  1. Understanding and agreeing on the problem
  2. Developing a workflow
  3. Generating organizational buy-in (evangelizing)
  4. Selecting, designing, and building a application
  5. Using the pattern library as a body of standards

Understanding and agreeing on the problem

We made use of existing research.
We were lucky to have the results of a contextual inquiry conducted a few months previously with the Yahoo! design staff. The findings pointed out that the staff wanted a central place to pool their collective knowledge. They wanted shared interaction design solutions, but no one ever had the time to develop and document them.

We wrote a lightweight product requirements document (PRD).
We began by reviewing the research and drafting a lightweight requirements document. Once the outline was done and some thoughts were fleshed out, we had meetings with interaction designers and design managers to test our assumptions. Were we heading in the right direction? Did the proposed solution seem useful? Feedback was incorporated into the PRD.

Developing a workflow

Before we could build an application for managing the patterns, we needed to determine where the content would come from, how it would be reviewed and published, and who would maintain it. To that end, we designed a workflow noting the prerequisites for each step as well as the participants and their responsibilities. We vetted the proposed process with each user experience team before moving on to building the application. Wherever possible, we attempted to build “hooks” into Yahoo!’s existing design process. For example, we knew that new interaction design solutions are often identified during design reviews, so the step of “identify pattern” was added to our existing process.

Figure 1 – The pattern library workflow, [PDF of this file]

We defined processes for communication.
We recognized that it would be useless to have a great library of content if no one knew about it, but at the same time didn’t want to be emailing the designers about every new contribution. To solve this, we designed a communication roll-up method. Calls for authors, announcements of new patterns, notices of patterns needing to be reviewed, and updating the designers regarding the most recent pattern ratings would be rolled up into a weekly email. In this way, the team would be aware of the activity in the pattern library without being continually spammed.

Generating organizational buy-in (evangelizing)

We involved the contributors and consumers of the content.
We conducted a low-fidelity usability test on the draft UI. This, in addition to the contextual inquiry, and the designers’ involvement in the definition of the requirements and workflow helped ensure that we built the right product for our audience.

We defined (and are still defining) incentives for contributors.
We recognized that the “warm, fuzzy feeling” that people get when contributing to the greater good would wear off once the designers recognized the amount of time writing a good pattern requires. To that end, we set out to create incentives for participation. Our ideas fell into three categories:

Raffles and contests. Shortly after releasing the pattern library application, we raffled off an iPod Mini. Every time a person authored, contributed to, or submitted a pattern for review, they received a virtual ticket. At the close of the raffle, a ticket was randomly picked. The raffle not only helped increase participation, it also generated buzz about the library.

Peer recognition. Presently, we’re considering adding functionality so that users of the library can rate each pattern’s usefulness. Once we know which the most useful patterns are, we can recognize their authors.

Performance evaluation. Perhaps the most compelling incentive is to write job descriptions so that contributing to the library is on each designer’s list of quarterly goals. We’re currently in the process of defining this and pitching it to the design management team.

We held training sessions.
We presented an “EZ-bake recipe” to the interaction designers that stepped them through the pattern-writing process and provided tips on how to write for their peers.

Write a Pattern Pattern Writing Process
Figure 2 – Slides from the tutorial on writing effective patterns

We defined incentives for management.
We found that the best incentive for getting management buy-in was to align the project’s goals with stated business goals. For example, we were able to make the case that increased consistency across the network would increase the number of return visitors and the average number of products used per session. We also demonstrated to the Chief Product Officer how he and his staff could use the library when reviewing major products before release.

Selecting, designing, and building the repository

We determined the repository should:

  • be scalable
  • be customizable
  • be easy to use
  • encourage collaboration
  • allow categorization

The primary decision was whether to build versus buy. We looked into a few commercial applications, but the upfront costs and the inability to modify them easily as our needs change discouraged us from going that route. Because we had a server for the design group and some technical know-how, we decided that open-source would be the best for us.

Within the open-source community, there’s a myriad of programming languages and databases. Since we had a UNIX server running some internal apps using MySQL and since PHP was the Yahoo! standard, we focused on content management systems that matched those technologies, although we did consider applications written in other languages.

Some of the solutions we considered included:

  • Blog applications (e.g. Movable Type)
  • Open source CMSs (e.g. pMachine, PHPNuke, Drupal)
  • Groupware (e.g. PHPCollab)
  • Wikis (e.g. Tikiwiki)

Some things we thought about when choosing our CMS:

  • How easy is it to update content?
  • Does it support collaboration? Can it generate diffs or do rollbacks?
  • How extensive are the classification tools? How many vocabularies are supported? Does it support parent/child relationships?
  • How does it handle rights? Can we set different rights for contributors, editors, and administrators?
  • How easy is it to customize and extend?

Ultimately, we chose Drupal because of its breadth of capabilities, powerful taxonomy, and extensibility.

We designed and tested the UI.
Using the requirements and workflow as our guide, we created wireframes of the pattern submission and retrieval application and conducted low-fidelity user tests with our end users. Free lunch was offered as an incentive for participation in the tests.

Figure 3 – The paper prototype used to test the pattern library tool

We structured the content to make it predictable.
We developed an input form for pattern creation so that a pattern’s contents would be structured and predictable. We surveyed pattern libraries on the web to devise a base set, and after some trial and error, settled on the following fields:

Figure 4 – A sample pattern
  • Title. Usually the name of the problem, solution, or element type in question.
  • Author. Each pattern has one principal author.
  • Contributors. For when there are co-authors.
  • Problem. Written in user-centered terms, i.e. what is the problem presented to the end user?
  • Sensitizing example. A single screen shot to serve as the picture worth a thousand words. Additional images may be added to the other fields; this is the one that really needs to count.
  • Use when. A statement to describe the context for the problem/solution pair.
  • Solution. A prescriptive checklist of to-dos. We found that this format was the most easily consumable by our time-pressed audience.
  • Rationale. A set of statements that reinforce the solution above. We separate all rationale information from the solution to make the solution easier to scan and consume. This field can also be used to summarize the “forces” that other pattern languages describe.
  • Special cases. Known exceptions. Often these exceptions warrant their own patterns.
  • Open questions. Unknowns. Useful for documenting areas that require further research.
  • Supporting research. For linking to usability reports, audits, etc.
  • Parent pattern. If this pattern is a specific solution to a broader pattern, this field is used for selecting its parent.
  • Related Standards. For cross-linking to related patterns and visual standards. (See Using a Pattern Library as a Body of Standards.)
  • Categories. Contains the pattern library’s four vocabularies to allow users to browse by category.
  • Importance of adherence rating. The application computes the median of the submitted ratings. The visualization of the rating shows 0-5 bars.
  • Comments. Notes and feedback from pattern’s consumers.

The fields required to define a pattern are the Title, Problem, Use when, and Solution fields. Other fields that aren’t filled out don’t show up on the pattern detail page.

We made the content findable.
We realized that as the pattern library grew, finding a solution to a given problem in the library would become increasingly difficult. To this end, we developed four vocabularies for classifying the patterns:

  • Element type. A list of nouns that describe the “what” of the pattern. If the pattern describes an element such as a button, field, page, or module, you’ll find a term in this vocabulary for it.
  • Task type. A list of verbs that describe the “how” of the pattern. If the pattern describes a method such as sorting, navigating, searching, or communicating, you’ll find a term in this vocabulary for it.
  • Application type. Terms that distinguish among patterns that are intended for different applications such as for the web or a compiled application.
  • Device type. Terms that differentiate between patterns for desktop computers and those for mobile phones, TVs, PDAs, cameras, etc.

These categories didn’t spring forth from the forehead of Zeus—they emerged after studying sample content and by listing the content we anticipated. Several of the vocabularies that were initially suggested had to be scrapped. In particular, we found it was counter-productive to classify patterns by their product type, location, or language. In the future we may add additional vocabularies, for example to distinguish patterns that are relevant only to double-byte character sets.
Because most of the patterns submitted are individual articles, not extensive families, one of the challenges to date is creating a coherent “language” that ties the patterns together so that the collection is greater than the sum of its parts. The library’s editor attempts to group and cross-link patterns using broader (parent), narrower (child), sibling, and related relationships. Because of the large number of authors, creating these relationships can be arduous, however.
In addition to navigating the patterns by category or by their relationship to other patterns, we also present the contents in a number of lists:

  • Table of contents – an alphabetical index of the broadest patterns with the narrower patterns shown indented below their parents
  • Sortable index (planned)
    • By title
    • By author
    • By rating
  • What’s new
    • Recently submitted
    • Recently modified (planned)
    • Recently commented upon (planned)
    • Recently rated (planned)
  • Review queue – shows the patterns under review

Figure 5 – Selections from the pattern index and review queue

We seeded the library with content.
We decided to launch the library with content for several reasons. First, we figured having a grand opening for “an empty room” wouldn’t be compelling. Second, creating the content up front allowed us to structure the documents appropriately and build the right classification methods. Third, it allowed us to debug the application. Lastly, it provided examples for other contributors to follow.

While the library was under development, we collected patterns using a simple Microsoft Word template. Designers filled out the templates, then emailed them to the editor. These patterns were ported into the content management system in a relatively static format. When the pattern application was up and running, the content was then re-ported into the new forms. If this process taught us nothing else, it was that Microsoft Word and e-mail are terrible group-ware solutions. We did, however, collect a half-dozen patterns that we were able to include at launch and it wasn’t long before additional contributions began to roll in.

Using a pattern library as a body of standards

Our goal wasn’t to simply gather a body of solutions to common problems and have it sit on a dusty corner of our intranet. Instead, these patterns were meant to have some teeth. If solutions were recognized as being “The Yahoo! Way,” then we needed to ensure that they would be consistently applied across Yahoo! products.

We decided on a ratings scale.
In order for the library of interaction design patterns to serve as a Yahoo!’s book of Interaction Design Standards, the patterns needed to be rated so that expectations for compliance on the part of designers could be set.

We looked at several possible ratings:

  • Importance of adherence
  • Strength of evidence
  • Quality / Usefulness / Clarity

Both “importance of adherence” and “strength of evidence” were borrowed from the standards put together by the National Cancer Institute and available at http://usability.gov/guidelines/index.html.
We settled on “importance of adherence” as our only rating. Its purpose is to describe how important it is for a designer to adhere to the pattern when designing Yahoo! products. In a sense, it’s describes, “how important is this behavior to the Yahoo! brand?”

We abandoned “strength of evidence” as a rating after consulting with the Design Research team at Yahoo!. The design research group was at a loss for how the patterns could be evaluated against existing evidence (both conducted at Yahoo! and researched on the web) in a systematic and affordable way.

We’re still considering a rating for quality or usefulness. This could be used to reward authors with community recognition for their well-crafted (and readable) patterns.

We quickly found that the ratings were ineffective unless the designers (and reviewers) knew how to interpret them. A 5-star system with “love it/hate it” describing the two ends of the spectrum wasn’t going to cut it. We came up with the following decision tree to determine what rating each pattern received.

Figure 6 – The pattern review decision tree

This common set of criteria helped normalize the ratings. Pattern ratings that are all over the board (some 1-bar ratings, some 4-bar ratings, for example) are marked as “contentious” and the median rating is not exposed in the application. We’ve yet to have a contentious pattern. Our current algorithm permits votes that are one bar above or below the median, and up to one vote that is two bars above or below. If we do have contention, the plan is to use our regular monthly meeting to come to a consensus (or at least give those with outlying ratings a chance to be heard). Once an agreement is reached, votes can be amended and the median rating will appear in the application.

We currently collect votes from a team of about two-dozen reviewers, of which about a dozen are active. Once nine votes are entered for a given pattern, the pattern’s median rating is exposed. The users of the library can see who has rated each pattern, but the ratings given by specific individuals are kept hidden. Both of these strategies were put into place to reduce groupthink.

We assembled a review team.
We initially nominated a group of reviewers from different business units and from different disciplines (ID, visual design, research). We found (non-surprisingly) that the IDs were the most motivated reviewers. In the future we hope to tie a designer’s membership in this group more closely to his or her quarterly objectives. In this way, each reviewer will have more incentives to participate and each design director will have more say in who participates.

We continue to avoid being labeled as the “standards police.”
The ratings themselves are not the final word on compliance; they merely show the expectations of the review team. The product team and the design reviewers have the responsibility of interpreting the standards during design review.

We use design reviews to test assumptions about the presented solutions, to inform the designers of new patterns, and to facilitate close team collaboration and the discussion of emerging standards. We have consciously put ourselves in the position of information broker or facilitator rather than design cop. This approach has contributed to wider acceptance of the process and a marked improvement in the quality of the design work. As a result, we’ve enjoyed watching as consistent design solutions leapfrog from group to group.

We decided to separate out visual design and code from the pattern library.
The library of interaction design patterns is only one part of a three-pronged strategy to capture and communicate standards for Yahoo!. We are also collecting standards for visual design and code samples into their own libraries. We’ve kept these three initiatives separate from each other for several reasons.

First, the standards for interaction design, visual design, and code change at different rates. For example, the visual style for a button may change more frequently than a solution for paginating search results.

Second, they do not necessarily map to each other. For example, a pattern for Menu Item Order may not require a corresponding visual standard and there may be a dozen visual standards for typography that do not map to any one interaction design pattern.

Third, the content for interaction, visual design, and code repositories comes from different sources and the reviewers of this content have different expectations for compliance:

  • The interaction design patterns are more of a grass-roots effort, coming mainly from the group of interaction designers at Yahoo! (bottom-up). This is in part due to the vast number of contexts in which the solutions are needed and that the central standards group is too small to capture solutions to such a wide variety of problems. The interaction design patterns are rated by a group of representative interaction designers.
  • The visual design standards and assets are centrally managed (top-down) and are designed, written, and edited by a central group. These are tightly managed to allow the stewards of the Yahoo! brand to more easily shape Yahoo!’s online brand identity. The visual standards are vetted in design review but are essentially dictated by the creative director.
  • The sample code is contributed by Yahoo!’s web development group (bottom-up) but best practices for writing code are centrally managed (top-down).

Our plan is to maintain these repositories separately but ensure they are heavily cross-linked.

Current activities and future plans

We’re currently projecting 10 – 15 new patterns per month over the next year to add to the sixty patterns currently in the library. Meanwhile, we’re collecting a list of enhancements for the pattern library application and designing and building the repository for visual standards. After the visual standards tool is in place, we’ll work with engineering on the best solution for linking these two tools with code samples. Ultimately, we plan on rolling out toolkits containing approved visual assets and code that conform to the visual and interaction standards to further reduce development time and aid under-resourced business units.


The pattern library allowed our small, centralized group to tap into the broad expertise of the Yahoo! design staff. What would have been impossible to write (authoritatively) by a small team is now being contributed to and reviewed by an expert staff. We were able to achieve this by understanding and agreeing on the problem, building a workflow that fit with the existing design process, generating buy-in by creating incentives for contributors, and by carefully designing and building an application with attention to user feedback.

We were then able to convert this library of patterns into a workable set of standards by agreeing on an appropriate rating scale and by assembling a representative group of reviewers who rate the content according to the same criteria.

Ultimately, we expect that pattern library will result in a strengthened Yahoo! brand and a more efficient design staff.

This paper, our slides, and printable versions of selected figures are available at http://leacock.com/patterns.

Compare and test drive CMSs.

The Yahoo Pattern Library is now public

Redesign Submissions Closed

by:   |  Posted on

REDESIGN UPDATE Submissions are closed and we are no longer accepting entries.
Thanks to all the folks who worked hard to submit a new visual vision for Boxes and Arrows and for all the great questions and discussion about the redesign.

Our final confirmed judges panel: Hillman Curtis, Katherine Jones, Andrei Herasimchuk, John Rhodes, Lou Rosenfeld, Nathan Shedroff, and Jared Spool.

We received over thirty entries from more than five countries. Christina Wodtke and Erin Malone will be spending the next two and half weeks reviewing each entry individually and prepping the entries for our judges.

Judging will begin the first week or so of September (specific date to be determined based on various travel schedules) and we will announce the winner and post the top 5 runner-ups on the site the end of September / beginning of October.

The first prize winner will receive a set of professional books from the fine publishers at PeachPit Press and (this just in) software from Adobe (exact titles and platform tbd)!

Mission Statements: Why You Might Want One

by:   |  Posted on

I recently started a new job. The group I manage is new and all the people on my team have recently been transferred into this group. Additionally, each person has spent a lot of time in the recent past working on individual, solitary projects, and has not regularly been part of a collaborative team.

Coming into a new company is difficult. Joining a newly-formed team can be even harder. Not only are you new, but the group dynamics are new as well. This is exciting and scary at the same time. There is no shared history or knowledge base to draw from in terms of how people will work together or be successful. On the other hand, the slate is clean and there are fewer possibilities of being compared to what was done on the past.

In an attempt to bring this group together quickly and create a sense of shared purpose, I decided that we needed to develop a mission statement for the team. This is important for a couple of reasons. One, it taps into the “shared vision” (see Christina’s article) mentality and it creates a statement for the rest of the department and company to understand what you are all about. Because the group is new, what we do is still somewhat undefined, and through several conversations with peers and other design staff, I came to realize that the perception of our purpose and place in the overall organization was varied.

Writing a mission statement for a team or department is a challenge. (Shoot, it�s hard to write one for yourself!) But it is a great exercise to go through. Most companies have mission statements, as do many large organizations–they can be equally useful for small teams. The mission statement is deceptively simple-looking. It’s important to try to distill the essence of your message of what you are about down to two or three sentences. The mission statement should tell the story of your ideals. The challenge lies in not to getting caught up in the “we are so great” type of language.

To create my team’s mission, I decided that one of the best methods to bring this team together was a group brainstorm. Together we would try to distill the core attributes that speak to the values and goals of this team. To use the mission both as an internal team building tool and external message that the team believes in, it is important to do this exercise as a team. The conversations and brainstorming and contradicting and negotiations over what is important and what isn�t is key to ensuring a shared sense of purpose.

I approached the session with three questions to the team:

  1. “What are we doing now?”
    (What has each individual person been responsible for and how does that fit into this new group?)
  2. “What should we be doing?”
    (Trying to think big and capture the sense or purpose and longer term vision.)
  3. “What are we not?”
    (What misconceptions are out there that we need to dispel as far as the role of the group in the organization?)

More formally, these questions translate into:

  1. Who we are.
  2. What we do.
  3. What we stand for.
  4. Why we do it.

A working session was spent discussing these questions and a whiteboard of lists created. From this raw material, I sat down and tried to draft a coherent mission statement. The statement is about three sentences long and touches upon these key points. I sent the draft out for review and feedback from the team, and went through several rounds of revisions based on their comments.

About halfway through the process, I realized that part of the mission was too specific. So I pulled out a few key phrases and used them to create a set of goals, and specific objectives toward reaching those goals. By pulling the more specific, tangible information out, the mission statement became a high-level, inspiring statement of what this team is, wants to be, and should be responsible for. It is something we can believe in, that expresses our ideals. The mission also sets the stage for the long-term development and growth of the team. Through the mission statement, we are able to reach ahead and put a stake in the ground about higher-level strategic opportunities the team will aspire to.

The mission, together with the goals and objectives that evolved out of the brainstorming session, satisfies the tangible aspect of what we do now as well as the loftier, more strategic aspirations of the team that establish what we stand for and why we do the work we do. It’s a good start, and the team and I will be sharing and evangelizing the message to the rest of the organization over the coming weeks.

Erin Malone, editor in chief for Boxes and Arrows, is currently Director of Design, Platform group at Yahoo! Her team is currently responsible for developing tools, brand guidelines, cross-network research and a knowledge management system for Yahoo! Design Standards and Best Practices for the entire User Experience group.

Planning your future

by:   |  Posted on

“It’s not the plan that is important, it’s the planning.”

—Graeme Edwards

I have been thinking a lot about career growth lately, and as a manager, have been generally concerned with making sure there are growth opportunities for my staff, regardless of their level or the point they are at in their career.

This often means rearranging teams so that a staff member might be stretched to grow in a new skill—as a designer, as a mentor and leader, or just in a new domain (i.e., moving from a music product to a mail product). In addition, I am always looking for networking, conference, and classroom opportunities that would benefit not only me, but my staff as well.

But not everyone has a manager that is concerned about her career growth, and there are even times when day-to-day work concerns are a priority and career growth needs are far in the back of my mind. As a matter of fact, for most of my career, I never had anyone watching out for me. For the first part of my career, I don’t even think I thought much about my long-term career. I just seemed to happen into new opportunities that taught me new skills and kept me growing and challenged. But there was no plan, no goal other than to stay challenged.

The point is, in the big picture, no one is going to look after your career for you, but you.

A few years ago, a manager of mine gave me the assignment to work on a five-year career plan. I had never created a career plan before (not even to plot out goals for the coming year), so I was completely unprepared for how and why I should do this. Luckily, she shared her own plan as a guide, but I still agonized through the exercise. Over time I have become aware of how important this was for me to do. Looking and assessing where I was at the time, really thinking about what I wanted to be doing in the future, gave me the tools to make the right decisions to make things happen.

After I was done, I realized that most of what I put down for a five-year plan could be done in a year. But it took writing it down to see that and to make it happen. This also was a good tool for working with my boss to craft training and work opportunities for me to meet my goals. I also made sure that these goals included life and personal goals as well as career goals. The older I get the more I realize that these are intertwined and success in one space brings success to others. Work/Life balance matters.

In an effort to make this anecdote meaningful to you, I’d like to share the steps and some resources I used to help me prepare my five-year goals.

The Template:

  1. Your Name
  2. Today’s Date
    This is important as you reflect back on this document. This will become a touchstone for your growth and a reminder of who you were as you look back at what was important to you in this point in time.
  3. 3–6 Months
    • Start small.
    • Think about short-term goals that are easily achieved but will also help move you towards the longer-term goals.
    • Include some tangible goals (i.e., ship a product that I acted as lead designer for).
  4. 6–12 Months
    • Start thinking bigger here—this is planning for a year out.
    • What new skills do you want to learn?
    • What new ideas do you want to share with others?
    • What changes do you want to make? Put them down here along with the steps needed to take to make them happen.
  5. Beyond 12 Months
    • Capture specific plans that you know may take more than a year to get to or accomplish. For me, it was to work on my Dr. Leslie book. I discussed the idea with a writing partner 3 years ago, but it is only now coming to fruition with an actual proposal in hand and a potential publisher.
    • Be realistic but not afraid to reach. Visualize success in areas you may have little control over. Don’t be afraid to write down a desired goal that may be a stretch.
  6. Longer-term Goals
    • This is the area to think out for the next 3–5 years, including life beyond the company or situation you are currently in. For me, I listed “teaching again” as a goal. This reminds me that I want to do this and I need to make certain decisions and changes in order to make it happen.

      If I decide at a later time, that I don’t really want to do this, I should remove it off the plan.

  7. Opportunities to Explore at Your Company
    • List all the training and coaching opportunities relevant and currently available at your company.
    • Note relationships that need to be cultivated at your company in order to meet success.

      Note: This obviously may not apply if you are an independent consultant. Think about other opportunities that might be available through professional associations and networking instead.

  8. Skills to Develop
    • Project what skills you need to develop to reach the goals you listed in the first part of this exercise.
    • What other skills do you need, besides the ones you have now, to attain your goal?

      Since I am a manager and this is the area in which I have been growing, I listed things such as Confidence and Effectiveness—along with ideas on how to master these more intangible skills.

      Over the last couple of years, I have purposely put myself into situations to gain confidence—especially when giving presentations. Think about starting slow and building on your successes.

      In addition, I also listed skills of associated/allied roles that I would like to learn in order to make myself a more well-rounded and effective manager in my company.

  9. What I Care About in a Work Environment
    • This may seem frivolous or not important to the task at hand, but it serves to remind you of the values you need to share with the company you work for. As you grow or the company changes this can help guide you when you need to make a change.
  10. Personal Goals
    • Don’t forget the personal goals that you need to weave into your life. It never hurts to write these down as a reminder of work/life balance and of the things that are really important to you as a person.

You can use the finished plan as a tool when working on performance goals with your boss. Letting her know what you want out of the job is as important as your manager being clear on what is expected of you. Reminding her regularly of your goals is also important, as we tend to fall into patterns of behavior that may not be best for our long-term career plans.

I pull my career plan out periodically to check off what I have accomplished, and have begun adding to the long-term section. I see how I have grown and what areas I still need to work on in order to reach the goals I have set. I can also see that some things that were important to me three years ago are no longer important, and that there are new areas of growth I am cultivating.

The point of this exercise is to come up with a realistic plan within the framework of your interests and career path. The list should be visited regularly and modified as you reach goals or when goals are no longer important to you. The plan should help you shape a vision towards reaching a future destination and remind you that success does not happen by chance.

  • Creating a Career Plan
    http://www.lmabayarea.org/pdf/LMA Career Planning.pdf
    Sugarcrest.com. This PDF from a career training firm offers some good exercise questions to answer about your values, strengths and current situation. A nice companion to the template detailed in this article.

Erin Malone is currently a Product Design Director at AOL (America Online). She has been a practicing interaction, interface and information designer since 1993. She is editor in chief of Boxes and Arrows.

Looking Forward and Back

by:   |  Posted on

“I resolve to spend less time worrying about educating people about what I do, and more time doing what I do—designing websites people can use.”

—Brenda Janish

Reflections on 2003 and resolutions for 2004

Looking back

This time last year, Boxes and Arrows published a few predictions. We promised that at the end of 2003 we would take a look back and see how insightful these predictions were. As expected, many of these predictions were ahead of their time and I expect that it may a couple more years before these come to pass.

Here are a few of those predictions and their outcome:

Dan Brown predicted:

The number of books specifically on information architecture (a la Polar Bear and Blueprints, et al) will double.

B&A: Well, they didn’t exactly double. An Amazon search reveals 14 books with Information Architecture as a phrase in the title with only four coming out in 2003. On the other hand, we know that many usability, information design and design books that are relevant also came out in 2003 so collectively there are a lot of good resources available.

There will be at least one course on information architecture in every major university in the world.

B&A: Mmm, how to check this one out. There are a lot of new courses in IA showing up in universities around the world. However, finding consistency in curriculum or even in the type of department offering the class, cerificate, degree is hit or miss at best. We still have some work to do here.

Earl Morrough predicted:

I predict that in 2003 the subject of the emerging profession of information architecture will be picked up and reported on by at least one of the major television news networks. The report will include clips from an interview with either Christina Wodtke, Peter Morville, or Louis Rosenfeld.

B&A: Well, maybe this year.

Jeff Lash predicted:

2003 will be the year of wireless. Wireless networks in homes, businesses, and public and common spaces will be increasingly popular, and cheaper service plans for mobile phones and PDAs will drive the development of usable and useful wireless-based applications.

B&A: Close. We are getting there. I think 2004 will actually see the cheaper prices and free common spaces. Where folks dabbled in 2003, 2004 will see wireless become commonplace.

Christina Wodtke predicted:

“Findability” will begin to be part of the business vocabulary along with “usability” and “understandability,” but not until the end of 2003, where it will be mentioned in a magazine such as CIO or Fast Company.

B&A: Well, I couldn’t find, findability mentioned anywhere except here and Peter Morville’s site. But CIO has a couple of articles, from the latter half of the year, about using audience to drive website design. Sounds like UCD to me.

And Dan Saffer successfully predicted:

Several IAs will get drunk in Portland.

B&A: I think he hit the nail on the head there. Any predictions for Austin?

Here are the rest of last year’s predictions. Boxes and Arrows invites you to add more of your own and comment on the success or failure of these to come to pass.

Looking forward

To ring in the new year Boxes and Arrows asked our staff and members of the IA, UX, and Design community to share some of their professional resolutions. We have seen this community grow, fracture, and come together as we all share common goals. And I think our collective resolutions reflect our continued growth and search for excellence in our work.

Brenda Janish:

I resolve to spend less time worrying about educating people about what I do, and more time DOING what I do—designing websites people can use. And—if I’m lucky—designing websites that contribute to the general good.

Liz Danzico:

Whether inside or outside of work, I’ve fallen into an accidental pattern of using certain tools to avoid voice communication. I communicate with colleagues in the next cube via email. I keep up with family members through instant messenger. I have to depend on friends’ blogs to know where they are.

As an information architect, my job is to communicate ideas. Whether the communication takes place between my client and me or between my team and an outside vendor, how I communicate those ideas is important not only in content but in format. For 2004, I intend to communicate directly: I will use the telephone more and without hesitation; I will approach people’s desks unabashedly and without warning. I will depend on the typed word only when these more direct forms are not available.

Erin Malone:

Continue to practice work-life balance and put my external community efforts into initiatives that will really make a difference—like AIFIA and Boxes and Arrows.

Write more.

Nick Finck:

Well, I have made a new year resolution to start extending my efforts within and outside of my own publication.

Part of this is joining up with Boxes and Arrows as a web developer. The other part is going things streamlined in my publication internally so I can invest more time into writing and contributing to other sites and publications.

Another part of this is just getting more in-touch with other individuals within the web community as a whole. Individuals from various backgrounds such as IA, publishing, UX, usability, accessibility, web programming and more. These are people who I already know and talk with from time to time. I am hoping that this year I can get to know these people even better and build more open communication between all of us as professionals.

As far as IA techniques, I can say that I hope to implement a new taxonomy for my publication within the year. It’s actually something I have been meaning to do for a long time but haven’t been able to
gain enough momentum to make it really happen. Along with this I plan to implement several other IA related strategies that will help improve the findability, usability and user experience of my publication.

Marko Hurst:

My mantra in life is “balance in everything.” In my now 8 year career I’ve worked for nearly every sized company from myself—several thousand, worked on projects that have lasted a few days—2 1/2 years, worked with too many technologies to remember, and played the role of nearly every person in a web development cycle from designer-developer, PM-business owner, and of course an IA.

Other than for myself I have never been a “technical” architect. So, in keeping w/ my mantra I feel the one of the greatest assets I bring to projects as an IA is my well-rounded skill-set. I feel that having been in everyone’s shoes has allows me a special insight to their cares and concerns, which in turn I can take into account and “translate” to others. So, this year my resolution is to understand System Architecture & Design.

And let’s not get crazy now, I don’t plan on selling myself as a Technical Architect by any means. The same as I do not claim to be a Developer because I can code a few JSPs or create a JDBC connection. The point is to simply to become familiar enough with another integral part of the web development cycle.

Jenifer Tidwell:

In our next design cycle, I’m going to try to keep a “design notebook” for the project. It would be, in a sense, a collective memory for the design team. From the inception of the project through the final touches, I want to keep track of design decisions made, the reasons for those decisions, all design documents, and “paths not taken”—alternative designs, features we want to implement but don’t have time for, etc.

Why? First, our design documents tend to be scattered in different places. We’d like them pulled together into one place so we can all have easy access to them. Second, our product release cycles are long—over a year in many cases—and we always end up asking ourselves questions like, “Why did we decide to do X? Did we ever consider Y? There was a good reason not to do Z, but what on earth was it?” Third, it gives us something to look back over at the end of the project; we can use it to evaluate our process, and help decision-makers “connect the dots” between our high-level goals and the features our team actually delivers.

I’ve never done this before, and I’ve never heard of it being done. It just seems like a good solution to the problems our project teams have had!

Lou Rosenfeld:

My resolution is to write a book on enterprise IA. 🙂

Keith Instone:

I resolve to actually read B&A this year! “Too damn busy working” is not a valid excuse anymore.

[We like to hear that, Keith, and we’ll be checking our IP Address logs to see if you follow through…just kidding. —Editors]

Julianne Bowman:

Finding ways of using captology in interactive marketing that are useful and engaging to the user as well as smart for the marketer.

Convincing marketers to harvest customer profile data over the course of several user visits, thus creating several “value-exchanges” for the user instead of one big, alienating registration form.

To continue trying to focus my clients on the big usability changes that really matter. They are so focused on piddling quick wins it can be difficult to get them to see the wood for the trees.

To use Visio’s new XML output facility a lot.

And finally,

Cynthia Hoffa:

I think, like me, many IAs are still stranded on the lower end of Maslow’s pyramid of needs. Therefore my short list might look modest, but it encompasses the primary things we fight to conquer in our quest for “self-actualization.”

Don’t sweat the small stuff.

Demonstrate how I add value.

Extricate myself from crazy delivery cycles.


Good words to live by.

I invite you, dear readers, to add your resolutions to the list and wish everyone a prosperous and effective 2004.

Erin Malone is currently a Product Design Director at AOL (America Online). She has been a practicing interaction, interface and information designer since 1993. She is editor in chief of Boxes and Arrows.

The Power of Process, The Perils of Process

by:   |  Posted on
“The power of a well-defined process is the creation of order amidst chaos. When it works, it can be like a fine-tuned machine, and our design work is better for it.”Traditionally, information architects and designers (UI, visual, ID) are creatures of process. We generally work in prescribed ways—discover, design, validate, repeat. We sketch first, then create rough flows and then finetuned detailed wireframes and mocks. This usually works well, once accepted, and most companies—whether in-house teams or consultancies—work along similar lines.

In my experience, I have found that creating and documenting process has been a good exercise to help institutionalize ways of working, to help educate new team members as well as to unveil the mysteries of what we do for executives, product folks, and development teams.

In my currrent situation, an agreed upon process has helped teams working in multiple time zones and across several locations to get their work done. The process — discovery and exploration, concept UI development, review, creation of wireframes and user interaction flows into a draft UI, review, finetuning into final UI and then creation and finetuning of a functional spec — is the same no matter who is working on the project or what country they sit in.

There is a lot of comfort in this shared way of working. There are fewer concessions that need to be made. Roles and responsibilities are clearly defined and everyone knows what they are going to receive at each point in the schedule. The framework within which we all work allows us to be creative, but also keeps teams on track.

The power of a well-defined process is the creation of order amidst chaos. When it works, it can be like a fine-tuned machine, and our design work is better for it.

On the flip side, problems happen when people get complacent about the structure they are working within. Expanding phases excessively, becoming rigid about the order or duration of each phase, or even over-documenting the elements within a phase can backfire on a team. There are also problems when one team decides to work in a totally different way than another within the same group. Suddenly, no one knows what to expect, what the level of thinking or quality of the product will be, and internal fighting over whose process is best ensues.

There can also be credibility issues surrounding process and how teams work with it and within it. No one wants the reputation of being so bound to a way of working that they lose sight of the reason they are working in the first place.

I was recently called out for rigidness about process by a client who went crazy over a proposed schedule. The client didn’t understand why some of the work couldn’t be done in parallel, and why certain phases of the project couldn’t be shortened. Ultimately, we were under a tight deadline to ship, and to make the deadline we all (design, product, and development teams) had to make compromises. I assured this client that we generally needed to “ask for the moon” at first, and then would pull back to something more realistic given the circumstances.

The conversation got me thinking though about how we work and how structure can overpower the actual needs of the project. If a group is not careful, the process can take on a life of its own and make demands that exceed the requirements of the situation.

For all the benefits a well-documented and richly detailed process has, it should also be a framework that is flexible, that can be adjusted at a moment’s notice to fit the situation at hand, and shouldn’t exist for its own sake.

I like to think of design process as a grand buffet. One that has discrete sections—discovery/early user research, exploration/concept, draft, final—and review checkpoints throughout. I generally like to think of each section as being collapsible or expandable depending on the needs of the project and the time allowed. Ideally, no section would be collapsed down to nothing, but sometimes it might feel that way. I also see each section as having a buffet of tools and techniques available to help solve problems, keeping in mind that just because a tool is available in a particular section doesn’t mean it must be used every time. That’s the beauty of the buffet: the framework and structure are there, but usage of the tools is flexible and can be fine-tuned for the needs of the team and the project.

Thinking about your work process in this way, getting your team or company to agree upon the framework and toolsets, and then remaining flexible within the overarching process structure will ultimately free you up to apply your skills to the tough problems—the design problems—and not the process.

Erin Malone is currently a Product Design Director at AOL (America Online). She has been a practicing interaction, interface and information designer since 1993. She is editor in chief of Boxes and Arrows.

DUX: Five Lessons Learned

by:   |  Posted on
“Great things can happen when you move beyond the bullet point.”Normally I would write a traditional conference overview to inform people about the recent Designing for User Experiences conference (DUX) held in San Francisco, June 6-8. But the format of the sessions was set up in such a way that my overview would be even further distilled from the panels, which were 8-minute distillations of the papers. So, instead, I would like to impart a few of the impressions I came away with and recommend that everyone go to the AIGA Case Study Archive to read the papers that were accepted.

We are a like-minded community.
The attendees of DUX—members of AIGA, SIGCHI and SIGGRAPH—while having different professional emphases, are a rich and robust community with much more in common than we generally think. This blended community is curious and vibrant and surprisingly interested in sharing personal stories of our work. The conversations in the breaks and at the receptions were as rich and informative as the dialogue during the panels. There was no “us vs. them,” or academia vs. real world—research and practice blended well together. As a matter of fact, unless someone explicitly pointed out that they were from one space or another, the conversations were incredibly similar.

There is a positive undercurrent in the community as a whole.
My impressions, after three days at the IA Summit in Portland this past March and two days at DUX this past weekend, is that the atmoshpere of the field is looking up. Yes, I know many people are still out of work, but it seems to me that more folks are working and less are whining; people seem genuinely excited about their work. The challenges within organizations are still there, but the stories told show that design (this includes all the flavors—IA, visual, interaction, etc.) is engaging in productive partnerships with the other organizational disciplines. Engineering and marketing are collaborative partners. I heard less “They don’t take me seriously, how can we be heard and involved?” than “What else can we do to make improvements?” and “Where else can our skills be used in the process?” this time around. Maybe it’s just me, but I think there is definitely a shift happening.

Great things can happen when you move beyond the bullet point.
I was excited to see that many of the presenters moved beyond the traditional PowerPoint deck of bulleted items and actually spoke to the audience conversationally rather than reading their slides—which we can all do ourselves. It makes it harder to take notes, but as an attendee, I appreciated the effort and the conversational nature of it. Jess McMullin chaired a panel that focused on constraints. He challenged his panelists to create their presentations without any bullets and to include more images and fewer words. This challenge worked. For the most part, the presenters were more lively, the slides were illustrations of the points rather than lists of the points, and overall, the collection of presentations was more interesting and entertaining. I challenge the rest of us to try this at home — er… work. What if we began to give presentations at the office that followed this logic? Would it help elevate the status of design within the organization? It definitely makes the presentation more challenging to give, but it forces people to listen since they can’t take away a list of bulleted items to throw into the shredder bin. Try this and let us know how it worked. One presenter reminded us that while a “constraint is a factor identified as a barrier,” an “opportunity is a factor identified as a liberator.” Liberation within design. Liberation within an organization. Liberation from the bullet point. This is a pretty cool way of looking at things.

Design can have great impact, and shoulders great responsibility.
This community is having an impact. We “design” the products people are using every day. We create new behavior and change behavior. We have a responsibility to be smart about what we do and how we do it. One of the presenters reminded us that it is our responsibility to understand the communities of practice that already exist as we design products and experiences. These communities of practice contain deeply embedded structures and processes, and in understanding these, we can create more effective experiences. Several presenters reiterated this theme, and I think it’s good to continue to remind ourselves that it is more than the user that we need to understand; often it is a collection of people within a community that will give us the insight we need.

Mentors can be found in all sorts of places. You might even be one.
One of the closing plenary speakers on Saturday was a woman named Sara Little Turnbull. She is 85 and has worked for six decades in the realm of strategic design development. She is still working, currently at the Process of Change, Innovation, and Design Laboratory of the Stanford University Graduate School of Business. As I watched her converse with Richard Anderson and relate some of her experiences, I realized that I personally was in desperate need of mentors. I try to mentor my team at work, and am always open to answering questions from colleagues in the community via email. I hope that as I share my experiences I am mentoring those coming behind me, but I sense a lack of knowledge about those who have paved the way, of those who I can learn from. What this speaker reminded me of was that we have leaders in the field who may not be recognized, yet have much to offer. I believe there is a need for more formal mentoring structures to help get people together. There are many of us—particularly females over 35—who don’t necessarily have a lot of role models to learn from. We have a lot of great peers, but the women who have gone before us are unsung heroes, women who haven’t been recognized and are still trying to get by in a corporate culture that is predominately male. This speaker reminded me that mentors are out there, and we all should seek out one or two, as well as remembering to be one ourselves.

In conclusion, I enjoyed this conference, and for being a ”dot two” release (dot one was the Forum at SIGCHI last year) the organizers did a good job. The days were interesting, I feel like I learned a few things and, most importantly, I felt excited to be a part of this vibrant, rich, and curious community, particularly at this point in time. I would love to hear how others felt, and welcome your thoughts and feedback. I’m sure our feedback will be welcomed by the organizers as they plan the next version of DUX.

    AIGA Case Study Archive As of this posting, the DUX cases had yet to be posted but keep checking back.

Some other conference thoughts can be found from other attendees here:

There is also discussion going on at the AIGA Experience Design [http://groups.yahoo.com/group/AIGAExperienceDesign] list about the conference and other attendee’s thoughts as well as a few posts on SIGIA-L (archives) [http://www.info-arch.org/lists/sigia-l/0306/0077.html]Erin Malone is currently a Product Design Director at AOL (America Online). She has been a practicing interaction, interface and information designer since 1993. She is editor in chief of Boxes and Arrows.