Chapter 3. Creating Your Team
Coming together is a beginning; keeping together is progress; working together is success.
Henry Ford
A First Day Experience
Because it was a fairly new organization, when I was hired at Ameritech things were not as well organized as when I started at Bell Labs. The vice president who had made the offer had a few of his other managers already on board and they in turn had just started hiring. The overall organization, however, was still small. My acceptance letter gave me a day to show up and an address, but not a time. It turns out on that day they were being moved from one building to a small remote building serving as a temporary facility until the new corporate location was completed. Without any guidance I figured 8:00 was a good time to show up. When I arrived all the doors were locked with security interfaces. There was no lobby or receptionist that I could find. I wandered around until I noticed movers arrive, and as they started rolling equipment into the building I crept in behind them. There was something telling about needing to sneak into your first day of work. Once inside the building I checked out the largely empty halls with that fresh paint smell, paper on the floors, and movers moving boxes, tables, and chairs around. Eventually someone asked “Can I help you?” I responded with something like, “This is my first day of work. I probably need to talk to someone and find a place to sit.” They took me, as I recall, to Jim Bradley, a Senior Director who was going to be one of my peers. He in turn introduced me to a few people, connected me up briefly with my boss, Joel Engel, and found the sheet that listed where my office was going to be. He led me to the office, and someone pointed out that I could have a plant if I wanted it. It sounded great, so in the big office with the windows looking out on the hall, there was a desk, a chair, and a bushy plant. There was no computer at that point. There was no UX team. There was nothing to do. There nothing to read. So I remember leaning back in the chair, looking off into the future, and asking myself “Now what?”
I have been an individual contributor and made a manager over people who a moment before were peers. I have been hired to start something new, as at Ameritech, or at my most recent job within Microsoft IT. I have been hired to take teams that had a vacancy for a manager, and teams in some cases that had acting managers who probably felt like they should get the job. I have had a team and absorbed another team and had to organize them into something new. I know of people who were managing engineers and were suddenly told that they were now going to have UX people reporting to them. Early on in each of these cases there is virtually always a “Now what?” moment.
It would be nice to say that the first thing to do is to create a vision and define a strategy. When you are new to a team, practically speaking, the first steps are often more basic. Make friends with the administrative assistant(s). It is amazing how important they are both in removing the on-boarding friction and facilitating innovative solutions to projects that will later be undertaken and problems that will be faced. They can help find out how to get a computer and get set up, they can introduce you to everyone within the organization, they can get you furniture, and they help you get the stuff you need to do everything else. Time and again lab space I have found or design studios I have created happened because I had a sympathetic administrative assistant helping me. They knew someone who knew the space planner and could put in a good word. Administrative assistants can also get you time on a busy boss’ calendar. Making friends with the administrative assistant(s) is clearly a key place to start. Being polite, being profusely thankful, and finding ways to connect personally with the administrators are some of those soft skills that should be explicitly developed, but, unfortunately, are rarely covered in management training.
Once you have a place to sit, a phone, and a computer, the next step is to understand the players and the rules of the game. In Chapter 8 there will be a discussion about how consultants work their way into companies. This involves finding a coach who can tell you who the influencers are and who the deciders are, and what the known problems are that need solving. Getting started in a job is similar to getting started on a new project. Find out who is doing what and why. Get to know your existing team, clients, and peers. Understand what each person on your team is doing, their existing commitments and their blockers, and what they are proud of and the things that excite them. Mine their wisdom and insights about where things should be heading and why. Leverage your team and those in the organization to build out an annotated organization chart around the work your team will be supporting, annotating both the formal roles and responsibilities but also including the sensitivities, goals, personalities, and any other information you can get about the people with whom you will be working. Immerse yourself in the systems and processes that shape the context of the work, which may include going through the same formal training that the users go through. This most likely involves getting demos and quizzing people on the users and the scenarios. You will be spending a lot of time in your office (perhaps with your plant) reading Web sites and other documentation about the area. New executives often call these listening tours. They provide needed information, buy time to formulate a point of view and hold off those demanding a still unformed opinion, and begin the process of enrolling the existing stakeholders as people realize their voices will be heard as you shape your opinion. If they are part of the process they are more likely to follow the direction you provide.
Look for the big problems that need to be solved, and the strategic goals of the organization and how they are being approached. Figure out the rules of how the game is played in your organization. This part of the process will be discussed later in Chapter 8 in the section on ROI and involves identifying the needs and desires that your work will be positioned to deliver. This search is also a chance to educate the organization about your point of view, what you feel user experience is about, and how it should work within the organization. When you are the first UX person in an organization that has not employed this discipline before, you are in a great position to define how people should think about UX. Once people start to form their own opinions based on what they observe and their experience, those opinions are hard to change; so use the opportunity wisely. Think about your message ahead of time and stick with it through the process.
Sizing the Team
The basic unit is [a group] which varies from three to twelve or fifteen in number, and perhaps optimizes somewhere around ten; that this group is bound together by a common objective, and that the bond of trust and loyalty thus formed can become an extremely powerful uniting force; that the group needs to decide on (or at least take part in deciding on) its own objective, and to work out for itself how that objective shall be achieved …
Antony Jay
One of the most frequent questions asked by new managers is “How big should a UX team be?” It usually arises around the annual funding process and is especially relevant once you have gotten past that first flush of excitement from having anyone to manage. It may even have come up in the course of interviewing. Experienced senior managers bringing in a manager to start a new program often ask about the person’s vision for the organization during the interview process.
As you lay out a strategy it can also be helpful to have an idea of what the end goal might be like. It can help you as you explore where the team might fit and the mix of skills you want to hire for the team. While some hiring is opportunistic (e.g., discovering your boss has five vacancies that have not been distributed and then going after them), often it is because you have built up a case over time for a particular need and then seize the moment during the funding process to make the case to act on the need that everyone has already accepted is there.
When you estimate the staffing for a project begin by defining what needs to be done (e.g., the number of screens to be designed, the number of usability studies to be run and at what size) and estimate what it will take to deliver. When you extend this to a team providing support across projects, look at the size of the team over time and what you have been able to do (if you have a history to draw on), and try to get a sense of how needs and resources will change over time. Look at the variability in demand as you will want to provide stability for your full-time staff, and probably supplement with contractors and vendors to respond to spikes or dips in demand. The challenge with this bottom-up approach is that you may end up barely having enough resources to respond to the immediate demand. It can be hard to drive the kind of strategic activity that returns the biggest value over time unless you are able to fund and staff it directly as a project. An alternative method is the top-down approach.
In the 1990s I did two small studies to see if there was a relationship between the size of a corporation and the number of human factors employees within the company (Lund, 1994b). The rationale was that companies that have had human factors departments for a period of time would have grown teams to the level where they were getting enough business value to justify the size of the team, and that further investment would be outweighed by other places where the company might invest. The curve interestingly was a positively accelerating curve, which suggested that very large companies could justify a much larger percentage of their budgets for human factors projects. In these very large companies it was found that once human factors groups were created to support enough of the most critical products, they were able to justify human factors efforts that were more strategic, more research oriented, and/or focused more on common requirements and best practices. There was also a suggestion in the data and reviews of these companies that a department of around 18 (typically about three groups) was one level of critical mass. Overall, however, investment in human factors represented well under 1% of the overall corporate size of the companies studied at the time. I have attempted to model how investing in user experience resources for the most important projects (where full support provides the most value) interacts with investing in activities that benefit all projects. What I find is that while the curves vary based on the set of projects considered, there is typically a trade-off where the greatest overall value comes from supporting a few key projects. Then as your team grows, there is more value in investing in more cross-projects, more strategic activity.
A more recent study of 40 clients by Usability by Design in 2002 found that the average development budget spent on usability-related activities was only about 2.2%. Nielsen (1994) reported some evidence that the proportion of budgets going to design and usability is growing. He noted that in 1971 Shackel estimated that the budget for non-military systems for usability work was about 3%. By 1989 he noted that Wasserman found that several companies were budgeting about 4 to 6% of their research and development staff for design and usability work. Nielsen also reported that in 1993 his survey of 31 development projects revealed that the median share of their budgets devoted to usability work was about 6%.
Much has changed since those studies; most notably, the growth of the Internet as well as the explosion of consumer electronics in general. This has placed a premium on effective user experiences for corporate success. Another approach, therefore, is to focus on the percentage of the corporate budget that should be invested in user experience work. Nielsen in his January 22, 2008, Alertbox (Nielsen, 2008) stated “… the share of project resources allocated to usability has held steady at around 10% in those enlightened companies that include usability in their design lifecycle.” This 10% figure has floated around the discipline for years as a common rule of thumb. In Nielsen’s Alertbox he discussed the business benefit that comes from such an investment.
Another way to look at the problem is to look at staffing ratios. These vary depending on the nature of the work in an organization. In a UX-intensive area that is more consumer oriented or that represents a new product, more designers and researchers are likely to be needed than in an area where incremental improvements are made to systems that are improved release after release and the users are already reasonably well understood. In some of the system software areas a ratio of 1 UX person to 10 developers or 1 UX person to 3 or 4 feature owners (project managers) is fairly common. UX people tend to work closely with developers on software teams as designs are shaped and implemented, but often it is the feature owners that drive the demand for UX support. For projects that are more design intensive such as consumer products, the ratios might be more like 1 UX person for 1 or 2 project managers and 1 UX person to 4 or 5 developers. In these ratios the UX people we are focusing on are assumed to be in the design (e.g., interaction or visual design, graphic design, and information architecture) and research (e.g., usability and ethnography) disciplines.
In companies where there are also user assistance specialists (who design the embedded and other user assistance that brings discoverability expertise to the design process), these teams can be nearly as large as the team of designers and researchers. In the UX team, a good ratio is 1 researcher for every 1 or 2 designers. There may be specialist roles such as UX project managers or producers, developers that specialize in the interface, content managers, and so forth. On many teams, the full-time UX work is often supplemented by contractors brought in as demand for varying skills spikes at different stages of the development process. When added up the user experience budget often does float around the 10% figure that Nielsen reported (with 50 to 75% of it going to the full-time staffing of the design team).
Small, Medium, and Large Teams
Think about sizing more locally. The basic unit of stability I have seen is the group. A group is made up of four or five designers and/or researchers and a UX manager. This group size has several advantages. UX managers can look across the team and ensure reviews are fair, and they can provide senior level coaching. The existence of a manager provides a career goal for some members of the group who might aspire to the UX manager position. A UX manager can serve as the face of the team and, being at least one level up in the hierarchy, can influence across the organization at the management level to advance the UX agenda and be an advocate for the members of the team. Members of a UX team share a similar orientation toward design and commitment to users as well as common approaches to their work. As a result, they enjoy being together, and diverse design and research perspectives help each member of the team produce better work through critiques and collaboration. Having several UX people on a team also gives the manager and the group flexibility when handling the demand for work that might rise or fall over time, and typically gives the manager flexibility to drive initiatives that can provide benefits across projects and releases (e.g., around design guidelines and patterns).
Individual UX people (or two or three people) reporting to a non-UX manager tend to be more unstable (Schwartz & Riley, 1988). The work climate is not as satisfying, and team members often have trouble getting their work valued by those who do not understand it, and they are frequently pressed into non-UX jobs when local engineering needs have to be met (and in performing them they may not be as effective as others within the organization and that puts them at a career disadvantage). Many have noticed a cycle where a champion may start building a UX team. As several people are hired and a group forms, more and more teams around the hiring organization see value and come for services. As the demand for services grows, stakeholders outside the funding organization start to get frustrated when their issues are not always the highest priority and they may pressure management to distribute the team. If the team is broken up and distributed some individuals will find themselves in fertile ground, have early success, and start to hire (and potentially become leads or managers). Others will find themselves the lone voices in teams who do not understand what they do and will become increasingly frustrated and either leave or move to other disciplines.
I have regularly found when managing individual teams that when I am managing up to five or six people I feel most intimately involved with the work. I also can lead complementary activities personally. Beyond five or six people the balance shifts to being more administrative and distant, and I hear, sadly, more people complaining about not having enough of my time. This is really frustrating since I can understand their needs and see some of what I can do, but the administration and the meetings to support them just take too much time. As the team gets up around ten direct reports, then the frustration about time can sometimes move from mild to severe. That definitely is not a good situation, and well before that is when I try to set up other structures to help each person feel as much support as possible even if the formal rules of the company do not allow for a new layer of management (e.g., because of requirements for a specific number of directs). In many engineering organizations an acceptable span of control seems to be larger than for the ideal design team. This may be because of differences in the fundamental nature of design versus engineering work.
The next level of stability I have seen is the department, or group of groups. From earlier research, and in practice, this starts around 16 to 20 people. In general, the more UX people in an organization, the better the climate seems to be for the team. There is a sense that there are more growth opportunities (there are now first level manager positions and a second level manager position). A department typically supports a wider range of experience with a range from senior people to early career people who can be mentored by the senior people. New graduates entering a team face a wide variety of challenges, but when they enter a department there are many more resources available to support them as they rapidly get traction in becoming productive and growing their careers. There are typically more opportunities for internships. Performance reviews with forced curves tend to be fairer. The senior level voice can represent the UX vision at higher levels in the organization and the individual designer or researcher is typically seen as having more clout behind them. A department can often support specialized talents such as a lab manager, technical writers, and accessibility experts. A department can also invest in work that benefits all the projects and that provides benefits across releases. The department usually has the ability to apply for more substantial budgets and can advance particularly innovative programs and efforts (e.g., large user panels or major field studies, or perhaps the creation of a design studio). With its range of talent, the department also is often able to generate more of the “glue” that creates culture within a UX community, a branded Web site, communications vehicles, team events and shared experiences, and so on. Beyond the department, some larger companies have found collecting the departments into a design center can drive design thinking through the entire business.
At the department and design center level of organization there is often some heterogeneity in the structure based on the needs of the organization, span of control and management depth restrictions, seniority, and so on. At several companies with sizable UX communities, a given UX middle manager or executive might have groups of various sizes focused on specific projects or functions (e.g., prototyping and branding), senior individuals, specialists (e.g., accessibility), administrative support, and others reporting to them. The larger the organizational unit the richer the view of how to best deliver the corporate goals through exceptional user experiences can be reflected in the skills available and how they are structured.
Defining the Mix of Skills
Jon Innes (2007) of Intuit wrote an article titled “Defining the User Experience Function: Innovation through Organizational Design.” He points out that most experts in our field recognize that to create great experiences and products requires highly collaborative multidisciplinary teams. He cites a quote from IDEO’s Tom Kelly (2005) stating that “… you don’t need every person on every project, and certainly not at every moment … you seldom need all the tools at once, but the perfect kit of tools is a set where you use all of them pretty frequently.” One of the tools Innes provides to the manager is the use of a spider diagram to articulate the mix of skills you are trying to assemble. He lists six dimensions or skill types that can be thought of as candidates for an effective team. In his diagram he includes field studies, interaction design, usability testing, concept prototyping, information architecture, and what I suspect was intended to be visual design. For other application domains, it is easy to imagine variations in the set of candidates. His diagram shows levels for each, presumably representing the needs of the organization. He uses the metaphor of the nervous system to capture the notion of how skills work together and how they can be trained to grow stronger and better satisfy the needs of the organization. He cites several sources suggesting that the role of the leader of the UX team is like a movie director, casting the right actors and getting them to work together to produce great experiences.
I agree with Innes. I have found that each time I have an opening, the person I am looking for is heavily influenced by the mix of skills, passions, and experiences I already have on the team. When a person moves on and leaves a vacancy, I often do not fill the vacancy with a person exactly like the one who left; instead I look for how I can advance the overall quality of the team. It is a little like playing cards, where at each point in the game you are trying to improve your hand. Some of the skills you may be looking for are illustrated in Figure 3.1.
 |
| Figure 3.1 Potential team skills. |
Jared Spool (2007) noted the tension between managers building teams by recruiting specialists in all the areas they need, and those unable to afford the full range of skills who instead recruit generalists. Generalists, typically, do not have the depth of specialists but they provide more flexibility. Spool also noted that the specialty areas were better at articulating the nuances of their unique areas and engaging specialized processes and tools that the generalists may not have in their toolkit. Spool offered an assessment tool that enables managers to walk through various skills area and rate their team’s competency. A variation on Spool’s rating scheme would include a rating of the demand and possibly the importance of the skill to achieve the team’s vision and mission. You could profile your team further in terms of immediate need and long-term need. In this latter situation, a development plan can be provided to help navigate toward the future. Spool said that his firm’s research has identified eight core UX skills: information architecture, user research, visual design, information design, interaction design, fast iteration management, copywriting, and editing. He also noted useful enterprise skills that include development methods, design-to-development documentation, Web analytics, ethnography, social networking, marketing, technology, return on investment (ROI), business knowledge, and domain knowledge.
Anthony Colfelt (2007) took a slightly different approach. He also noted that you are either looking for generalists or specialists. But he said:
Skills are measurable. Anybody can learn new skills through education or apprenticeship. They are the capital built over the course of a career, making the applicant more saleable. … Not to be confused with roles — which define the activities of any member on the team — staff employ skills to do the work.
Colfelt identified several skills including research, information architecture, interaction design, graphic design, and writing skills. To really create a dream team, he also argued that you want to look for the right personality. At most companies I have been at screening for personality would cause the Human Resources (HR) people to go through the roof. What he is really after, I believe, is getting at the skills that enable collaborative behavior. He recommended looking specifically for creative and analytical qualities. He further argued that you should consider the mix of practitioner and managerial qualities; getting at the right mix of T-shaped, bar-shaped, and I-shaped skills. T-shaped people have both breadth and depth, bar-shaped people are generalists who connect the dots to get things done and can move between roles, and I-shaped people have great depth (e.g., the experience architect). You want to find the right mix of strategic versus tactical skills. Pick a team that works in your corporate context, including determining whether you have people best suited for agency type work (he referred to them as outies) or those who want to be embedded with skin in the game and move as the team moves (innies). Colfelt created a summary table a manager can use to assess a potential team member’s ability to fit within your organization (Figure 3.2).
 |
| Figure 3.2 Team attributes relevant to selecting employee skills. From Colfelt (2007). |
Positioning the Team
Every company has two organizational structures: The formal one is written on the charts; the other is the everyday relationship of the men and women in the organization.
Harold S. Geneen (CEO of ITT)
Dan Rosenberg (2007) described a 360-degree view of key dimensions facing UX leaders and influencing how you position your team both organizationally and in its role. There is the importance of working with C-level executives and champions, developing and marketing to peer organizations such as marketing and product management (and Rohn, 2007, would add development), and building and running the UX team. He pointed out that as leaders grow within the company their role and scope grows, and they will work with both internal organizations (e.g., sales and support) that extend beyond their normal development contacts as well as external entities such as government agencies and the press and analyst community. When Ameritech built their ad campaign around the UX team’s work, I found myself on radio shows, on TV, and there was that exciting moment when we were told Oprah Winfrey was going to visit our lab (although unfortunately, national events or some starlet scandal overtook us and we were bumped from her priority list). Rosenberg noted that globalization is increasingly important for many teams. He pointed out that while having a dedicated user experience function is necessary for great products, it is not sufficient. The experience is a shared ownership and requires a combination of functions all with the same level of user-centered design focus and commitment. Design is definitely a team sport.
Rosenberg outlined a variety of questions suggested by his 360-degree model whose answers will influence the way you operate your team. They are clearly important.
• Funding Model
• Do you charge for services or fund with a corporate tax?
• Who determines how prioritization decisions are made?
• Organizational Model
• Do you use a hierarchical or matrix management approach?
• Where is UX placed? Is it in development, quality, documentation, marketing, or elsewhere?
• Corporate Culture
• Are you at the headquarters location or remote?
• Do you design new products or modify existing ones for local markets?
• Is the organization run by a founder or by a committee?
• Who is your boss, and what is their role in the company?
The Need for Champions
At the Human Factors and Ergonomics Society (HFES) conference in 2002, there was a fascinating discussion on how to make human factors efforts more successful. One of the topics discussed was the successful departments in the past (Miller et al., 2002). An important question was why do so many of them rise, shine, and then disappear? It is instructive to look through the accounts of great departments described in Michael Wiklund’s (1994) book Usability in Practice: How Companies Develop User-Friendly Products. While many of the authors of these articles are playing leadership roles in other companies, the departments they were in at the time often have vanished. As hard as you try, and as important as it is to try to educate and evangelize great user experiences, time and time again in engineering companies the ultimate health of a UX team is often tied to the support or lack thereof at the senior management level. There are some companies that are so large, and where user experience has been around so long, that the ultimate existence of UX in the company is not questioned. Even in these companies, however, the existence of UX within a particular area of the business often has some dependency on a champion. At Ameritech, it was Joel Engel who was the champion, and when he became the CTO his advocacy became even more important. At Sapient the influence of the Chief Experience and Chief Creative Officers (Rick Robinson and Clement Mok) were clearly felt throughout the company and shaped its culture. Within other organizations when there has been a vice president or general manager who shared the vision — even if they did not completely understand it — UX was able to have tremendous impact. When someone with green eye shades and a pocket protector took their place, however, the fortunes of UX quickly changed.
An interesting in-depth interview with Mark Vershel in a 2007 issue of Interactions provided insight into what the champion may be thinking (Desmond, 2007). Vershel was a vice president and general manager for Borland, a company providing products like Turbo Pascal, Borland C++, Quattro Pro, and Paradox (serving both the consumer and developer markets). Desmond’s article talks about how he came to the conviction that UX is important for product success. He was asked whether he had advice for UX professionals working in an organization where UX is new. His response was “The key is that the UI is as important as the functionality, and if that’s not part of the discussion from day one, it’s very hard to make it work.”
Harley Manning, research director for Forrester Research, argued (Schaffer, 2004) “The person at the top of the organization must believe that user experience is important and must require people to follow good practices. Unless that person is committed to this idea, good usability is not going to happen.” One implication is that education of senior management must be a standard part of the job description for a UX manager. Janice Rohn (2007) pointed out that in 2005 there were more than 16,600 C-level management changes in the United States, so it is an ongoing role for the UX manager to develop new sponsors and executive champions. Equipping the champion with success stories and with the impact of the work is important. Helping them succeed (and being seen as helping them succeed) is wise. But it also is important to be thinking of succession and working to find or create champions and sponsors for the future. Change in corporations is the norm. I am a big supporter of encouraging my team to send praises to the management who work effectively with UX. If you can help the “friends of UX” to move up the ladder you are building future support. When you believe that UX brings business benefit, you are doing something that should benefit the business and your users when you help drive rewards for the people who in turn support UX.
Eric Schaffer (2004) suggested that it is important to train the executive champion in the basics of usability. They need to understand and evangelize the specific value of usability throughout the organization and what it means to work user-centered design into the current process of the organization. Not long ago we had just finished sharing our UX strategy with the CIO and he happened to mention that he would like to learn to prototype. I jumped on that invitation and set up a training program for him that opened the door to a series of subsequent meetings on UX-related topics. The champion will need to expect, just as the UX manager does, that there will be resistance within the organization, and that they need to help keep the initiative moving along. In Chapter 9 there will be a list of suggested books that can be used to educate senior management, as well as suggestions of how to approach that education.
At Ameritech in the late 1990s there was approximately a 25% turnover rate among the senior executives every year in several of the business units. A typical scenario that captured the situation was when a new executive was hired he had about three months to figure out what was going on, three months to put a strategy in place, and six months to prove it out. If it did not work, the executive was out. An environment like that meant that Ameritech was hungry for solutions when the executive arrived. If you could show up on the company’s doorstep and explain how UX could be their salvation in a compelling way, the executives could often turn into supporters and advocates who in turn could open doors for UX to have an incredible impact. In one case after such a presentation I was given a standing invitation to participate in the vice president’s staff meetings to represent user experience at the general manager level of that area of the business. In another case, such a presentation resulted in an effort to define and drive design pattern standards across an entire vice presidential level organization.
One ongoing debate is whether there should be a vice president of UX. Those who argue for it seem to feel that a vice president of UX will fix all of our problems and will be able to force the rest of the company (largely engineering based) to “do the right thing.” Doing the right thing is of course doing things the UX way. Those who argue against it make the point that waiting for a champion from above is just giving up personal responsibility to make a difference, and if we keep moving forward eventually one of us will be promoted to that level if we are producing real value. I have to confess my personal bias. Based on what I have seen in companies for which I have worked and in companies where I have seen vice presidential level UX people, a senior officer with a UX background can have a tremendous impact on accelerating the growth of UX and driving a user-centered design culture. When they are absent it is just too easy for UX to be relegated to the niche role of staff augmentation to development and testing (quality). That does not remove the responsibility for those at the working level to continue to take ownership for advancing the UX agenda, but it can amplify the impact of UX people working in the frontline and can materially drive broader UX impact at the strategic level of the business. One of the changes over the last decade has been the explosion in the number of vice president of UX positions opening up across the industry. The opportunity to influence from the executive ranks is unprecedented.
At Sapient there was a Chief Experience Officer (Rick Robinson) and a Chief Creative Officer (Clement Mok). Sapient had largely been a middleware company before E-Lab and Studio Archetype were acquired, and having these important voices at the very top of the company inserted UX language into the corporate strategy discussions. This in turn drove culture change throughout the company. Neither appeared to be inserting themselves in daily decisions at the working level but their voices — and their voices as heard through the voices of the CEOs — made it clear through the company what the values of Sapient were. They clearly brought inspiration to all of us and provided a validation for the work we were doing and the points of view we were expressing.
The most senior level UX people should influence those executives across the business like a vice president of UX might. Some clearly are doing this and are visible at the very highest levels of the company. Even those at a somewhat lower level have many opportunities. I have been fortunate to be on projects where I was part of periodic reviews to the CEO, had a chance to share what the user experience community could and was doing, and have had several one-on-ones with the CIO and CTO talking about the vision for user experience.
At each level of the management chain there are decisions being made that would be made more effective if UX expertise was inserted into the conversation. In other words, there should be UX people at each level of the business from top to bottom bringing a UX perspective to the table. At each level of the management chain the skills needed are going to be different. It may also be that very few UX people are prepared yet to speak the language of higher level executives and with the appropriate business authority, to do it with a rich background of UX experience and insight, and to swear and yell with the best of them that this is where UX should be. It will be interesting to see how the field evolves, however, as more and more people grow to these higher levels, and whether academic programs begin to form hybrids between human-computer interaction (HCI) and other departments, and business schools grow these kinds of senior level people. When there is a specialist MBA for executive level UX people at the University of Chicago, Harvard, or Northwestern Business Schools, a milestone will have been reached.
Distribute the Team or Centralize It
One continuing debate is whether to centralize UX or to distribute it. At one extreme is the single UX department that supports the company or a major product area. At the other extreme are individuals embedded in the teams they support. Most UX people want to be in a centralized team. We have discussed many of the advantages of a centralized group. A few professionals prefer to be the lone UX fish in an engineering pond, because they can define their own ideal role and are rewarded for it, or because they are in a position to grow their own team in the future. In practice, as noted previously, in large companies or large organizations there is a pendulum that tends to swing over time driven by the fact that there are advantages for each. Furthermore, in many large companies there will be variations along the pendulum’s swing in organizations across a given company. From a corporate perspective, the pros and cons are probably more evenly weighted resulting in the pendulum.
Rosson and Carroll (2002) noted that integrating usability professionals into project teams increases the likelihood that the questions that need to be raised are raised at the right time, and that the issues are dealt with directly during the development life cycle. The usability people have skin in the game and are immersed in the domain of the problems. They can both see issues that might not otherwise be noticed and recommend solutions that are more likely to make a difference. On the other hand, there usually are not enough usability people for every project and when they are focused on the local priorities they often miss the issues that cross project silos.
My current organization is a concrete example of whether to centralize or distribute UX. After the recent changes in the organization, there are seven designers, one researcher, and one product planner (similar to a market researcher, and coordinating across business groups). The team is responsible for Microsoft.com design work, including sites for Microsoft’s partners and small and mid-sized customers (among other projects). There is also a sibling team of designers and researchers in the organization that supports HR applications, applications for legal and finance, and similar internally focused applications that sit under a different general manager. Both are under the same vice president. A third general manager under the vice president has a single UX person, and there are a few other individual UX people scattered under other vice presidents in the IT organization. The general managers under the vice president are naturally quite competitive, and for much of the time over the last few years have each wanted their own UX people as part of their teams’ core competencies.
The manager of the other UX team and I have talked about combining so we can have the advantages of a centralized team, and we have talked about where it would then make sense to position us as a team. The general managers each have enough work and funding for their own teams. One result, however, is that each team is driven by local priorities and does not have the support to work on larger IT priorities where UX might have a larger impact. It is unlikely that either general manager will agree to let the other control the UX resources that support their own team. One general manager remembers being supported by a centralized team and he feels it did not work. He argues that because of the problems it was broken up and distributed, and he remembers that as the preferred model. Interestingly, the distributed model has not been working in his old organization and so now they are centralizing again.
One option is to combine the teams and have the centralized team report to a general manager who owns common process and tools efforts for Engineering and IT. Another option is to report into the CTO under the CIO. That would place UX very high in the organization and link it more tightly to where many of the strategic decisions are being made. Another option is to report to someone who has major projects (e.g., quality, the intranet, etc.) that benefit all of IT. Still another is to move it to an organization that works much earlier in the development process, at the point where early envisioning and user research takes place and requirements are written. Complicating the discussions are a wave of reorganizations taking place that are designed to provide more engineering focus on key problem areas.
Janice Rohn (2007) argued for the centralized model as well, arguing that “centralized UX teams produce higher-quality work more efficiently and attract and retain top talent.” The reasons she made this argument include the ability to support a broader range of priorities across the business: improved training and support; better development and career growth; and superior quality, consistency, and efficiency. She also cited other sources supporting centralization as a best practice such as Bodine (2006) and Rosenbaum, Rohn, and Humburg (2000).
Figure 3.3 illustrates the dimension of centralization versus distribution. The key value in distributing UX is driving impact by focusing individuals and small groups on the priorities of the teams in which they sit. They own the problems with which they are tasked and impact through that ownership. The key value of centralizing is that when massing the UX resources you can address priorities for broader areas of the business, apply a richer set of skills and resources to them, and have more impact in part by having more visibility and presence within the larger organization.
 |
| Figure 3.3 Centralizing versus decentralizing. |
Figure 3.3 also illustrates two models of organization — by project or by discipline. When I started at Microsoft the server UX department I was in was organized by discipline (research and design). The disciplines had a great deal of rivalry, and the products we supported did not feel they had their fair share of support. As a result, I restructured the department into multidisciplinary teams focused on individual projects. Part of the goal was to get the benefits of centralization, but also to have the projects receive the equivalent benefits of decentralization.
As a different example I organized my Tablet and notebook computer UX team into a design team, a research team, a content publishing and user assistance team, and a team creating a software development kit (SDK) that helped partner companies create more usable applications consistent with the work my other three teams were doing. This worked because the entire team was supporting a fairly homogenous area, Tablet and mobility. At times members of each of the teams were collaborating on some of the same features and at the same point in the development cycle; at other times each team was driving initiatives either in different areas of the business or different times in the cycle. For example, the research team had a major effort around identifying needs for the next-generation mobile device, while the design team was still focused on fit and finish for the last version of Windows Tablet software. The content publishing team was leading an effort to shift the support paradigm to an online Web site rather than depending so much on help files. Because I had specialists in each area leading each team, they were able to raise the level of excellence for each type of work.
The closest I have been to the distributed product orientation cell in Figure 3.3 is when I was at Sapient. At that time people were hired into disciplines such as information architecture, visual design, content management, and experience modeling. When you were assigned to a project, you would report to a project manager for the duration of the project. To grow skills across projects there were discipline leads, and senior people within each discipline had dotted line oversight for individuals within the discipline. I was responsible for supporting people across projects along the west coast, and participated in projects to grow the information architecture discipline. The lead drove discipline-wide activities (e.g., the creation of best practices and training and ensuring quality control in hiring), but in essence each individual was matrixed both through their discipline and to the projects they supported. A senior person within the discipline conducted career coaching and performance reviews, and the primary performance evaluation came from the project manager to whom the person was reporting.
To get some of the benefits of centralization in a distributed environment there needs to be a person or organization that attempts to create a virtually centralized organization or community. In my current job, for example, one of my roles is UX Community Lead. In large companies I have been in there are leadership teams for the discipline that attempt to build community and to work issues that apply to the virtual organization. Other companies use teams high in the organizational structure to drive common practices. Often these structures operate without authority, however, and compliance requires teams throughout the company to buy into the effort.
Positioning Within the Company
The productivity of a work group seems to depend on how the group members see their own goals in relation to the goals of the organization.
Ken Blanchard
UX teams have been positioned in a variety of places across companies, and are most frequently placed in engineering teams close to where UX work is turned into product (probably since they are taking on design tasks that would otherwise be performed by developers and usability appears to be similar to other quality assurance activities). However, UX teams are also placed earlier in the development process closer to where they can have the biggest impact on what matters to users or higher in the organizational structure where they can influence strategy. At Bell Labs there were UX teams in corporate, in systems engineering, and in development, and as projects moved through their life cycle the experience was handed from team to team. At another company I worked at, we were positioned in a user assistance team (a very large one) supporting several product areas. My current UX team was positioned in an architecture team for a while and then was moved into an organization responsible for “common services” across all of the engineering teams. These services included supporting the software builds and deployment, release management, tools, and the quality initiative.
Another place where you find UX teams is closer to the strategy area, and when positioned there they tend to drive more common guidelines and processes. In the Tablet organization, UX reported to the general manager in a functionally organized team along with the project managers, development, and test; UX was treated as one of the core competencies needed to deliver the operating system. UX may also be positioned in the product management area to shape and drive the vision of the experience downstream through development. The design work for the core project on which my team is working is currently owned by two teams — one is my team and the other is a design team inside corporate marketing and near the team working on branding. Marketing is a common place for UX teams as they work with customers to drive the vision of the experiences that will be developed. When teams are organized by discipline some companies and organizations place design in one part of the organization and usability in another part of the organization with the former treated as a type of development and the latter as a subdiscipline of test.
If you have a choice, being positioned in an organization at the point where the requirements are defined is a good compromise. This might be in marketing or in the systems engineering area. The heart of what UX does is to design and deliver user experiences that people find useful and compelling, but the biggest barrier to that is when the design does not quite make it into what is being built. The more organizationally and physically removed from development the more effort you need to build how you operate to make it feel to like you are part of their team. It is usually a little easier to work across organizational boundaries to partner with the business when generating the requirements. Often the business will see UX as their insider connection to engineering. The key is to build relationships with them, negotiating to get the intent implemented, and collaborating on finding the design alternative that can be built efficiently and effectively and supported. The further away you are from marketing and strategy and with the business itself, the more you have to build similar relationships with that organization to have an impact on the most fundamental aspects of the user experience that impact the business.
Being in the marketing organization or the strategy group has the advantage of placing UX up front where it can shape the vision of what is being built, and where one typically can spend the most time with the users to generate the best insights into what should be built. Often there is a big gulf between that visioning work and what comes out the back end, and many great visions stop at the point where the business requirements get picked up by engineering and turned into what the developers believe they can actually build.
Because UX shares a common commitment to a deep understanding of users with market research and strategy, it turns out that it is often easier to build bridges to those organizations from engineering than it is to build the bridges to engineering from marketing and strategy. Indeed, being in engineering often means UX is viewed as the translator with marketing, and this translation function is an additional value that UX can provide.
Architecture is a powerful place for user experience to be located, because shaping the very structure of the products enables the most effective experiences to be created. Furthermore, architecture gets involved very early in the engineering process. Unfortunately, in many teams architecture may be positioned outside of the heart of the organization so their guidance may not always be followed. Architects often are pretty hard-core engineers and may have trouble reaching across the cultural differences between a design team and an engineering team. In other words, they often do not “get it,” so UX can struggle to have its contributions recognized in such a team if the right people are not running the team.
In a shared services team, the problem is often that the emphasis is clearly on the “services.” Because of this there is a tendency for the group to be treated as icon jockeys or a usability-study-on-demand shop rather than as a team that can provide design leadership. Shared services teams are often viewed as overhead, so the pressures are on cost reduction and service levels. This makes it very hard to grow a program and its impact. The way UX is treated and the fragmentation it forces on the team as it delivers the demands of a wide variety of groups can harm the morale of the team and the design environment itself. It also raises the question in some people’s minds about the value of having a permanent UX team, and whether or not the same results can be achieved by vendors.
Higher or Lower in the Company
Janice Rohn (2007) argued that
The organizational position of UX in the company, both reporting level and department, is one of the most important factors in determining how effective and influential UX will be. This organizational positioning is a truer indicator of how much value the company executives place on user experience than any well-intentioned statements of how important user experience is to the company.
She noted that marketing and development report to higher levels in organizations (e.g., CEO, president, or top executive), and that when UX does not do the same, it suggests UX does not have the same level of influence. She recommends pushing to arrange for UX to report high in the organization. What functions report higher will vary from company to company, but the principle of identifying where the influence points are and aiming for those is a good one.
Recognizing that in many companies UX does not report to a higher-level person, Rohn believes UX should report to the department with the most power (control and influence) in the organization such as marketing or development. She suggested that the quality assurance or technical writing/user assistance teams typically have less influence and should be avoided as a place to position the UX team. In essence, she recommends assessing whether your team is more marketing driven (where detailed requirements come from) or more development driven (with products and features coming from development) and to push for positioning based on whichever is core.
As you look across various companies where the UX team has been placed high in the organizational structure, they do tend to work broadly across the corporation and can get involved in and even generate projects that address corporate strategic needs. On the other hand, many such teams (and this includes architectural teams) often have serious challenges when it comes to being an influential part of frontline teams and having impact on the ground. Contributing to this challenge is that some people at the general manager level and higher do not want to get involved in operational activities; they just want to work at the higher strategic and business levels. This means they will be less likely to attend to the day-to-day challenges the UX team is facing.
Where Should People Sit
Great discoveries and improvements invariably involve the cooperation of many minds. I may be given credit for having blazed the trail but when I look at the subsequent developments I feel the credit is due to others rather than to myself.
Alexander Graham Bell
Yet another person on my SQL team burst in the door with the complaint “They didn’t include us in their morale event! They went to the movies and didn’t include us! Make them include us!” This person was not the first or the last with that concern. Instead of the movie it could have been, “I heard the team had a meeting to discuss the new feature and they didn’t include us!” or “They decided to change direction [having met in the hall] and they didn’t tell us!” or “They won’t let us see their designs. They are keeping them hidden in a server and only showing them at their team meeting, and we aren’t invited!” One perspective on the problem is that UX is not loved enough. When UX works with teams who really see UX as vital to their success, they will invite your people to the morale events, make sure you are not forgotten when the spontaneous meetings are pulled together, and give you access to the key information. It is often true that everyone has limited budgets, and you may not be inviting other teams to your events, or remembering to engage them in every decision you make with your team. The root cause is often simple and pragmatic. The applicable phrase is “out of sight, out of mind.” If your team wants to be there, they need to be there. They need to be reaching out to the teams with whom they are working and getting involved.
One of the questions that comes up time and again is whether the UX team should be physically collocated, or whether the team should be distributed among the teams that are supported. There was a study in the early 1990s at Bellcore that showed the further apart two people are physically the lower their probability of casually meeting. As you separate two people by a hallway, the probability drops about an order of magnitude; by a floor, another order of magnitude; and by a building yet another order of magnitude. That obviously impacts the likelihood that people are going to meet spontaneously, discover things they should get involved in or remember to invite others, share the gossip that serves as the bond that leads to further engagement, and collaborate in other ways.
The argument for embedding with the supported teams is that you want those teams to feel UX is part of their team. You want the UX people to know what is going on and be part of those casual meetings that spring up where decisions are made. You would like project team members to be enrolled in what UX is doing almost in spite of themselves (e.g., because the designs or data are on the walls and in the air). When people see you in the hall they tell you things you might not otherwise learn, as you pass people you overhear things that are relevant, and people see you and a synapse closes and they say things like “Hey, Karen should be in this meeting. I don’t think she was invited. I’d better get her there.” Spontaneous gatherings of people from across disciplines within the team for lunch or coffee build bonds that serve as the foundation for project collaboration.
Designs get put up on the walls so people know design is happening, they get a taste of the process of user research and design by seeing it around them, and the designers and researchers can pull team members in spontaneously for a “Hey, what do you think of this?” session. Furthermore, for various activities such as fit and finish work the designers spend a lot of hours working side by side with the developers. In situations like that, it clearly makes sense to have a base where the UX people can work closely with the people they collaborating with on a daily basis. Your team will be a lot more efficient in this environment.
On the other hand, if your project portfolio is likely to change it will be hard to move people from location to location with those changes. Space typically does not work that way. Each group holds onto their space very tightly in most companies, and it is usually a battle to get more. One of the reasons for bonding closely with the administrative assistants is they often have an inside track in the process of getting space. The only time things really loosen up is when major moves happen and the amount of space is up for negotiation again. So unless your team is dedicated to a small number of projects with a stable set of project managers, developers, and testers, you probably will not be embedded with the supported teams. In that case, you will almost certainly want to be collocated. One compromise is to try to negotiate satellite offices in the area of the supported teams that your team can use when they need to work locally. You will need to find ways to increase and support face-to-face time with the teams you support. This might include inviting them to participate in your morale and training events.
My current team recently was in a situation that represented several of these challenges. As a team, we were located in a small campus of three buildings in Issaquah, WA. Half of my team was in offices in one building and half were in cubicles in another building. The type of space allocated to each person was determined by seniority. There is a big room that contractors are typically placed in, but since the contractors work so closely with my team members the team chose to have the contractors share their offices and cubicles. Most of our business contacts, however, have their offices up in Redmond (about 30 minutes away), and some of my team work with the development organization that sits in a different part of the Redmond campus. We tried, without success, to get a satellite office that my team could use in the midst of the business contacts; but we were only successful in getting a remote office with the development team.
For usability research we were using the shared testing space in Redmond that is primarily used by the product groups. We did manage to work with the administrative assistants to get access to lobby space we turned into a small design studio and a storeroom that we redesigned to create a team space for design and research activities.
After a year and a half in that arrangement it was announced that all of the general managers were going to be shifted like pieces on a game board. The general manager that I work for moved his entire team (including the development organization) to a building in another part of Redmond. As expected, we were then able to work much more closely with that team. On the other hand, most of my team was moved far away from the other development teams they were supporting which remained in Issaquah. I am now trying to get the administrative assistants handling the space to see if they can grab a satellite office for us. I am also trying to keep control of the former storage space room, so in the worst case we can continue to use that as a satellite office. We discovered an unused user research area that technically belongs to another organization, and have arranged to bring the lab back online, turn another area into a participatory design space and team room, and use another part of the testing lab to house our growing set of contractors. Since we have been distributed this way, we have been using instant messaging and teleconferencing heavily to support our team activities, and I supplement with weekly team meetings and periodic all-day mandatory off-sites to support team bonding.
Personally, I have found the benefits of collocation tend to outweigh the benefits of being distributed and embedded in the diverse teams we support. A key to getting your team to the high performance level is physically having them together. UX people typically enjoy and get energized by being together because they share a similar approach to problems and are stimulated by the creativity in others. Being together improves the quality of what each individual designer or researcher does since they get the benefits of ongoing critiques from their colleagues. They also grow their own skills by airing their own points of view and exploring and debating them with others. Designers and researchers solve problems faster when they can pull in colleagues. It is easier to manage as you stay in touch with what each person is doing and move from person to person. You can communicate more consistently across the team and manage the rumor mill more effectively by being in the middle of it. You can create spaces with labs, studios, and getting the design process on the walls that become a brand for the team. You communicate the weight of the UX effort as others come to the area for meetings, which in turn helps increase influence.
Working Remotely
Collaboration is to the networked organization what leadership is to the hierarchical organization, and we are living in a world where the networked organization is replacing the hierarchical organization because it’s more natural, more engaging, and more effective.
Dave Pollard
There are times when at least some of your team may be working remotely. Not long ago I was approached by a member of my team who wanted to explore a telework situation, where at least for one or two days a week he could work at a shared space in another city or work from home. This team member lived far away, the distributed nature of the teams he supported was causing him to travel a lot, and he was concerned about the environment and his own work-life balance. Another person wanted to work extra-long days for four days, and have three days off.
Jean Scholtz organized an excellent panel at CHI in 1997 on telework (Scholtz et al., 1998). The panel had both managers and people working for the managers remotely. Victoria Bellotti was on the panel talking about her research on systems supporting remote colleagues. She distinguished two types of teleworkers: teleporter and telepath. The teleporter is a person who occasionally works from home and takes work home at night or on the weekend. The telepath works more consistently from home or a remote office. She found that teleporters talk about how occasionally getting away enables them to get a lot more done by going heads-down and avoiding meetings and interruptions. I personally recall as a lead disappearing periodically for a day to work on requirements and being able to complete about a week or two’s worth of work in a long day; even now, when work starts to pile up it is clearly a blessing of technology to be able to duck out of the office, squat at a table in the corner of my favorite latte shop up in Snoqualmie, WA, with a gorgeous grande latte (and for very difficult tasks, a homemade shortbread cookie), and just crank out results.
Telepaths on the other hand have particular challenges around driving influence, having their influence be recognized, and getting the kind of low-level information that over time becomes critical to having the greatest influence. Scholtz noted that consistently telepaths want technology to help them gain access to people and to interact as informally as if they were sitting near them. We all know how e-mail is much weaker than face-to-face communication in its ability to carry important emotional cues and information shared through the physical interplay that happens in face-to-face situations.
Jenny DeGroot and I were on the panel as one of the manager and remote worker combinations. Jenny is great, and she came to me at one point and told me that her husband was attending school for a while in another part of the country. I did not want to lose her from the team. She was clearly an excellent member of the team bringing energy, accomplishing wonderful things, and helping advance UX within the projects on which she worked. We had already gone through performance reviews where we had had great conversations about her career and it was exciting to watch her grow in the job and anticipate future successes. On the other hand, time and again I have either been in or heard of the conversation where the significant other is going to move and the person quits to be with them. How can you blame them? When she proposed the possibility of working remotely it opened up an entirely different alternative. As we talked about it, it was clear that many of the people she worked with were already in other states, and so from their perspective her move would be transparent. There was no question that she would be able to be successful in delivering her work.
One of the biggest challenges turned out to be more local, more about how the two of us would work together. I wanted to make sure that I was able to coach her effectively, and that I would be able to give her a fair performance evaluation. We realized we needed to make sure we worked much harder and more explicitly at communicating. The fact that we had been working together helped with our communication. We already knew a lot about each other’s styles. In addition, we needed to make sure that through that communication we were very clear on what was being done, the deliverables that were being created, and the process of creating them (what was going to be done, how it was going as it progressed, and the results). These same conversations are important even when you are surrounded by your team, but there are more incidental opportunities to stay in touch with the work. When someone is remote you have to work at it explicitly.
The most irritating challenges in some ways were the more subtle ones. Jenny captures it well with her comments. Here is an excerpt that contains her feelings while working remotely.
Some colleagues in other work groups had a frustratingly wrong mental model of my situation. Because I was not physically present, they seemed to think I was on a sort of vacation or leave of absence. For example, they behaved as if I had no access to company information or e-mail. When I visited the main office periodically, they would fill me in on old news such as, “Guess what? Our division has been reorganized!” When I returned to the main office full time, I was sometimes asked, “Are you back at work now?” as if I hadn’t been working all along. As a result, I made extra efforts to justify my telework during casual conversations, by mentioning the benefits of working without interruption, or of attending conferences in my area without travel expenses.
When in a telework arrangement formal activities such as status reports are even more efficient than when held face to face because extra effort is usually invested in scheduling and preparation. The informal level of communication that supports creative collaboration and team bonding typically is tied to the existing trust relationship. If a group of people have already bonded as a team, introducing technology may not strengthen the team’s effectiveness, but it usually does not hurt it too badly. The bonding persists despite the insertion of the technology. There is some evidence that face-to-face bonding may be required to refresh the relationship. Again, Jenny noted
A disappointing surprise was that the friendlier a group is, the harder it is to attend its meetings via speaker phone. For example, our weekly Human Factors group meetings are lively and interesting — for those in the meeting room. But via speaker phone they’re frustrating. People talk at the same time, interrupt, crack jokes, rustle cookie bags. The very things that make the meeting fun in person make it difficult to simply hear what people are saying, let alone contribute, over the phone.
When people are separated you have to take extra steps to bring them together. When half my team was moved into another building, with half in offices in one building and the other half in cubicles, we held nearly all our meetings in the building where the people in cubicles were located. We exchanged calendar access so we could easily find each other and find meeting times when everyone could attend. As a team policy we leaned heavily on instant messaging to stay connected electronically. As a manager, management by walking around became even more important.
These issues are pushed to the extreme when working with team members working internationally or working with teams on another continent. All the issues that we have been discussing for remote workers apply, but there are additional issues such as cultural differences, the organizational strategies that have led to the relationship, and practical issues like working across time zones. The organizational strategies are often about having a 24-hour design and development cycle, taking advantage of different cost models in different countries, and taking advantage of unique skill sets and experiences.
Globally Distributed Teams
Many companies are global companies and sell internationally. You want the users of the products to be engaged in the design process, so having a local presence in key international markets helps product quality. Even practically, when I was at Ameritech, one of my team (Bob Schumacher) worked remotely in Europe for a while. Remotely, he had immediate impact of being embedded with the project and there were long-term benefits through the connections he made with the international parts of our business.
A common chronic complaint when managing a team that is spread internationally arises when U.S.-based teams treat remote members as merely staff augmentation and just send them the work on the edges of the project — the work that the people in the home office do not want to do. As a manager, it will be up to you to make sure that the work of your remote employees is as meaningful, challenging, and rewarding as the work the rest of your team is doing. The advice from a recent manager who has worked with many teams on separate continents is that what is important is having clarity in roles and responsibilities as well as deliverables and expectations. There needs to be a crisp and clear decision-making process, and as with other remote work situations you need to maintain frequent communication (he called it “high fidelity, low friction communication”).
The obvious implication is that maintaining regular open communication will take extra effort. That means calls and meetings need to be scheduled early or late in the day (which will be early or late for your remote person as well). As the manager, there may be times when you will need to hold a meeting twice, once for each location. When there is budget, you should periodically travel to the remote location to spend extended time going deep with the remote team members and learning about the context of their work, bonding with them face to face, and catching up on the aspects of projects that do not come out in formal meetings.
When I was at Sapient, to help with the bonding and to smooth transitions as work moved through the development cycle and across locations, the company would bring people from one location to spend an extended time at the starting location before the work transitioned between physical locations. Then when the work did transfer, some of the people who had worked on it at the beginning went with the work and spent time at the remote location to help with the transition.
Another thing to keep in mind is the cultural differences that may impact the remote work situation. Today this diversity needs to be something a good manager is aware of even within their own team when they are collocated. You want diverse teams because they bring extra value and improve the quality of and innovation in your work. Be aware of whether the remote person is comfortable expressing bad news or sharing information that might seem more personal, or desires to be more autonomous or to be more a member of the group.
A quick refresher about some of these considerations is available from a book Kiss, Bow, or Shake Hands (Morrison, Conaway, & Borden, 1994). You will learn plenty by just be being open with your team members and curious about their culture, talking about their wants and needs, and sharing your own. There are also many other resources online or through available books and articles about cultural differences (e.g., Marcus, 2002). Another newer source is a book that has just come out about conducting international research, which also offers insights about the issues that come with managing across cultures (Schumacher, 2009).
Moving Your Team in the Organization
What if you and your team are reporting into Dilbert’s boss, or a jerk, or someone who does not quite get it and probably never will? What if you are positioned in a team that is actually hostile to UX or that does things in a way that will kill UX and clearly will not change, or you are just simply in the wrong place for what you need for success? I have been in each of those situations at various points. I like to think I can work with nearly everyone, and I hate to admit that there is a situation I cannot work through to advance the UX agenda. At times, however, when I think about the cost-benefit trade-off of beating my head against a wall versus taking ownership of a bolder and often riskier move that offers a chance of moving to a positive place, I conclude that the risky move is in fact better than certain failure. That risky move could be to start exploring the possibility of navigating your team to another position in the organization.
When you find yourself in this position, it may be time for what is sometimes known as a career-impacting decision. You hope you are making the right decision for you and the team. One thing is certain in most companies, change is the rule. If you can survive long enough, there is a reasonable chance that your management and perhaps even the organization itself will change. In my latest job, I had 5 managers in 2½ years. That degree of change obviously did not help my career, since career growth in part depends on your reviewer getting to know you, your work, and your impact. It will help if you have in mind where you would like to be when change comes since it is sometimes easier to steer something in the midst of change than when the systems have all settled into place. I have also been in a couple of spots where I felt the position was harming my team and risking future UX impact, and have taken a more aggressive role in altering my team’s destiny.
This navigation is delicate at several levels. You cannot talk to your team about it, because the last thing you can afford is rumors starting to fly and taking the decision of your team’s fate entirely out of your hands. You cannot appear to your boss like you are disloyal, or cause your boss to think you are not giving your all to the organization’s goals (especially if there is a chance that the move will not happen). Indeed, you should be doing your best to simultaneously be as successful for your organization as you can in your current situation, even as you try to navigate to a better one. You might find it useful to find a trusted mentor who can be a sounding board as you develop tactics.
One approach is to talk with the manager you want to work for by trying to create a conversation where he comes up with the thought “Hey, you should report to me!” Another, depending on your current boss’ attitude about the team, is to try to engage the targeted manager in developing strategies for increasing the impact of your team on the overall organization, including at least as a thought exercise thinking through organizational alternatives. Like any sales job, that discussion is about trying to get the boss to realize that some goal they have (perhaps a pain point they want to reduce) will be solved if your team moves to another place. You may need to prepare assurances that the manager will continue to receive services that led him to acquire your team in the first place.
The ultimate step might be to go over the manager’s head and talk to someone higher in the organization about the issues. If there are champions above, you can leverage them. If you are going to take that step, you had better have your arguments together and be reasonably certain of the outcome. There is probably no going back once that step is taken. I have taken this ultimate step, however, and it did result in a move. I did need to put in the extra effort over the next year to try to heal the relationship and the hard feelings persisted in causing irritation for some time (mostly negative comments during public reviews of my team’s work from the former boss, and some payback at performance review time). With time and effort the person became a supporter (at least a mild supporter) as we were able to accomplish things that could not be accomplished if we had stayed where we were.
One final form of escape is personal escape. I had one wise manager tell me (after he was no longer my manager) that I needed to watch out for myself first. He argued that in a new and better place I would inevitably be building a team again and some of my best people would be likely to follow. As I have moved from place to place, I have been fortunate in having some of my best people follow me to new teams. That has been a great help in seeding efforts and rapidly growing to excellence. It is another reason to be absolutely committed as a manager to helping the individuals on your team be the best they can possibly be, and to grow their own careers while they are contributing to your team strategy and to the business goals. In general my moves have been to grow and try something new, or to take a big jump in the impact I can have, but there have been one or two times when it has been at least partially about getting out of a bad situation.
Funding the Team
Estimating Your Needs
There are several ways to determine how much funding will be needed for a project. One approach is the top-down approach described in the section Sizing the Team. Here you are basing the estimate on the expected demand from the project managers and the developers (either by size of total budget, or based on staffing ratios). For example, if you are supporting a team with 10 project managers and 30 developers, and you know it takes 1 designer to support the work of 3 or 4 project managers, you can begin to build a staffing plan. Or you might look at the total budget and know that for projects of the type your organization is supporting it should take 6 to 10% of the budget to support the needed design and user research. Another approach is historical. Here you know how much your team was able to produce last year against a projected set of features and the organizations you supported, and you can size up or down based on changes in the forecast for the upcoming year. Then there is the pragmatic approach where your funding may be reduced for a given project, while the project itself may continue with the same level of need. Again, you can reduce what you can produce appropriately and that will force a conversation with the team on what they will need to pick up, and where you can provide leadership that will enable others to take on more of the design under your team’s direction. This is similar to the analysis described in the engagement model where you provide more or less support (and will do more or less work) based on the business impact of the project and the importance of the user interface to the project.
There are also various bottom-up methods. If you can be clear about what the required activities are then you can put together an estimate of what will be needed to deliver. I cannot tell you how many times I have had people saunter into my office with a “Hey, can you put some designers on my project? I am in a hurry and need screens designed for Monday.” I am always amazed that they think I have a designers and researchers sitting around apparently doing nothing. The size of the project described usually bears no relationship to what it will actually take to do the work, and that is unfortunately due to a lack of understanding of what it takes to create an effective design. A model of the default deliverables through your process and the parameters that impact the effort required to support them can be helpful in putting together a quote for the work.
My team put together a table (see Figure 3.4) that we use to help with the estimation and to set expectations with clients. It shows the major deliverables we produce and the T-shirt sizing for the work. We distinguish new-to-the-world projects from those that focus on major problem areas of an existing application or significant new features, and those from smaller variations on an existing design. We point out that the specific levels of effort will depend on details of the project, that activities can happen in parallel (e.g., you can get an icon reviewed by legal while you are working on other design tasks), and many of the things we do that deliver the greatest value do not lend themselves to being represented in a menu (e.g., participating in a strategic planning task force).
 |
| Figure 3.4 Menu of activities for planning. |
To improve the accuracy of estimates, we are pushing teams toward early rapid, low-fidelity prototyping to rough in a user interface that implements the top priority scenarios and to kick-start user research. For one project, a multidisciplinary team using a rapid prototyping tool was able to convert seven major scenarios into several dozen use cases, then they could wireframe the interaction patterns supporting the use cases in a matter of just a couple of days. They were then able to estimate how many template types would be needed, how many total screens, the number of graphical elements that would be needed, and the key design problems that would take more work. A side benefit is that the prototype became a common language that everyone on the team could use and agree to as a representation of a specific implementation of the scenarios. You need to be careful that this rapid prototype is not the final design, but rather is used as a tool — an initial mound of clay roughed into the general image of the final result — to help in working toward the design. Clearly, it is the designers and researchers who are the key to turning a scoping exercise into a working estimate. They have the best handle on what they can produce and how quickly.
Direct Funding Versus Strategic
In 2007 there was an excellent panel at the ACM SIGCHI conference on incorporating HCI into companies. One of the most interesting parts of the discussion was on how best to fund user experience work. There are basically three approaches: direct funding, shared funding, and a hybrid. The funding might be provided at the beginning of the year and budgeted, or it may be cross-charged in an internal service model (e.g., the expenses for the month are billed back to projects at the end of the month). The recommendation of the CHI session was that the hybrid model made the most sense, and that has been my experience as well.
In direct funding, a project includes the funding for the UX work for the year in its budget and funds it up front. If the UX team is organized within the project team, the UX budget may be treated in the same way as the development, project management, and test budgets. If budgeting is based on feature areas and initiatives within the project, the UX budget may be handled in a similar manner. In either of these cases, your job as manager will be to identify not only the number of people to be covered and the other costs associated with the ongoing UX work (e.g., hardware and software, research costs, etc.), you will also have the opportunity in the process to think about specific initiatives that you want to drive into the budget (e.g., the cost of a major user panel, or an exploratory ethnographic study, or a Web site for providing access to reusable assets).
Another model of direct funding is the cross-charge or chargeback model. In this situation the team is funded much like an internal consulting firm. As work is done the requesting teams are billed for the work. In direct funding, if the UX is not devoted to a single project and embedded there, the UX team is often placed at the highest level that covers the majority of the relevant funding teams, or it is placed in a team that provides support across projects (e.g., a common services team or an architecture team).
In the shared funding model, the UX team is funded like other initiatives within the organization (in essence equivalent to an entire project, and with a similar implicit or explicit business case). Funding is set aside for the team, and the team develops its work program within that budget. Each year appeals for increases in the budget are made based on the major initiatives that are planned. The shared funding model may be implemented as part of a larger funding process where the money is allocated early in the corporate funding process or higher up in the organization, or it may be implemented as a tax on the other programs in the larger organization in which the UX team sits. Shared funding tends to recognize that UX is a core competency and is strategically important for the business. With shared funding, there is often a discussion that UX should be positioned at a place in the organization relatively high up so that the “view” of UX covers a broad area of the organization, often at the executive level. This can have a side benefit of providing a UX voice at the executive levels.
The pros and cons of the two models based on my experience are shown in Figure 3.5. The shared funding model gives the most flexibility in responding to the needs of the organization. It lets you respond quickly to emerging and strategically important needs, to invest in key projects that need UX support, and it lets you initiate projects that are beneficial across projects and during the release of projects. The downside is if teams are taxed and they feel slighted, it can build resentment. In shared funding, people are likely to assume that your services are unlimited and free, so they feel they can walk in and demand those services. The value placed on your services may be lower, since they are likely to walk in for specific needs rather than strategic end-to-end involvement, and people tend to value what they actually pay for and to the extent they pay for it. If they view services as free and if they do not like what you recommend or produce, there is little incentive for them to go ahead and use it. Finally, any shared service in an organization has another word often applied to it besides core competency and that is “overhead.” When budgets get tight, teams not seen as directly integrated into the value engine of the business (and sized based on the value they produce) are among the first to be squeezed.
 |
| Figure 3.5 Types of funding. |
The direct model has the advantage of being need and value driven. When you are providing value, people want more user experience. Under the best circumstances it is almost like they become addicted to the value they receive and are hungry for more. It is a straightforward argument that if a team wants more support, the team should pay for more support and as a result your team will grow. Accountability is clear because the team funding you is defining the priorities and since they are paying for what they get, they are motivated to value and use it. Unfortunately, it also can mean the work gets locally optimized and may not be the most strategic application of UX resources for the overall business. Your team will spend time on the needs of the team but not necessarily on the things that will produce the most value. Since projects go through busy times and slower times, demand may wane and you may not have funding for some of your team (at least in the chargeback model). I also find that other teams can bond to specific people on your team and only want those people. That can restrict your flexibility in making staffing decisions that are smart for the business, and it can make it hard for you to help people develop their careers if their goals are to move into different kinds of work. There is also very little motivation for teams to support cross-project work like reusable assets or standards. If they sense that some of the cycles of “their” people are going into these kinds of things, their pushback may be to suggest that perhaps the people should just be moved directly into their teams.
I have found the hybrid model works the best. If I can get shared funding I can use it for “business development.” It lets me respond to the most critical needs of the larger organization. It also lets me make smart investments if I see a corporately strategic project that does not have UX but should, or when I see an emerging project that is likely to become a more strategic project and that clearly is at the right place in its life cycle to take in user experience. I use the shared funding for some of those common activities that make the team more effective and efficient over time. These activities include standards and best practices, reusable assets, and projects like Web sites to serve the assets to those who will consume them. It was this kind of funding that let us invest in the work on understanding what makes products successful and to develop the USE questionnaire (Lund, 2001) as a way of doing a better job of creating successful products. It also is the kind of funding that lets us support our lab environment and create some of the branding assets that help promote the team and grow direct funding. The shared funding also supports a stable staffing model when direct funding varies.
The growth in the team often comes from direct funding. Projects were first supported by people who had been hired using the shared funding and our initial support might have been in that strategic investment category. The projects we support directly often have their favorite people largely dedicated to them, and as more and more value is provided they begin funding people directly, and as they fund more I hire more. Critical to the success of this model is that they feel the people I have supporting them are virtually on their team. I build into my climate assessments and 360-degree feedback process metrics to ensure we deliver the most value and are collaborating effectively. If at some point I conclude that someone should be on a different project (e.g., because their career aspirations have changed or the project needs are shifting), then I manage it with the team. There can be some resentment, but I have found that they usually come to love the new person just as much as the previous one who had been working on the project.
This can be illustrated with a recent example. When I joined the organization three years ago I came in as an Experience Architect to define and build a UX program that would change the way our customers deal with us through their life cycle of product experiences, and to serve as a UX Community Lead and grow the UX people and teams already present, unite them as a community, and evangelize continuing investment in UX. I reported to the senior general manager of the organization and worked closely with him and with the vice president on developing and implementing a strategy. I was funded directly by the general manager out of his budget. Even before I showed up, one of my previous designers (Pam) from another organization had joined and I suddenly had a team. As I laid out the plan I had in mind, the general manager announced in his staff meeting that he was pulling funding from each of his direct reports to fund the growth of UX within his organization. While I suspect I did not win a lot of friends in that staff meeting, he was receiving clear direction from the VP at the time (a champion) and saw user experience as a core competency that he wanted to build to deliver the vision he had for the larger organization.
I initially focused the team primarily on the general manager’s top priority —developing a relationship experience through the self-service interfaces customers have with us. We were at the incubation and planning stage at this point, and I was also working on the experience architecture needed to support it. To enable these activities, my team was moved to the architecture team (which, as it happened, was also where the incubations were taking place). We became a center of gravity for UX and additional UX people, and those who wanted to work in the UX area were moved into my team. We grew the work plan to support teams who sent their people to us, as well as initiating projects to leverage the skills of the senior people who joined the team (e.g., working on user-centered process innovation). I was also able to invest effort in community building across the IT organization. There were important projects that came through the door that I was able to support (e.g., designing a prototype of a profile center to address regulatory requirements and launching a major international ethnographic study to understand what self-service and relationship meant to small and mid-sized business customers).
By the second year, we were sufficiently successful that funding was doubled. We hired a range of excellent and diverse designers and researchers. We were still funded primarily through the tax. The general manager and I agreed that we should focus on the project priorities within the organization where the UX work would have the greatest impact, and I argued that we wanted to take full ownership of the excellence of the experience. That meant I focused my team to put a critical mass of people on the projects we were working end to end. With that concentration and visibility of work there was a side benefit of opening the doors for direct funding as well for special projects requiring unique skills (e.g., information architecture). We hired contractors and vendors for those projects, and cross-charged the contractors and vendors to the requesting teams. I used managing the contractors and vendors as an opportunity to grow leadership skills within my team. As the rhythm of the projects varied over the course of the year we were able to shift people among the projects as needed. Organizationally we were moved to a team that provided other services across the organization such as release management, various tools, and software build engineering support.
I did get people walking in my door, however, wanting to know where the UX people were that they were paying for with their tax. They were not happy when I explained how the model was working. Others had just heard we had a UX team and wanted to know how they could get help. They also were not always happy with the answer they received. They would often walk in Friday wanting a design delivered by Monday. But the master plan was that with a focus on excellence we would be in a position to harvest best practices and reusable design ideas that could be applied elsewhere to help bring broader benefits. We also started what we called Office Hours. Office Hours were a series of sessions where any team could request support through a member of my team (Sindhia, who was a new graduate from Indiana we had recently hired), and subsets of my team would come together to provide a concentrated design or research critique. Finally, we were actively a part of a larger quality initiative where we would work closely with teams to build user-centeredness (through scenarios) throughout the development process.
Entering the third year we were reorganized yet again. My new boss wanted to deal with the ambiguity that came from the taxing model. He wanted the certainty of people paying for what they get and getting what they pay for. As a result we moved to the direct funding model and more of a service orientation. Each member of my team (with one or two exceptions) was funded by one of the teams under my general manager. This meant that we could not assemble a critical mass of effort for any project. Instead, we had to come up with a way of scaling the impact of the team by more actively educating the project managers, developers, and testers on projects to take on user experience tasks under our design direction and cranking up the efforts to grow the library of reusable design patterns another notch.
In this situation there was clarity, because as new projects came in requesting work we could point to the existing model and say that they had to have funding, and when they did, we would bring on contractors. Our hope was that when we reached the next funding season, we would be able to get a commitment up front from those teams so we could hire more permanent staff. To the extent that funding is a sign of success, at our height during the year we had tripled our funding. It dropped a bit by the end of the year to just doubling the funding with which we began the year. Unfortunately hiring was capped across the entire IT organization and so no new vacancies for full-time employees have appeared.
We keep running across project needs and not having the people to address them (and the teams do not have the flexibility in their budgets to let us hire). Where we have someone with the appropriate skills and where there is funding, we potentially can find a way to move money from one budget into another as we move people around. It does feel a little like a shell game at times, and there is a lot of overhead in keeping track of the budget and managing the hiring of contractors. This arrangement has also restricted our ability to address the biggest issues on the projects that will return the greatest value. Alas I am reasonably confident that when user interface issues arise in the customer feedback, my team will get the blame even when we are not involved in the design of the interface. This is obviously a concern. Still, we are doing what the organization currently is looking for — setting up a system of predictability in the funding process.
Perhaps even worse, the work climate has taken a major hit. People no longer feel like they are part of a team since they are each working on separate projects and often are scattered geographically around the Redmond area. They do not get to interact spontaneously with each other to improve their designs. The contract researchers take the intellectual capital that would otherwise accumulate across projects with them when they move on to other jobs. Teams are motivated to treat even the full time people like contractors and to leave them out of planning meetings, to push the least desirable work to them, and make impossible demands on delivery. This model definitely does not work well from the perspective of building the vision for the team.
We are in the process of again rethinking the approach. I have defined a new charter for the team that will allow the majority of the full-time staff to focus on one shared goal, even as they support individual projects. Nearly everyone on the team will be working on re-envisioning our corporate site and driving that vision across the sub-sites they are supporting. I will be pooling the funding from each and have the general manager’s support of a charter where some of each person’s role will be to drive themes across all the projects (e.g., a common brand framework), and where each person’s top priority will be to drive a scenario-based vision into their projects. I am hiring a vendor who will provide a program management office function to handle the overhead of budget details and management of the temporary staff. Our hope is that the staff augmentation will allow us to grow and shrink as needed. We are also creating a design center where project themes will have team areas, the UX team as a whole will be able to meet, where our research will take place, where participatory design will be supported, and where we will collocate our team offices and cubicles for the contractors. Finally, we have obtained limited but stable shared funding that we intend to grow over time for more generic work whose value will be felt across projects.
An Engagement Model
Put all your eggs in the one basket and watch that basket.
Mark Twain
Given the challenge of both the shared and direct funding models, it has been important to have a standard response that can be used to answer the question: “How can we get UX support?” The place to start is to begin by scoping the business benefit and determining the level of effort needed to achieve the benefit, rather than just estimating the effort needed in the abstract. For any given project, you can provide more support or less, and for any level you have a variety of tools at your fingertips that can be applied given a specific set of constraints. A tool to help in the discussion is shown in Figure 3.6.
 |
| Figure 3.6 Assessing engagement level. |
One dimension in Figure 3.6 is “How strategic is the project for the larger organization?” It is described in more detail in Figure 3.7. In most companies where I have worked, projects are assigned a priority when they first enter the queue as candidates for funding at the senior executive level. A subset of those projects are selected by senior management as among those they will focus on during the year since their potential business impact is considered to be so great. Senior management tracks metrics on them, gets regular reports, and engages to drive progress. The big bet projects end up being in senior managers’ commitments, which in turn ensures that they get the needed focus and support. There are many benefits that come from UX playing a critical role on projects that are in a senior management’s sights as well as being seen as responsible for part of the business value the projects will deliver. At the low end of the dimension might be projects that are internal tools that teams are creating for themselves, and in the middle might be projects that are important for divisions within IT but that do not merit IT-wide attention.
 |
| Figure 3.7 Business importance example. |
Not every project, even strategically important ones, should have UX support. An additional question to ask, therefore, is “How important is the user experience to the success of the project?” This metric is illustrated in Figure 3.8. Projects that have many users or where the users are making decisions that have high business importance are good candidates for a high rating. New–to-the-world user interfaces or projects with major user interface design challenges are candidates for a high rating. Our project to create a business center for millions of small and mid-sized business customers that would leverage the latest social networking technologies fell into this category.
 |
| Figure 3.8 Interface importance example. |
At the low end of the dimension might be incremental improvements in an existing interface or where there are only a handful of users (e.g., administrators). For such incremental improvements, the rest of the user interface becomes a model of how to design an improvement. As an example, another tab might be added or a modification of a menu is needed and a couple of additional content screens need to be designed. In the middle of the dimension might be interface improvements that represent solutions to major user interface problems but without a wholesale redesign of an entire site.
Neither of these judgments is easily automated. The answers to the questions are judgment calls and the power of the tool is in the discussion it provokes. The goal is to have a conversation with the requester and negotiate the right assessment. The negotiation is educational and positions the way you want your work to be positioned in terms of its business value, and the user experience design and research activity required to deliver the value.
Given a position on the table illustrated in Figure 3.6, you can define a recommended level of engagement. For example, projects falling into the A cells might call for full support. Those in the B cells might only need partial support. Those in the C cells might only need consulting support, and those in the D cells might not require UX support at all. Teams owning projects in the D cells might be directed to examples they can copy and guidelines that have been created. The descriptions of these levels of support are listed in Figure 3.9. The original table I used was developed by Tjeerd Hoeck when he was a director of design for one of the Windows releases. I took his table and modified it to fit our IT environment and the approach we were taking to staffing projects. The version shown here is a further adaptation of that revised version.
 |
| Figure 3.9 Levels of engagement. |
Again, every project does not need an all-out UX effort. You want to concentrate the UX resources where the business return justifies them, and to the extent that users benefit. This approach can be at least as important as abstract ROI arguments in demonstrating the value of UX within a company.
The target level of funding of around 6–10% of a project’s budget represents full support in this engagement model. The budget could conceivably be even greater for particularly difficult design projects. At the incomplete level of support the budget is at the 3–6% level; at the consulting level of support it is usually a portion of a single full-time UX person’s time and is then supplemented by consulting. Interestingly, at one point I went through an exercise where I estimated the desirable level of funding based on the appropriate levels of engagement. I was only able to persuade a fraction of the teams to fund our team at the right levels. But when I looked at how much the organization ended up spending over the course of the year on consultants and vendors along with full-time user experience staff, it was very close to the estimated need from the top-down analysis using this view of creating a portfolio of projects across the engagement levels.
One of the things I do argue for when I negotiate with teams, however, is the expectation that when planning work they should be planning for about 80% of an individual UX person’s time, not for 100%. The 20% is needed for activities that keep a vibrant UX team going and for administrative tasks. It provides capacity for turning their work into reusable assets that benefit everyone. I have found that the managers I work with are comfortable with this as long as they feel they will get some of that benefit. If others also benefit, that is okay too. When they feel like they are paying for someone else to reap all the benefits in a direct funding model, managers get a little touchy. One example is a CSS framework, built by one of my designers with a development background, which made it easy to create design patterns, to assemble them, and to give them a brand identity. The sponsor was willing to share the work as long as his team was directly benefitting. This type of sharing model means that each team is also sharing in the assets created by the rest of my team, and it can be leveraged to make teams feel the support they are getting is beyond expectations.
Edmond W. Israelski, PhD
Director of Human Factors Abbott Labs, Abbott Park, IL, USA
Where should teams be positioned within the company? This question is common and the answer is not always simple. I personally have managed Human Factors groups in Systems Engineering, Software Development Engineering, Product Management (Marketing), and Quality/Regulatory. HFE groups might also find homes in Medical Affairs, Training, Documentation, System Test, Market Research, Manufacturing Operations, Safety, Occupational Health, and Industrial Hygiene among others. The guiding principle is that it should be where design decisions are made in order to have maximum influence on the usability of products and systems. Being in an organization that is considered a “consulting” organization is not optimal for having impact on design. You may not be taken seriously, or worse, be marginalized.
Another consideration is the mission of the HFE group. If the group is new and is trying to establish its presence with a beachhead, then being in a corporate organization is more influential in getting various divisions to incorporate HFE. But, ultimately, HFE needs to be near the product/system/process design action. If the starter group is in a corporate oversight organization that looks out across the entire corporation, then it would be better to dedicate group members to specific full- or part-time product or project teams depending on the intensity of the HFE efforts. This way the design teams feel that the HFE professional is a true valued and trusted stakeholder member of the team, rather than a remote or disinterested consultant. Being physically collocated with the design team is ideal to foster formal and informal (lunch, hallway) communications.
A related question is, “Should the HFE group be centralized or decentralized?” The answer depends on the many factors including:
• Company organizing philosophy
• Product line diversity
• Geographic diversity
Some companies embrace a great deal of autonomy among their diverse divisions and frown upon micro-managing from a top-level corporate headquarters organization. I work for such a company and it is clear that top management values placement of profit and loss responsibility directly with each division. In this case, HFE expertise needs to be decentralized and follow this philosophy. A small corporate presence — for example, a two- to three-person HFE group — can foster consistency in approaches and methods of HFE, but the final design and product decisions are made in each independent division. There are also many successful multinational companies that have large centralized corporate groups with a great deal of control over product development and corporate governance. This control, it is argued, allows for efficiencies and economies of scale, as well as promoting consistency and the company brand and values across the entire corporation. The more diverse the product line, the more difficult it is to have a highly centralized organization, but there are notable exceptions such as the GE Corporation. The centralized philosophy has many positives, but unless executed properly, divisions within a company may be resentful of overbearing corporate headquarters control. Unfortunately, this resentment could apply to a large corporate HFE group. It is not uncommon for the philosophy of centralization versus decentralization to shift like the proverbial pendulum, usually as a result of executive changes and the need for the new leaders to make changes, sometimes just for the sake of change. Geographic diversity is almost the norm today, and modern communication tools, such as Web collaboration, video/audio teleconferencing, e-mail, and instant messaging all shrink the distances and allow geographically dispersed teams to work well. The idyllic arrangement of all team members working together under the same roof is harder to achieve. Some companies start off this way, but over time with mergers and acquisitions, these close-working arrangements are harder to maintain. HFE team members also have a higher chance of being accepted as full team members when they are collocated with the main design team decision makers in large part due to the informal, unscheduled communication opportunities.
The following table shows some of the trade-offs and considerations for organizational placement of an HFE group.
Natalia Kirillova
Managing Partner, Business Development Director, UIDesign Group, Moscow, Russia
1. Why work remotely: Contexts and dimensions of remote work
Although being a fan of live communication, I believe that remote projects have a bright future. I am experienced in being hired remotely; I meet my international business partners remotely; and remotely, as well, I manage many international projects; living in a huge city I often work remotely staying at home. Virtual teams and distant projects have become a part of my life.
Generally, remote projects are launched to obtain some particular or unique resources or experiences unavailable within the same area, or just to save time and avoid the expenses on traveling. As for the scale of remote work, it could be organized on different levels — city, country, and world. In fact, the scale does not really matter until right management and technology allow establishing effective communication. Today, when globalization is so extensive, it is becoming quite easy to have project teams distributed around the world: UX consultants in the United States, developers in Bangalore, and visual designers somewhere in Europe. International user research is another example of working remotely. The study has to be done in several countries locally and sometimes simultaneously, but the final result should be consolidated — E-mails, phone calls, webinars, remote meetings with shared screen and audio, Web conferences providing full interaction, and so forth — and all these help to bring the results together and to ensure the success of the project. Remotely organized projects are particularly noticeable on the country scale, especially if the country is as large and diverse as Russia, where it takes more than six days to travel from east to west by train.
Thanks to the fact that technologies are trying to catch up with business needs, we can use remote tools for quite a wide range of tasks — varying from synchronous meetings and communication (remote presentations and conferences) to remote collaboration that can be organized in different time zones or asynchronous meetings (while managing distributed projects and organizations).
My company is located in Moscow, but we have partners and customers not only in different regions of Russia, but on most continents — North and South America, Europe, Asia, Australia and New Zealand. Year after year we have more and more remote projects, so three years ago we started to hold annual online conferences sharing knowledge and experience with people all over the word. These kinds of projects inspire me and make me feel as if there are no limits and borders existing in the world.
All these sound good, unless you get down to the process itself …
2. Remote versus face-to-face
I always persuade the UX consultants in my firm that it is better to send results by e-mail and then to call the customer to discuss rather than just to send an e-mail, and it is always better to have a face-to-face meeting rather than to present results remotely.
The advantages of remote work are quite obvious; time, budget, efforts, and resource expenses can be reasonably lowered. However, these advantages begin to fade when you start to think about how to organize remote work effectively: you have to take into account time gaps, the difference of languages and cultures, the necessity to establish trust, the ability to put together different teams, and to control and manage collaboration skillfully. All these issues look challenging enough. Some even find remote work risky and not always applicable.
Management is the most important and vulnerable issue of remote projects. By management here I mean organization of communication and collaboration, as well as coordination of the remote work. Even a professional who performs high-quality work can fail to achieve success in the end if he or she cannot manage a remote project.
Technology helps to manage, but still has some limitations. It cannot fully replace personal communication yet; the broadcast quality is not perfect due to bandwidth. Although there are plenty of tools that support both synchronous and asynchronous remote work, still there is a lack of live presence and some information gets lost.
3. Secrets of success when working remotely
The secrets of success are not really secrets; each of them is the part of the hard work that has to be done thoroughly and on a regular basis. Here are some high-level tips that can help to set up remote work.
Responsiveness
When starting to work with a new remote partner, the first thing assessed is your responsiveness. A good manager knows when to react — sometimes an immediate response is required, sometimes it is enough to answer once a day, and so forth. Anyway, a quick response is very much appreciated. It shows not only that the manager cares about the project and respects a partner, but it also saves time and effort.
Right start
It is highly recommended to make all important agreements on land before you go to sea. It is also important that all sailors know where the ship is going and what everyone has to do.
It is essential to start a project the right way: to organize a kick-off meeting or briefing with all the parties involved to establish terminology, roles, and expectations. A virtual meeting should be accompanied by documentation in a written form provided in advance. A meeting report is to be sent out afterward to all parties.
It is always useful to find out the contacts of each remote party’s responsible person so they can be available not only online but also by phone and through other channels in case of an emergency. It is also good to know who the decision makers are. This information should be collected before the project starts.
Building trust
Trust is an issue without which it is impossible to have a successful project. When the parties do not trust each other or have considerable doubts about each other’s professionalism or other issues, it is better not to start the project at all. Otherwise, one party will spend a lot of time on inspecting, and the other one will spend a lot of efforts on double reporting instead of working.
To avoid this situation, it is good to have a preliminary live meeting (if possible), a conference call, or conversation with the decision makers in order to get to know each other. Also, it is good to probe a new partner in a small project before starting a big one.
Making use of different communication channels
Another issue is related to perception. We perceive information via three channels: visual (60%), audio (30%), and semantic (10%). When we share information via e-mail or any other sharing tool, it is perceived only via semantic channel which is usually not sufficient.
That is why it is wise to duplicate orally at least some data that have been shared in written form, and to provide visual support for audio information. Distant communication is less vivid than live, so we have to be more careful with jokes, avoid using slang, and so forth. It is also more difficult to jump from one topic to another, therefore it is recommended to discuss issues and summarize after each of them.
Choosing remote tools
The choice of tool is not so important. Although a convenient tool can save time, it cannot improve or compensate for poor management. However, a good combination of remote tools can help to create a convenient project space. For example, instant messaging may boost the feeling of presence for project participants in case of synchronous collaboration.
Finding the right balance between remote and face-to-face communication
If you have a chance to meet with your remote party then do it! Sometimes just 15 minutes of personal communication can tell you more than half a year of remote work. My personal experience shows that after live meetings people become more responsive and even responsible because they have a feeling that they “know each other personally,” which is perceived differently from “knowing each other remotely.”
It is very important to, find a right balance between remote and live communication when possible. This is particularly necessary with complicated projects, when remote meetings save time in the short term, but face-to face ones save time in the long term, which is usually more beneficial.
Daniel Rosenberg
SVP User experience, SAP
There are so many different dimensions to the topic of globalization for user experience teams that my recommended approach is similar to peeling an onion. It needs to be done layer by layer with an understanding of the goals and value provided with each deeper approach to the core.
The most important step is to separate out the operational topics from the strategic ones. Many times I have seen decisions made regarding the organization of a global UX team precede a complete understanding of what the long-term purpose of building the specific team actually is. Explorations of the best Web/video conferencing system to purchase, the optimal remote usability testing setup, or the appropriate level of project structure and delegated responsibility level will change based on the experience of the local team and its leader, but even more important, based on the nature of the mission.
Typically the mission of global UX teams fall into one of six scenarios:
1. Designing a product for global consumption
2. Modifying an existing product for local consumption
3. Designing a totally new product for local consumption
4. UX team as guidelines police force to oversee local (outsourced) developers
5. UX team embedded within IT organization doing internal systems design
6. UX as part of consulting practice (local or global)
In the first scenario, the local organization must be designed for daily coordination with other design locations as well as engineering and marketing in a highly distributed fashion. The communication skills and a shared design methodology are second only in importance to a high-quality project management approach to ensure that no deliverables are dropped. In the second and third scenarios, an organization with more local autonomy is preferred with a small and predictable amount of oversight from headquarters. This can work particularly well when other product stakeholders such as engineering and marketing are also local. It looks more like the first scenario when it really is not.
The fourth scenario is the most problematic from a management perspective. It is best to avoid this one because the work will be boring for a high-quality UX team. It provides little ownership and very little opportunity for creativity. This scenario is a recipe for high employee turnover and low morale.
Scenarios 5 and 6 provide additional challenges primarily depending on whether the internal or external customer is local or globally located with respect to the UX team. In a typical outsourcing situation the UX team is not collocated with the customer or problem owner. In the global case a significant travel budget is generally needed during the requirements and validation phase. The most common reason for project failure is the desire to save money combined with the assumption that conference calls are as good as face-to-face communication, particularly in the requirements gathering and validation phases where observational techniques are more relevant than interviews.
Another critical challenge is to define whether the local UX team is totally self-contained and has the full range of required interdisciplinary skills locally; for example, interaction designers, user researchers, information architects and visual designers. In the first scenario outlined above, there is typically a difference in global role distribution compared to building a stand-alone product or a module for a larger suite. In the case of software suite vendors, UI guidelines and visual design are usually centrally owned within a UX team at the headquarters location. The local UX team will need to learn to work within those UI pattern and branding constraints. This in turn impacts the type of designers that can be hired. For example, a Web designer used to concurrent ownership of visual design, information architecture, and interaction design generally will not adapt well to a globally distributed product UX organization where these skills are specialized and concentrated across different geographic locations.
As the dimensions previously identified indicate, globalization is a complex multifaceted topic. My best advice is to start with a clear understanding of the long-term goal and design each globally distributed team to match that goal. Otherwise you run the risk of building a UX team capable of delivering short-term cost savings that cannot scale to do independent design as both the team and the business mission mature.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.