Modeling the Creative Organization

Posted by
“Once I had an understanding of the current landscape of responsibilities, I was ready to take a look at the roles currently covered by the team and the roles that should be covered by the team.”A few months ago, on the cusp of another reorganization, my boss challenged me to present some ideas about how my group should be organized. The challenge: “If you could organize the group in whatever way you wanted, what would you recommend doing?”

Everyone who has ever been a manager longs to hear those words. I often thought, “If I could do it my way, I would do things differently.” Now, suddenly, I was being offered an opportunity to make a difference—to design the perfect design group.

As with any design problem, I first needed to assess the current situation. What was working? What wasn’t? What skills were already in-house and what skills were missing? What type of work did we specialize in and what kind of work did we have to turn away because of lack of expertise? Did we need to be centrally located or could we continue to function in two geographic locations?

While researching the subject, I uncovered a couple of interesting things:

  1. There is not very much information out there about building a creative organization. Being a researcher-type person, I immediately went looking for models and guidance from others who have had to solve this same problem. I was not very successful, although the Design Management Institute offered some interesting articles from their journal (see For More Info).
  2. Asking friends and colleagues for advice yielded as many variations of organizations as the number of people I asked.

With external research in hand—which ended up being interesting, but not really helpful—I began to look at the details of the situation I was currently faced with.

  1. The group is an internal group—we live within a large corporation.
  2. The group is a separate entity from engineering/development and product marketing. This means being an equal partner at the table. This is very important when looking at how a creative group should be structured. Certain roles may not be needed internally because they are the responsibility of other groups.
  3. The design group is responsible for content design—channels of partner content, and product design—downloaded clients and applications as well as web-based applications where the focus is primarily interaction design.
  4. The design group was also responsible for several brands, brand style guides, some writing, and various other side functions.
  5. The group contains a user research group, which supports the designers as partners in the design process.

Once I had an understanding of the current landscape of responsibilities, I was ready to take a look at the roles currently covered by the team and the roles that should be covered by the team.

Uncovering roles
Analysis showed that the various roles practiced by the group didn’t necessarily match the distribution of people on the team. Several people were performing multiple roles. Some roles were missing altogether. Other roles were in place but understaffed.

These are the roles that were in play:

  • UI design. This role primarily consists of interaction design specialists. Many of these folks also skilled in IA and research and pull those skills out as needed.
  • Visual design. Responsible for the visual design of products and content areas.
  • Brand design. Creator and visionary of the brands and brand style guides.
  • Research. Usability and early user research specialists.
  • Web technology/HTML. Prototype specialists and front-end technology folks who interface with the development and engineering teams.

In addition to current roles, certain roles had to be recognized more formally, as they were often overlooked, given short shrift, or just plain ignored:

  • Information architecture. The organization delivers a portal product full of content and full search, yet no single person had the role of IA exclusively, which showed in the quality of the final product.
  • Visual standards. While the visual designers were responsible for upholding visual standards, no single person owned the creation, dissemination, and maintenance of visual standards documentation.
  • Technical/copywriting. Copy delivered in the interface was usually written by the user interface designers during the UI phase, with the intent of enlisting a tech writer to do copy clean-up. In reality, this responsibility was foisted on one specific team member who could only do it when they had spare time, so most copy was never cleaned up.
  • Producer/project management. Project managers lived within the larger development teams, but didn’t track the milestones of the creative team. This role was sorely lacking in our organization.

Vertical or horizontal

The next step in analyzing the roles needed was to determine whether or not each role was vertical or horizontal.

Vertical roles are generally one step in an overall linear design process. For example, UI/interaction design is generally done before visual design and is handed off upon completion. (While this is not strictly true, as UI and visual designers should collaborate together from the beginning of a project, for the purposes of this classification these roles are considered vertical.)

Horizontal roles are generally overarching throughout the whole process and generally support or inform the other roles. For example, a global information architect creates a framework and structure that an application may live within. Likewise, research informs the designer at all stages of the project. The research may take different forms at each stage but the need is constant throughout the project lifecycle.

Wrapped around all the disciplines is strategy—the business goals that define the work that all these teams work toward. Recognizing this role is important because each team needs to be aware of the overall product strategy in order to make the best design decisions possible. Leads from each group should be part of the team defining the strategy, to ensure that the users’ needs will be integrated with the needs of the business.

Creating the models
Once I had the roles defined by discipline, I began to create different drawings of the organizational structure to share with my boss. With each, I carefully identified the pros and cons and how the organization should be aligned for growth. I needed to identify what changes could be made with the teams currently on staff and come up with a plan for how to fill out the missing roles.

Looking at the base model, I realized that the needs of the publishing projects were very different than those of the product team. In many cases, the type of design practiced varied greatly. I decided to split the horizontal roles into Product and Publishing and under each place the role of UI Design and the role of Visual Design.

By doing this, I could further differentiate the two groups by establishing that the UI designers in the Products area would primarily practice interaction design, while the UI designers in the Publishing group would primarily be practicing variations of information architecture and information design.

The advantages of this model are:

  • Clearly identified roles.
  • Broader roles that are responsible for the big picture and touchpoints across products are elevated in importance.
  • All support roles are identified.
  • Very clear distinction between product and content design, with specific teams for each.

A variation of this model breaks up the horizontal groups up by UI and visual design and then creates specialties within the larger disciplines. Model 4 shows the UI team as consisting of two specialties—product design and publishing design. Visual design is broken up this way as well.

I thought about the roles of architecture and visual standards carefully as I drafted these models. On the one hand, they were very horizontal roles (Models 2 and 3) that were important to think about throughout the design and production process. On the other hand, they could be considered a subset or specialty within the greater design group. In Model 4 I have indicated these roles as being the responsibility of both design teams.

Model 4 also looks at the production group as a vertical bucket rather than as a horizontal support group. The vertical representation recognizes its position in the process as coming after the visual designers are done, who then generally hand off their work for final production. In the previous models, production is shown in a horizontal fashion. This is to acknowledge the responsibility production has across the design process to inform design about technical issues and to be a bridge between design and development throughout the process.

Conclusion
When all was said and done, there were only a few variations that made sense for our particular set of needs. The models I created brought to the table clarification of roles. They indicated areas where the organization was lacking, areas that had to be addressed. Discussion around many of these roles—information architecture and visual standards in particular—revolved around whether the role should be filled by one person, a whole team, a designate from within the UI team and visual team respectively, or just be identified and assign someone to the role on a project-by-project basis.

With models in hand, I was able to have meaningful discussions with my boss around the future of the organization, and work with him on a plan for growth as well as how to shuffle current staff around to bring the idea to life. We settled on Model 3 as our long-term goal. We chose this model for a couple of reasons—the clear delineation of product design from publishing design offered easy management of the responsibilities across two geographic locations (publishing design was in one area, product in another) and well-articulated horizontal roles could be managed separately and staffed with one person to start and expanded as necessary. This model expressed, for us, the need to have these horizontal roles recognized and utilized by all the different design groups.

With the support and approval of my boss, we had plans to divide the product team from the publishing team and to identify and carve out clear roles around UI and visual design related to the different design types (product, publishing). Our intent also was to beef up the research team, which at the time was approximately 1 researcher to 4 designers. Our goal was to get it closer to 1 to 2 or even, if we were lucky, up to a 1-to-1 ratio. Of course, the head of our research group was very excited about this plan and offered a lot of thought about how and when to grow her team.

We discussed starting with one or two producers and growing the team as needed, and hiring a writer, as well as converting one of the UI designers into an information architect and a visual designer into the keeper of visual standards for the whole organization. I felt that these roles and our products would be better served by recognizing one person as the owner, rather than having the role fractured as a subset of an existing designer’s set of responsibilities.

Overall, there would have been two directors over this large organization—a creative director over the design disciplines and a production/implementation director over the support groups.

So how did it all turn out? We got as far as creating a traffic/producer group that was horizontal in nature. We were in the middle of clearly differentiating the publishing design group from the product design group before we were hit with another major corporate reorganization and layoffs, and my whole team was transferred into another division. Ah, the joys of corporate life. Fortunately, the new group already has a strong structural model in place—although it is slightly different than any of these.

Note: These links lead to abstracts of articles published by the Design Management Institute. There is a charge from DMI for full articles.

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 can be reached at .

5 comments

  1. Thanks for sharing this Erin.

    I suspect that organizational issues are the cause of most Design group’s problems with effectiveness and lack of power, especially within large corporations such as AOL Time Warner. I hope your article spurs more discussion of these issues in our community.

    I was surprised that you didn’t mention discussing the re-organization with the designers who were to be affected by the changes. As a user-centered designer, I expected that sort of inquiry to be part of your research. Perhaps you’d be willing to discuss this?

    Thanks again for the article. Cheers!

  2. Thanks Brad. You make a good point. These models were developed with a lot of discussion across the various groups. I spent considerable time discussing options with the head of the user research team, with the art director, with the brand design lead as well as the head of the support organization. I didn’t speak too much about this in the article, but it definitely was circulated and iterated several times with feedback from the various groups that would then have to work and thrive within this structure.

    It was through these discussions that we decided to elevate and recognize as separate roles, the roles of information architect and visual standards.

  3. Creative Organization? Sounds similar to the Fifth Discipline. Have you ever read anything by Peter Senge?

    For a start:
    http://www.infed.org/thinkers/senge.htm

    (disclaimer: I am not in any way shape or form associated with anyone at the abovementioned website, or with Mr. Senge or any of his associates. I just think he has some really interesting theories.)

  4. Just one thing to add to an otherwise great piece. Can we please all stop calling ourselves the “creative” ones? Once you’ve been in a small, diverse company that has to make ends (and the books) meet, innovate processes and solutions, and generally rely on everyone to be bright, you figure-out pretty quickly that we have hardly cornered the market on creativity. It’s pretty damned selfish of us, not to mention inaccurte. We are no more creative than anyone else better be in a company, including engineers, producers, managers, adn the most creative of all (at least in our case, the controller–read “accountant”).

    Furthermore, it’s a box we allow ourselves to be put into and constrained by. The marketing and business folks refer to us as the “creative” people because that way they don’t have to understand what we do, we don’t have to explain it, and they can conveniently write us off in terms of participating on any level in the company beyond “wacky” and “intuitive.” Believe me, it’s a boss. If you want the CEO to listen to your needs and follow your advise, you won’t get anywhere trading on your purple hair and your fashionable clothes. You better be articulating your value in terms he or she is understanding.

    At vivid we named our group very early (1993-ish) the Experience Group because that’s the part of the development needs we were most responsible for. It didn’t prevent engineers or other developers from playing with us nor did it box us in by being too vague, too flaky or too presumptuous.

  5. I do agree that we are hardly the only creative ones in any organization – but at my company we are called the “creative studio” and our role envelops everything from ui to ia to interaction to graphic to brand to programming DESIGN. Our primary role is to be creative. That’s not to say that we also don’t contribute to defining products and strategy or to say that our Product Manager’s aren’t creative and don’t have good ideas. I do not believe that just because we are called that, that we are relegated to creating fluff or decoration. In my experience, through much education and having champions at the executive level, we are equal partner’s at the table along with the Product Manager and the Technical folks.

Comments are closed.