So You Think You Want to be a Manager

Written by: Erin Malone
“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

Written by: Erin Malone
“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

Written by: Erin Malone
“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.

Conclusion

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

Written by: Erin Malone

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)!