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 differenceto 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:
- 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).
- Asking friends and colleagues for advice yielded as many variations of organizations as the number of people I asked.
With external research in handwhich ended up being interesting, but not really helpfulI began to look at the details of the situation I was currently faced with.
- The group is an internal groupwe live within a large corporation.
- 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.
- The design group is responsible for content designchannels of partner content, and product designdownloaded clients and applications as well as web-based applications where the focus is primarily interaction design.
- The design group was also responsible for several brands, brand style guides, some writing, and various other side functions.
- 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.
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 strategythe 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.
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.
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.
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 rolesinformation architecture and visual standards in particularrevolved 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 reasonsthe 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 organizationa 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 placealthough it is slightly different than any of these.