When building a team there are four things you want to achieve:

Each person on the team does not need to have identical skills. To ensure the most creative diversity team members should have different collections of skills. This means you are putting together a portfolio of skills. The choices you make about new skills, experiences, and styles you are adding are determined by the skills, experiences, and styles that already exist.

Diversity is important not only because it is the right thing, but because it is at the heart of building a creative team and baking innovation into everything the team does. The literature is full of research that demonstrates the power of diversity in driving creativity. For a UX team it is especially important as it brings with it a richer set of perspectives for understanding your users, for relating to the diversity of people you are collaborating with across the business (and for solving collaboration issues when they arise), and to enliven the design process. This diversity includes skills and experiences, race, cultures and gender, disabilities, sexual orientation, age, new hires, senior people, and more.

Coupled with collaboration skills, the healthy give and take from different perspectives and backgrounds also contributes to the energy of the team. I have found the more diverse the team the more fun we tend to have. Each person should have a can-do attitude, curiosity and imagination, and the willingness to be ready for any challenges faced by the team. Team members should be able to put together a point of view and move it forward. They should be willing to grow and take coaching. Each member may express it in different ways. Some will be quieter and some more outgoing and some will bring different cultural backgrounds and personal styles to the table; ideally each member will have an energy that adds to the whole. With this energy and diversity, however, there will inevitably be some tension. It is important to turn it into creative tension and make it work for the team so people are able to work collaboratively and have the greatest impact.

A colleague from Microsoft’s office in Israel visited and asked what skills they should look for if they could only hire one person. Who should be first in after the manager (especially if the manager is not a UX person)? A good choice is an interaction designer since this position is typically a “tweener,” spanning both design and user research. Interaction designers usually come out of human-computer interaction (HCI) or human factors programs, can prototype, can create interaction design and basic wire framing, may be able to do reasonable visual design, and can perform user research to validate and shape the designs if needed. The most important driver of user satisfaction is usefulness, which is largely reflected in the interaction design. The interaction design has to be incorporated at the deepest level of the software architecture and it is often the most expensive to change late in the process.

The biggest demand from development teams is for visual design. Many developers would prefer to do something other than design, although there is an ongoing conflict with developers who believe their sense of design is equal to that of experienced designers. However, in order to deliver value to users and the business and to get the interaction design right, it is important to have user research skills on the team. Engaging users in the design process, centering design on scenarios coming from the users, exposing engineering teams to the users, getting feedback on designs throughout the process, and other activities of a user researcher are terrific sources for demonstrating the value of UX work. Interaction designers are often capable of both design and research skills, but if they are not or if the demand far exceeds their ability to deliver in both areas, adding a user researcher could be worthwhile. Figure 2.1 contains a sample job description for a researcher.

Once the team has interaction design and user research skills, then typically great visual design skills are needed (see Figure 2.2 for a sample job description). It is the visual design that makes the user experience work the most visible. In the early 1990s visual design became important to successful software products, moving it from a luxury to the necessity it is today. As the Internet started to be widely adopted, the design bar moved higher and people began expecting an aesthetically pleasing experience along with functional value. A great product designer can drive people’s emotions and trigger a WOW! Research has shown that great design builds user trust and triggers expectations of ease of use and value. Coupled with the interaction designer building in the value and the user researcher who can identify changes needed in the design to enhance usability, the visual designer brings the design over the finish line. The visual design carries the branding for the team’s value, and a great designer is typically recognized by everyone as having skills that the developers do not have. Creative visual designers enhance the skills of the interaction designer and the researcher as well. They help everyone communicate their ideas in a more compelling way and are a unique source of innovation in how the interaction design is implemented.

Beyond the basics, it can make sense to grow the number of visual designers faster than the interaction designers and user researchers (since they move between each other’s roles and support several visual designers). Some teams try to match researchers and designers 1 to 1, but for many teams 1 researcher for every 2 designers seems to be good ratio. Corporate cultures differ in whether they try to keep design and research roles separate, and the degree to which they differentiate specialists within the skills. In practice it is possible to find both specialists and generalists, and academic programs are producing both.

Figure 1.2, created by Clement Mok (2000) and shown in Chapter 1, illustrates many of the skills and job titles in the user experience discipline. Design includes the interaction and visual designers that have been discussed, information architects, graphic designers, art directors, industrial designers, ergonomists and human factors professionals, brand specialists, producers, audio designers, experience architects, and others. Researchers include specialists in usability, quantitative research, statisticians, ethnographers, market researchers, and more. The particular mix of skills that you add to a team depends on the focus of your organization, your strategy, the size of your organization, and the demand for its services.

Technical writing and editing of the text within the interface is often overlooked when thinking about staffing a UX team. This is distinctly different from the writing and editing of marketing content, because it focuses on the embedded assistance in the design and the discoverability that it supports. Everyone has seen examples of poor content writing and editing. A recent design my team was trying to salvage began with prompts and explanatory text that developers wrote as they produced the interface, was modified by marketing people who wanted to make sure all the right words were included that would convince people to buy more products, and then was extended by lawyers who wanted to make sure that every possible liability was covered. The resulting design was virtually unusable. Designers and researchers can often write well, but they are not the word masters that a good technical writer and editor would be. Occasionally there will be successful writing from designers and researchers, but there is no substitute for a professional and specialists in the technical writing field are very good at what they do. If you cannot have content people on the team, ideally you should try to have access to them. As your UX team grows beyond the size of a group, the importance of having these specialists grows.

For larger teams it can make sense to start growing specialists in key areas that can work across projects. A critical specialist is an expert in accessibility. Obviously everyone should have this issue close to their hearts and built into their toolbox of skills, but practically speaking I have noticed that this works best when there is one person who is really passionate about it and works as an evangelist across the team. Similarly for products that will be deployed globally, having someone who is a passionate expert on globalization and localization can bring tremendous benefits. As the team grows, and as you start to have a group of researchers and research that happens on an ongoing basis, having a technical support team member or access to technical support for the user research lab, design and research tools becomes important to ensure that the team can be maximally productive and not waste their time on overhead activities. You may need someone just to handle the recruiting of people for user testing, gratuities, and to maintain the database that tracks who has already been tested. Beyond that, building out interface development and prototyping skills, the skills of an experience producer or equivalent, and market research skills can enable various strategies. Past teams I have managed have included writers and developers specializing in producing software development kit (SDK) content for the design patterns and code samples we were creating, and Web developers working on our team site and interfaces to our guidelines. One colleague had ontologists on his team who were helping create a particular user support experience.

An alternative to growing a user experience team that owns most or all of the interaction design is to grow a team whose strategy in part is to scale up by enabling others to produce effective experiences. The way to do this is to grow the design skills of everyone involved in the user interface (UI). The goal is to create a virtual UI team with shared responsibility for the user experience. Andreas Hauser (2007) described this well in the article “UCD Collaboration with Product Management and Development.” The argument is that the user experience team helps bridge the relationship between product management and development by representing the user’s task-specific requirements, providing design leadership, creating process controls, and educating others to perform key tasks needed for the design and development of the interface. Hauser argued that in one view of the ideal model

Some companies are beginning to grow project managers who specialize in the user experience area. At times they are called producers and their role is to clear the way for the UX work and support it, to amplify the impact of the designers, and to work through the technical issues necessary to deliver on many of the user requirements. In one product group these specialized project managers are responsible for much of the scenario definition and interaction design, and they work closely with the user researchers as the interaction is defined. The project managers also reach out to the visual designers to implement their designs in a consistent and compelling way.

Some want to create developers who are generalists that can be shifted from project to project as needed. It can be effective to create UI developers who understand the technologies needed to create great user interfaces and who are experienced in working with designers. This is especially true as more and more tools are created that blur the lines between design and development. Testing is one of the final links in the chain. Like user experience professionals, testers also want to get involved earlier and be treated as partners and collaboratively create test plans. If UX and testers work together on test cases that appropriately reflect the targeted users and the top priority scenarios, better experiences will result. To grow each of these disciplines involves rethinking traditional roles and responsibilities, relinquishing control of some tasks that UX might otherwise take on, and training and mentoring the members of the virtual UI design team.

The Myers-Briggs method of characterizing differences among people is commonly used in companies as another way to describe the diversity of people on teams, and both the challenges and virtues arising from that diversity. Some leadership training courses recognize that personal styles differ between normal and conflict situations. Another way of looking at the diversity that can be designed into teams through hiring is to focus on problem-solving styles (Basadur, 2004; Basadur & Gelade, 2003). Much of what UX people do is problem solving. In this scheme, there are innovators, conceptualizers, optimizers, and implementers. Innovators love to come up with new ideas. Conceptualizers are about looking at diverse data and make sense out of it. Optimizers like to put things together in a way that drives efficiency (and they are typically the people who look at a large spreadsheet and immediately see the numbers that do not fit). Implementers ensure projects get done and are excellent at creating and driving plans.

User experience people tend to fall mostly into the innovator and conceptualizer categories, while many engineers are optimizers and implementers. It is not too surprising then when misunderstandings between people in different roles occur, since each person has different goals and values. To get a project done and for a team to collaborate most effectively, you would like to have team members in each of these categories. Most people have a preferred style of problem solving but have some skills in the other styles as well. One thing Basadur noted is that people can move into different areas depending on situational needs.

As your organization grows you will need to start hiring leads, managers, and perhaps even managers of managers. Here the focus is on many of the topics being discussed throughout this book. At this point you are looking for leadership and the ability to attract a following. Look for strategic thinking. Project management and experience leading teams will be important. The ability to communicate effectively is essential when selling ideas and negotiating to overcome conflict. Much of what you are looking for in individual contributors in the soft skills area becomes the hard skills for leads and managers.

At many companies, the process begins with an approval to hire and enter the job opening into a system that tracks personnel. Often there is an administrative assistant in the organization who serves as the interface to the personnel system. Entering the job opening into the system triggers a variety of business processes that support bringing the person hired on board.

This process begins with writing a job description. The job description typically contains a high-level description of the role with text that gets people excited about the job and motivates them to apply. While you want to entice the right people to apply, you still want people who are not going to be a match to realize they clearly will not make it through the process or eventually discover the job does not match their interests. You want to catch people’s interest but you do not want to deceive them. The job description also includes the job requirements (both the requirements that must be met and those that it would be nice for the candidate to meet). These requirements need to be verifiable and linked to successful performance, and avoid subjective characteristics. Cheerfulness, for example, would not be a good requirement. Figure 2.1 and Figure 2.2 are examples of two job descriptions I have used before.

Part of the challenge is that many companies have career ladders where the specific responsibilities vary by level. As a hiring manager, you may have some leeway in the level for which you are hiring so the job description may need to be flexible. There are roughly four categories: entry-level people, experienced early-career people, senior people who are hired in part for their leadership abilities, and very senior people. Beyond entry level, job descriptions differ between individual contributor roles, leadership roles, and roles that require a mixture of the two.

Hiring regulations have caused some companies to require applicants to go through the corporate Web site, and for the first contact to be handled by recruiters (either internal or external) who can assure the process is unbiased. The recruiters are likely to want a subset of the requirements from your job description so they can filter resumes and so they can use them during the initial phone interview. If you have employed a headhunter, they will share your job description with candidates they are recruiting on your behalf. If you or your recruiters are finding candidates at conferences and through various job boards and sites frequented by UX people, your job description will serve as the basis for posters used at job sites. Know that UX professionals are a community, and chances are your job description will be forwarded far and wide.

Dealing with recruiters in the Human Resources Department (HR) can be quite frustrating for many managers. The process they use to recruit engineers might not be as effective when recruiting UX candidates. UX professionals may come from a wider variety of backgrounds and schools, and are often evaluated based on portfolios and criteria that may not be as important for, say, developers. It helps if you can get a recruiter dedicated to recruiting UX people. You can then invest the time to educate that recruiter about UX, what it is about, and the skills needed to effectively do the job. Recruiters may be able to join you at key conferences, where they should ideally attend a few of the sessions. As recruiters attend UX conferences and meet a variety of people in the field they can develop a better sense of what makes an effective candidate. A dedicated recruiter can also begin to build a list of relationships with potential candidates that they can leverage over time to either hire senior people who might become available or to leverage for networking to find other candidates.

Working with recruiters to better help them understand the requirements built into the job description is very important. They in turn will help you understand what they can reasonably screen for as they go through resumes, do phone interviews, and meet people at conferences and universities. Recruiting is a long-term investment, and just as you want to build a reputation with the candidates, you want to build a relationship with the recruiters on which you depend. If you can get someone dedicated to your cause you can meet with them periodically to provide advice on where they can look for candidates, you can feed them names of UX professionals that they should build relationships with, and you can give them feedback on how candidates they have recruited have worked out. This investment in time also can help during the process of negotiating an offer and it supports the candid conversations that will result in the best for the candidate, for your team, and for your company.

Students will often ask what I look for in a resume. I have shared some of the attributes in Lund (2000) and through student panels on which I have served (many of which were organized by Ron Shapiro for the Human Factors and Ergonomics Society, HFES). The questions students ask these panels as they consider applying for jobs and the responses from various hiring managers are documented on the HFES site (http://64.9.213.250/Web/PubPages/career.html). Fundamentally, the goal is to match a candidate who has the skills and passion to do the job with the characteristics of the job. These characteristics consist of both the specific needs that led to the opening and the more general needs you anticipate as your team moves into the future. Hiring someone is a long-term investment, and you should be thinking about hiring for your team and hiring for your company. Remember that if you do your job well, the person you are hiring today may be your boss in the future. The process, therefore, is about transparency. Both you and the candidate should be confident the fit is right.

In the 1980s and 1990s in the telecommunications industry it was common for UX applicants to have PhDs and come out of cognitive psychology programs. As the software industry has grown and the variety of skills needed has increased, the diversity of the candidates has also increased. Skills may come from formal training or through experience, and some of the most interesting candidates have traveled very unexpected paths. The approach to resumes has evolved as a result. In the beginning, the review was similar to the way you might expect to review an academic curriculum vitae. Currently the review is more focused on looking for evidence that the candidate can do the job.

When I first pick up a resume I briefly look at its design. The job is for a UX person after all so the resume should have an appropriately clean and attractive design, and should guide me to the information that convinces me the person would be a match for the job. It does not need to be fancy, but it should not be poorly designed. As I read through resumes, I will be monitoring grammar, typos, and so on. Those are clues to how the person will approach their job. I look at the schools they have attended. If they have been successful at high-quality schools in programs that I respect, that will shape my initial estimate of what they know. If I do not recognize the school, that does not rule them out, but it means I will look even harder for more evidence that their practice is grounded in knowledge. If they have some form of certification that I recognize and value, that also tells me more about what they know and about their attitude. For new graduates I look for internship experiences (and where they occurred), professional activities, and leadership positions held. For more experienced people, I look for what they have done and their professional accomplishments. I go through their work experiences looking for evidence of substantive contributions and its impact. I look for evidence of skills that predict how they will do in my work environment. If they have a Web site, I will look for similar evidence there. Finally, if they are a designer I go through their portfolio in detail. I want to see design that is compelling, creative, and reflects sound design principles. If they are a researcher I look for any examples of the research they have done (perhaps in conference papers or published articles). I pass the resumes of the best candidates to my team and seek their opinions. For candidates that may move to the next stage, I look for gaps to explore with their references and through the interview process.

For visual design candidates, the portfolio is a critical part of the process. When the job is about producing design, seeing the designs a candidate has produced is revealing. For designers I look at the quality of the designs they produce; I look at their aesthetic. The portfolio may be thin for new graduates, but those whose training is explicitly in visual design should have design to show. Recruiters unfamiliar with UX may neglect to ask for the portfolio, and will need to be reminded to do so. It also serves as the basis for many of the subsequent conversations through the interview process around the designers specific contributions, their own design process, and how they think about design. Interaction designers and researchers may not have a rich portfolio given the nature of their work, but you can look at any publications or other artifacts they share and study the content they include in talks during the interview process.

Depending on your company’s policies, either recruiting or management may do a phone screen with the candidate. If recruiting does the initial screen and gives the go ahead, then follow up and make your own phone call. The screens serve several goals: they provide the candidate with more visibility into the nature and requirements of the job, and they provide a better idea of what the candidate wants in a job. The screens also present an opportunity to explore the gaps in the resume and answer questions that may have arisen when talking to the candidate’s references. They are also the first opportunity to evaluate the candidate’s communications skills, and for the candidate to show their curiosity, creativity, and problem-solving skills.

If the phone screens are successful the next step is the face-to-face interview. Companies vary in what recruiting considers an appropriate process. Some years ago casual meetings between the team and the candidate over breakfast, lunch, and dinner were encouraged to make the candidate more comfortable and to explore the fit with the team culture. Now these seem to be more restricted because questioning about personal areas is discouraged to avoid even the appearance of discrimination, and interviewers are rightly cautioned to beware of their own stereotypes through the interview process. Unconscious biases might restrict the kind of diversity that creates a more effective team in the long run. There will be casual conversation and the candidate needs to eat, but these times are more constrained than they once were.

The interview process is an opportunity to share the culture of your team and company. You want the candidate’s experience to be professional and well orchestrated from the moment arrangements are made for their visit, through the final filing of expenses and the completion of the process (whether an offer is made or not). You also want candidates who do not get hired to serve as evangelists for your team. A standard checklist with owners identified and activities tracked can be helpful in managing an effective experience while minimizing the workload. The interview experience should be designed based on the goals of the visit and the impression you wish to make with the candidates interviewed. The interview process will go smoother if both your team and the candidate are prepared. Let the candidate know how to dress, what to bring, and what to expect. Provide directions, and arrange or help arrange needed transportation ahead of time. If interviews and activities are distributed around several buildings be sure to allow time to get from one place to another and allow time for things to go wrong — as they inevitably will.

The interview day is not just about interviewing the candidate; it is about the candidate getting to know your team. For some companies, there is a formal recruiting interview at some point during the day where the boilerplate questions are asked. A good way to start is with a portfolio or a research review with those interviewing the candidate throughout the day. If you invite your entire team and a few other key stakeholders or knowledgeable people, these reviews can even serve as training. The goal is for the team to see how candidates perform in a group setting, their communication skills (especially their presentation skills), their ability to design their communication to have an impact, and for you to quiz them on their design or research process (simulating what might happen when they present to a project team). It also saves the interviewers from having to cover the same ground and provides material for deeper questions to be asked in individual interviews.

A good approach to the interviews is to have a variety of people talk to the candidate, including both members of the team and perhaps a representative or two from one of the teams with whom they might work. It can be effective to identify the skills and experiences you are looking for up front, and then have different people be prepared to focus on each of the areas based on their unique expertise. Distribute the topics so that each interviewer has their own set of questions, but ensure that for the key questions there are at least two people providing their assessments. At some companies one or more of the interviewers is responsible for evaluating the candidate not just from the perspective of the immediate opening but also determining whether the candidate would make a good company employee. A more senior person who has been part of successful hires before can provide valuable insight in this role.

Knowing that as the interviews proceed new questions can arise and other questions may not be completely answered, arrange for communication between interviewers throughout the day. If you can get the interviewers to agree, a very effective technique is for each interviewer to e-mail a quick summary of what they learned and questions they believe still need to be answered and send it to the other interviewers. Some companies have arranged the process so that if it becomes clear the candidate is not a match, the process can be terminated early. If this happens, the candidate will not meet with all of the interviewers. The candidate will need to be prepared to be flexible and should know the interview schedule is subject to change.

As the hiring manager, you should finish the interview day. This is the place to ask any remaining questions and answer any questions candidates have at the end of the process, as well as lay out the next steps. The final discussion is a good time to sell the team and company as well. If you believe the person is a match then this is a key point to win them over, and even if you feel there is no match then it is an opportunity to ensure they leave with a great impression of your team.

Some companies have a defined set of competencies that employees work on growing and that are leveraged throughout the interview process. These are defined by the HR organization, and if your company has something similar it is a good place to start when designing an interview process. The skills behind the competencies are common across many companies, and common questions that are explored depending on the candidate and the job requirements often include:

More recently candidates are reporting that they are given “take home” problems to submit before interviewing. Other companies require designers to solve design problems during the interview process or to design a research study. There are teams that ask candidates to solve problems the team is currently facing, and others that use hypothetical problems. Some companies use team interviewing. The press has covered companies that use “impossible problems” (e.g., How many utility covers are there in the United States?) to test candidate creativity or reasoning ability. Still others have used formal tests. I personally have not seen these techniques yield better results than rich interviews and portfolio reviews, and the end results strike me as not recognizing that people may have very diverse styles and yet still be highly effective. These artificial situations seem less like simulations of real work environments and more like selecting people for colleges based on their standardized test-taking abilities. The interview process needs to be more nuanced to create a team with the greatest creative and effective diversity.

If the candidate looks promising, I try to connect with their references to see if I can get more real-world confirmation about what the candidate is actually like to work with on a day-to-day basis. One thing you cannot get from the resume or even the interviews is how a candidate collaborates. Be realistic about what information you can get from a phone screen with a reference. Clearly the candidate’s references were chosen because they will say good things about the person, but I have found in talking with them I can usually get behind the “he/she is great” comments. From the resume I can often also find people who have known the person when they were at school, at previous jobs, or professionally. UX is a relatively small community and there are usually only a few degrees of separation between any of us. Those who have made favorable impressions as they have moved through their careers (however short) are those that have the kinds of skills I am looking for on my teams. Internal candidates allow you to connect with previous managers and have a more candid conversation about a candidate’s strengths and weaknesses.

If the candidate has made it through all of these screens, the next step is to work with the recruiter or other appropriate HR person to put together an offer. You will want to be competitive, but you do not want to set the candidate up for frustration or even worse, failure, by bringing them in at a level or salary that is too high. It is better for them to move up quickly than to come in and stagnate in the career and salary ladder.

The best way to find great people is to get great people to find you. If you already are an excellent manager and people know it, your reputation will bring people to you. People who have worked for you will want to work for you again, and they will tell others about you. If you let them know you are hiring, they will actively recruit for you. Similarly, having an ongoing professional presence where you demonstrate the quality of the work your team is doing, the impact you are having, and the excitement your team feels about their work environment serve to lay a foundation for future recruiting. I almost never return from a conference without a pile of cards or resumes in my briefcase. The most effective recruiting often starts well before you have an opening; it starts as you build relationships with potential job candidates and with influencers who will evangelize on your behalf.

Large companies often have an internal site for posting jobs. There is some pain in losing good people to internal movement, but it is often exactly the right thing for their own development and is beneficial to UX departments within companies. New ideas and best practices are brought to your team, even as your best practices have a broader impact across the company. Movement within the community allows teams to flex their size based on local need without the company losing great talent. It also creates an internal network that can be leveraged when you are looking for special skills, and gives you a natural way to discover background information on people interested in joining your team. Beware of getting a reputation as a raider. It is one thing to reach out to peers to see if they have people on their teams who might benefit from moving to your job or to publicize your job to those seeking a change, but it is quite another to be seen as poaching. The Golden Rule is a good one to apply when recruiting within your corporate community.

As mentioned, your job description should appear on the external-facing corporate career site. It is worth checking how it appears and running through the scenario of a UX person looking for your job. Some companies do not include the UX tags that job applicants look for in their site search or navigation architectures. Also make sure recruiters are actively scanning the resumes that arrive in response to your job description, and see if you can review resumes coming in for other UX jobs sibling groups have posted on the site. You may be able to negotiate to achieve the best match of candidate to job, and even have a candidate come in and interview with a couple of groups at the same time. You and the other hiring manager can then agree on a process for resolving the situation when you both want to make an offer.

Other opportunities to expose your job to potential candidates include:

One recent change is that corporations are working very hard to ensure that every candidate is treated equally. That means while it is okay to stimulate people to enter the pipeline or to encourage people to apply for jobs that might be a good fit for them, you have to be very careful about what is said, not to promise anything, and to make sure the candidates enter the formal recruiting process (through the corporate recruiting site). Recruiting then applies standard filters to the people in the pipeline to find the ones that match the job you have defined. It is very important, therefore, to work closely with the recruiters to make sure the attributes you are recruiting for are very clearly and objectively defined, and to identify where you have flexibility in the parameters. Companies differ as to whether you have the ability to interview two or three applicants and then pick the best candidate, or whether you must hire the first person you feel qualifies for the job.

When you start a team and are looking for your first employee, you are faced with a unique challenge. The team has no reputation yet — a team brand. Your personal accomplishments may be impressive, but from the outside it is not clear what your management style is like and whether your team will be successful. Joining your team may appear to be a risk for candidates. There may be an attraction for the entrepreneur who wants to be part of starting something new, but how do they know if funding might be cut next year and the team eliminated? At some level you will be bootstrapping your team up, acquiring the best people you can, and then taking advantage of growth and attrition to enhance the mix of skills and experiences on your team.

If you have come from another organization or another company, some of the great people from your previous teams may come to join you (or at least be interested in interviewing). If you can provide a compelling vision you may be able to attract a team who wants to join you specifically because of the uncertainty, the chance to build something new, and the chance to put meat on the bones of your vision. But you may also need to take a few risks and choose from candidates who might have the occasional flaw and who did not fit well with a previous team. They may have struggled in an earlier organization, perhaps because of a mismatch between their style and goals of that organization or because they are still growing in a particular area. What you need to decide in cases like that is whether or not you are betting that the apparent flaw was an aberration, or if it is a true growth area that will improve under your leadership and your particular strengths. Often the best people are most willing to strengthen their weak areas and those that most need to grow are often the most resistant to recognizing their flaws. You may also need to supplement with others who have strengths that complement the growth areas to create a complete team. At the beginning, getting the mix in balance is often the biggest challenge.

One of the things I enjoy is talking with students who are getting ready to enter their careers. The HFES conference has done an excellent job over the years in creating opportunities for students to see what directions their careers can take and giving them a hand up. Consistently the most important advice fellow panelists and I give to students is to get an internship. There is no better way for students to learn what working as a UX professional might be like; to find out if their future is in practice or teaching and research; and, if in practice, to discover the questions to ask to help ensure that the job they are considering is the right job for them.

Hire interns if you get the chance. Practically, you can often hire interns when you cannot hire anyone else. That is not always true — at some companies an intern may take a vacancy that would otherwise go to a full-time person — but generally it is. Interns are very cost-effective. They may only work for a short period of time (like a summer), but they are perfect for many of those tasks that your full-time staff does not have the time to take on.

Interns also add to the diversity of the team. They bring a lot of energy, they bring fun, and they add to the creativity. They also help take your team to another level; while the team is educating the intern they think about their own work in more general terms. Interns ask naïve questions and questions grounded in the latest research and both often cause your team to step back and re-evaluate approaches to problems. They also are future candidates for full-time positions. The internship gives you a chance to see them at work before they enter the full interview process.

When I interview interns, I look for the same kinds of characteristics that I look for in full-time people. I just do not expect their talents to be quite as developed. The interns obviously do not have the same level of training and experience, but they can have the spirit and curiosity I want more seasoned professionals to have. They will have skills they are bringing that can be applied to a meaningful problem I would like them to address. They may not have evidence in their resume that looks as impressive as a new full-timer, but on interviewing them I often find experience that typifies the collaborative skills and the ability to take responsibility that I am seeking.

The needs of projects can vary, and in some organizations funding ebbs and flows quite frequently. When that happens using vendors and contractors can be an effective approach to staffing. It is relatively easy to bring them in and equally easy to reduce staffing (assuming the contracts are written properly). If a project walks in the door and needs someone right away you can create a team with vendors and contractors more quickly than if you hired full-time staff. Since such projects may be of limited duration, the staff is hired only as long as you need them. You can also add staff without adding the other infrastructure that comes with full-time people such as offices, equipment, and hardware.

If you need specialized skills (e.g., ethnographic research or high-end product design visioning), the best way to find those skills for the time that you need them is with vendors and contractors. In this case, those bringing in the specialized skills may not only be doing the work, but you should work to leverage them to transfer their skills to your full-time staff. Over time, your team should be capable of taking on these added tasks. There may be times when hiring an outside expert brings credibility to an argument you are making that might not be there if you use internal staff. There may be times when there are teams that want support and you do not have people available at the moment but want your team to have effective, professional UX support so in the future they will fund full-time support. During these times vendors or contractors should be considered. In general you want your full-time staff to do most of the interesting work, take on the big challenges, and build the intellectual capital that brings value over time. If you are focusing your full-time staff on the work that provides design leadership you may want to outsource the more routine production work to vendors and contractors.

As a manager, be careful to not treat vendors or contractors the same as you treat your full-time employees. It needs to be clear that these relationships are different. You do not want your full-time employees envying the life of the vendor or contractor. On the other hand, for effective projects you need to worry about how to ensure people are fully informed about what they need to know to do their jobs, that there is communication and collaboration, and that the contractors and vendors not only have a contractual relationship to deliver but share your personal vision for the excellence of the work. Great contractors who catch the excitement of your team and bring unique value also become potential candidates for full-time positions. As a result, you should try to bring the contractors and vendors into the right meetings to help ensure they are collaborating effectively with the team.

There can be a distinct difference between how contractors and vendors are handled. I am going to discuss this distinction to differentiate between two models used to supplement your full-time staff. The terms used at your company may vary, but the models are fairly common. Contractors may freelance or may be associated with a staffing agency. They typically are brought on when particular skills are needed for a period of time. If they are working with an agency the costs might be slightly higher since the agency will want to recoup the overhead of managing benefits, taxes, payroll, and so on. From a corporate perspective, however, it is often easier to work with an agency versus the individual, and contracts may be easier to set up with the agency. If you identify a particularly interesting freelance contractor and you run into barriers engaging them, you may be able to find an agency that they can work through. Contractors can be relatively easy to move from one project to the next as priorities change without needing to renegotiate contracts. Selecting contractors is similar to selecting full-time employees, although it does not need to be quite as extensive as it is easier to terminate a contractor if they do not meet your needs.

Vendors are usually engaged to take on specific projects. They may be pre-screened and need to be approved at the corporate level. If you want to work with a new vendor, it can take a long time to get through the screening process. For large contracts you would go through a Request for Proposal (RFP) process to find the best vendor for a given project. While your company may want you to focus on a few large, full-service vendors, UX work tends to be more specialized. Many of the largest vendors are not particularly strong in their design and user research competencies. We have identified sets of UX vendors that have strengths that we want to leverage. Some are particularly good at design innovation or generative user research (and they tend to charge the most). Some are good at production. There are firms that specialize in usability, contextual inquiry, branding, and graphic design. There are vendors with an international presence, and some capable of scaling to very large projects. There are small, low-cost vendors who are willing to be very flexible and responsive and large, more expensive vendors who bring brand-name credibility to projects. In large companies there is the opportunity to learn about the experiences others in the company have had with the vendors you are evaluating.

One thing to watch out for, especially where you have helped teams outside your organization to hire vendors or contractors, is to make sure they are aligned with your best practices and reusable assets (e.g., design guidelines). How they perform reflects on you even after they have left the project. Try to stay involved for quality oversight. Teams supported by vendors or contractors need to align with the way you do things because of how it reflects on your team and how it helps ensure consistency across experiences. For example, you may want to build compliance with your standards, guidelines, or best practices into the contracts that are created. You may also want to build opportunities for you to review or sign off on major milestones into the project plan. It may seem like using vendors and contractors will allow you to scale indefinitely, but it does take overhead to manage them if you are going to ensure quality, consistency, and client delivery. It is likely you will hire a limited number of vendors. Before deciding on how many vendors to hire, you need to anticipate the management overhead in your resource plans.

Interestingly, one of the best discussions of how to select a usability vendor is written by an usability vendor (Schaffer, 2004). Eric Schaffer, recognizing that initially you are trying to build your program, recommends leveraging usability vendors to help get your program started. He suggests:

Schaffer laid out a nice set of weighted criteria for selecting a usability vendor in his book. His top criteria are the staff that will be on your project, the completeness of the solution they can offer, their domain expertise (which I would include in my staffing evaluation), their methodological expertise, and their available tools and templates. For each criterion he lists, he provides further detailed considerations that you can use.

In recent vendor evaluations, we have started to compare them on similar criteria. Our set of dimensions includes:

We define a scoring scheme for each item and calculate an average for the factor. Each factor can then be weighted, and the weighted average scores summed to define a total score. The total score is then used to compare alternative vendors. The scores are just a tool, and business judgment needs to be applied to the result in case an individual item or other considerations turn out to be critical to the final decision. This approach works well for evaluating responses to RFP requests, especially when the RFP provides responders with a clear vision of the requested work. Supplement this process by having the vendors present their proposals in person and respond to questions that arise as you compare the written proposals.

Costs of vendors and contractors vary considerably. Reasonably experienced freelance contractors often cost less than full-time staff, although very senior contractors may command as much as a 25–33% premium over comparable staff. Contractors obtained through an agency seem to come in at about the same as the loaded cost for full-time staff (where the loading includes the overhead for benefits, offices, equipment, etc.). Vendors leveraging staffing outside the United States may be able to get their costs to a level that competes with full-time staff but at the cost of the overhead that comes with remote workers. Vendors who specialize in local production work are often in that 25–33% premium rate over your full-time staff, and specialty vendors who are in great demand and some very large brand-name vendors may run fully 2 or 3 times the cost of full-time staff.

Currently we are testing a staff augmentation model that tries to combine the virtues of a consulting model with a vendor model. We are engaging a vendor who can provide contractors on demand. The contract will be set up so that teams can “buy” support either for specific UX deliverables or they can by blocks of hours. The hours can be used to engage a variety of skills as needed. To help the vendors in their responses to the RFP, I have defined a prototypical project with a set of deliverables through the development cycle. I have also provided a framework of the standard design and research artifacts we typically create and how much effort they take (for small, medium, and complex projects). The statement of work also includes skill descriptions that map to comparable levels in a career ladder. The vendor will provide program management office (PMO) support that handles recruiting to our requirements, managing staff in and out, and performance reviews. The expectation is that they will meet our guidelines and design patterns and other requirements to ensure that their design is consistent with the full-time staff designs. We’ are able to use the staff as we would use contractors and move them from project to project as needed with easy modifications to the base contract. There will be service-level agreements about how much time they will have to staff new projects and for the quality of the work delivered. Over time as we increase our use of this type of vendor, the goal is that prices will come down but we will be able to continue to increase the quality of services. The goal of this model is to enable the staff augmentation to scale indefinitely. The hidden agenda is that we will be able to demonstrate an ongoing year over increase in the demand for these services, and that this increase will be converted to help fund full-time staff (which should be less expensive on the average and produce a greater return).

Over the years I have tried to get each of my managers periodically into a neutral setting to have a casual conversation about where the UX program is heading and to improve my own performance. When I was at Ameritech, at one such lunch Joel Engel (my boss at the time) asked “Don’t people in your field actually know anything?” I thought this was interesting since Joel had previously managed a successful human factors department, and was clearly a champion for UX within Ameritech. Certification is one way to show that people in our field know something. It is also about the science behind the field, and it is what distinguishes the field from an art and perhaps from the craft. Our field has elements of both art and craft, so those that argue that a portfolio review is the best way to capture those aspects are right. We typically assess those skills in interviews where we try to understand the process the candidate uses to get a sense of whether they will be reliably successful in their design work. As with engineering, however, there is also a long history of research and the evolution of best practices in the relevant fields that inform user experience. While having a foundation in that body of knowledge is not a guarantee of excellence, one would hope that having the foundation would help improve the probability and reliability of making good design and research decisions as well as in interpreting feedback from users.

With this in mind, I would also state up front that I am still a little old school. I believe in doing things for reasons in addition to their usefulness. I believe in doing them because they are the right thing to do. I believe that the certification process itself should continue to drive our field to be more systematic in the excellent results we want to produce, as it forces us to think in terms of generalizable principles based on a deep understanding of design and users in context. It is consistent with the arguments we make about why and how we should be integrated into the development process. I also believe that as a user experience professional, I should test myself. When I run in a marathon, it is partly to see if I can do it. It is a test of my own ability and my training. As a professional, I want to make sure I am as fully equipped as possible to give my very best in my chosen field, and when I do research to advance it, that I am advancing it from the shoulders of the giants who have come before.

Certification is a controversial topic. It is regularly discussed in forums frequented by UX professionals. Some argue that it is impossible to certify UX people, and others argue it is critical for the credibility of the UX profession that certification become part of our community culture. For a manager, the question is whether certification is desirable for full-time staff, contractors, and vendors and, if so, under what circumstances.

Certification is intended to verify that someone has a body of knowledge or is able to exercise a specified set of skills. In a sense, some university programs are training people in the relevant skills for a job and successful graduation can be thought of as a kind of certification. Some candidates for a job, however, have entered the field from other fields and many university programs cover portions of the practice of UX but not all the areas that may be important for the most successful practitioners.

Certifications are often talked about as demonstrating the qualifications to perform a certain job or task and may be treated as a method of protecting the public interest. As a result, there are many certifications in the engineering field. There are certifications sponsored by IEEE, that show engineers have a comprehensive understanding of a fundamental set of principles identified as representing the best science in the field (e.g., the Software Engineering Body of Knowledge), and there are certifications for special areas within the engineering profession.

Certification can be controversial because it does not guarantee the quality of the work produced by those certified. In discussions among usability people, for example, you often hear “How dare they claim to determine whether I am going to be good or bad at my job! My work speaks for itself!” On the other hand, many employers and professionals in the field complain that they see many usability people who have virtually no understanding of the human factors basics that influence what makes a design good or bad; human-computer interaction (HCI) principles that specify good design; or even the proper, unbiased application of the range of formal methods they claim to use.

I cannot tell you how many times I have asked someone “Do you know how to do contextual inquiry?” and the response is “Yes, I have done field studies.” It turns out they have no idea what the formal elements of a contextual inquiry are. These people feel the power and the confidence they get when doing a user study, so they are absolutely confident they are discovering truth. Without being sensitive to and practiced in the concepts of control, reliability, validity, and generalizability they may inadvertently be missing what they should be finding, and without the formal background in human factors and HCI they can make design recommendations that are less than optimal. They are confident, and because of the power of engaging people in the process they often please their sponsors. They often also find some of the most obvious problems (how could they help it), but they may not discover the most important issues. It is not too surprising that the reliability between usability researchers testing the same system is often low. If the basics were well defined, and if professionals had the foundation of those basics, the field would enjoy a stronger reputation.

At this point there is a bigger problem in the field associated with this uneven expertise among practitioners. It is hard for many companies to know the difference between good user experience and bad user experience, and what it takes to create it. That is probably part of why the staying power of UX programs depends so heavily on champions and why it is so difficult to find any kind of return on investment (ROI) narrative that is persuasive, even when we know the tremendous business impact that user experience can provide when done well. As long as user experience appears to be more art than science, and as long as some professionals try to keep it that way, it will not be viewed as predictable a business value as engineering, and companies will not look for certification to ensure people have the foundation to do the job well. At this point, certification is sought largely for jobs in the government, safety, and hardware design areas. Consultants use it as a way to distinguish themselves from competitors as well, and job candidates may similarly use it as a selling point when the hiring manager is sufficiently knowledgeable to understand what they are seeing and how to interpret it.

In engineering, certification is quite common. IEEE certifies software professionals (the Certified Software Development Professional), the Society for Professional Engineers has a certifying body, and the British Computer Society has just developed a Chartered IT Professional certification. The Software Engineering Institute has certification for security, process improvement, and software architecture. There are certifications for best practices such as the Six Sigma Black Belt. There are also corporate certifications for platforms and tools (e.g., by Microsoft, Apple, Oracle, and Cisco). There are third-party and vendor-neutral certifications (e.g., the XML Certification Program and the Linux Professional Institute).

For managers, certifications are like other records of education and training and should be evaluated in the same way. Look for the nature of the certification, who is doing the certification and their qualifications, the confidence you can have in the certification process, and what is actually being satisfied. There may be areas where you may want to require specific certifications. For most of us, certification is one of the pieces of information that helps a candidate stand out from other candidates, and suggests additional steps the applicant may have been willing to take to demonstrate what he knows. Managers may use certifications as part of career plans for their employees. It can serve as evidence that an employee has been successful in growing his knowledge in a particular area.

Certification may be a step that people outside the field use to build credibility for moving into the field. For example, I have known several technical writers who have a bachelor’s or master’s degree, and who want to move into interaction design, or information architecture, or even usability. I have also known computer scientists in development teams or in project management roles who similarly want to move into user interface roles. In these cases, they sometimes start by jumping in and gaining experience, educating themselves through reading and community activities (e.g., listservs), and perhaps taking the University of Michigan Human Factors Engineering Summer Conference, other conference training, or consultant-run seminars. But when they want to move more formally into the field and show what they know, they look for some kind of certification that does not require them to quit their day job. In the Seattle area, that typically means getting the University of Washington Human Centered Design and Engineering user-centered design certificate.

There are a variety of ways people can be certified. I have been involved with the BCPE, which was created as a certification driven by the profession itself. It was established in 1990 as an independent non-profit organization and aims to certify individuals whose education and experience indicate broad expertise in the practice of human factors, ergonomics, and UX in a variety of human-systems interaction design areas. It certifies, but it does not train. It provides direction through the Ergonomics Formation Model, which is designed to be an architecture describing the range of knowledge that makes up the ergonomics or user-system design field. Over 1,500 professionals have successfully met the certification criteria and been awarded one of the credentials offered representing a cross-section of active professionals who are also members of the societies that make up the field. The BCPE is governed by an elected board of leading professionals. It is managed by a full-time Executive Administrator and a Financial/Information Systems Manager. It is endorsed by the International Ergonomics Association and is a corporate member of the National Organization for Competency Assurance (NOCA), which is a U.S.- based organization that provides best practices and support to certifying bodies. In March 2009 the BCPE became accredited by the National Commission for Certifying Agencies.

The University of Washington Human Centered Design and Engineering Department offers a full set of courses designed to provide working professionals with skills in two key areas: user-centered design and technical writing and editing. A certificate in your specialty area is earned when the training is completed. This training program is less extensive than a full degree, but is an excellent complement to an already existing degree and can prepare the professional for the UX field. I have known several people entering UX from other fields who have gone through the training and have been successful as designers and researchers. There are others who have taken the training and have exercised their unique understanding of UX in areas such as project management, development, and technical writing.

Human Factors International’s certification is aimed at usability analysts. The exam can be taken without the training, but training is also offered that prepares you for the exam and provides an insight into the focus of the certification. Courses include: user-centered design and conceptual design, Web design, practical usability testing, and putting the principles into action. The courses (and I would expect the exam) are designed around the approach that Human Factors International has built into their consultancy.

Figure 2.3 was created by a list obtained from the BCPE and shows a variety of available certifications. When you find a certification on a resume or explore a certification for continuing education for an employee, the questions you have to ask include:

Once you decide to hire someone and make an offer the question then turns to the offer itself. It may be made up of a variety of factors including salary, projected bonus, stock or stock options, other benefits, and subsidized moving costs. The offer is usually developed in collaboration with your corporate recruiter or someone from HR and is influenced by where you believe the candidate fits within the career ladder and what it will take to hire them. The recruiter has attempted to find out what the person wants, what they are currently earning (and their cost of living), and their relevant background for positioning them on the ladder. The recruiter may want to save the company as much money as possible by offering a low salary (although they are often also given incentives to make successful hires). But as a manager you know what you want them to do, and where you think they will fit on the ladder. You want them on your team.

You are now convinced you want this person and want to do what you can to attract him to the job. Still, you do not want to hurt the applicant by paying him too much at the start. Unless the new hire turns out to be an absolute superstar, if you pay them too much only small raises will be given until he is more in line with the existing employee salary structure and they will, as a result, be unhappy. You also do not want to get a reputation with your existing team for giving new people higher salaries than those who have been at the company for a while (this can happen if the company has been holding costs down or focusing on rewarding only the very top employees).

Your best bet is to pay on the low side (not so low that it is hard to get them up to the average over time), and offer larger raises than expected in the early days as the applicant settles into his job and shows his value. The raises will make him happier and bond with the team. It also gives you more tools to reward the right behavior and, if needed, to hold back if things are not going well.

Overlaid on this dialog are the corporate targets. At several of the companies I have worked at there has been a philosophy of not paying top dollar, but rather being competitive by paying at around say the 75th percentile when hiring, and then differentiating the salaries of high and low performers over time. These companies intend to attract and differentiate by the supplemental benefit packages they offer, as well as the work environment and the job itself.

It is worth imagining what candidates may be thinking as you or the recruiter are negotiating with them. When I was exploring one job, I had excellent discussions with a colleague who had been the head of HR for a previous company we had been at and who had been laid off himself. I asked him about the salary negotiation process and his advice was to not focus so much on a specific number being offered but to think through what I thought I needed and wanted in order to make the new position worth taking. I was then able to express my desires for a specific salary, but also to share my major pain point. At the time the pain point was the prospect of carrying a mortgage on a house that was not likely to sell soon while having to buy a second house for the new job. The company was then able to come back with an offer that was not quite at the salary I wanted, but they were able to pay for a longer stay in interim lodging than normal, and they offered an extra-large signing bonus. With that larger signing bonus, they arranged with a mortgage company to help me get a loan and buy down the points to a very low starting level. When working with the recruiter think creatively. Explore all the tools you have available for attracting the candidate and keeping them happy as they get started in the job.

If you are the first UX person in a company and are starting the program there, you may have to drive change in the HR area. The companies where I have worked have tended to be engineering companies. At some of these companies engineers with qualifications and responsibilities equivalent to UX people have been paid more. This is often explained in terms of supply and demand. There clearly have been points where there were a lot of UX people on the market relative to the number of potential openings, and there has been a shortage of engineers. But the inequality in salaries has a way of impacting a variety of downstream processes such as attracting talent, building a compelling environment, career development, and performance reviews.

One path is to try to drive the HR team to conduct a salary survey, and then to shape the survey so it evaluates UX salaries more fairly. The team doing the survey often benefits from an education about what UX roles involve, the typical backgrounds, and where the competition is for those you are trying to hire. Another source for potentially useful information can be salary surveys conducted by professional societies. The American Institute of Graphic Arts (AIGA) and HFES, for example, both regularly conduct salary surveys. It may take effort to draw the line between how the society categorizes respondents and the particular classification used for UX people within your team. A key argument is that you want your UX professionals working at a given level to have the same kind of business impact as other engineers at the same level, so both should be paid roughly the same.