This is the second in a three-part series on how to build and grow successful user experience teams in agile environments. It covers challenges related to organization, hiring and integration that plague UX teams in these situations. The perspective is that of a team leader, but the tactics described can be applied to multiple levels in an organization.

In part 1 of this series, we discussed what kind of organizational structures and attitudes are needed for agile and UX integration to take root. The third and final section will deal specifically with how to integrate the team. In this section, we’ll discuss hiring. As you build and grow an agile UX team, hiring becomes a central point of impact for the team. Understanding what to look for in designers and how to assess their potential success (or failure) in your agile environment can be tricky. In addition, not all (and potentially none) of your legacy designers will integrate with the agile methodology. Here are a few ways to go about it.

Agile Designers Are Hard To Find

Anyone you add to your agile UX team must be willing to work collaboratively.

Simply advertising “agile” in your job description will not drive enough interest from designers who actually have experience with the process, mainly because many designers with at least five years of experience have never worked this way. Also, the proliferation of interactive agencies has produced a huge swathe of designers who have partnered with developers but have minimal experience. When you first meet a prospective member of your UX team, it’s critical to get an understanding of how they approach two things: the concept of “team” and problem-solving.

The Devil Is In The Transitions

To assess how they feel about working on a cross-functional team, go through each employer on their resume to see where they fit in that organization, what their impact was and, most importantly, what triggered their departure from the company. The transitions will often tell you exactly what drove the separation between those companies and your candidate.

Handling Criticism

One warning sign to watch for as you probe their resume is difficulty with taking criticism from beyond the design team. This could foretell of potential challenges with integrating with a scrum team down the road. Feedback will inevitably come from non-designers. If there are already signals that the candidate does not take this type of feedback well, then consider someone else.

Hero Designers

Next, keep an ear out for rock-star syndrome. If the transitions in your candidate’s career were driven by “too much criticism” of their work, or an inability to build the designs they came up with, or a propensity to simply leave a job if the chemistry wasn’t immediately there, then you may be dealing with someone who believes they are a hero designer. Hero designers are problematic in agile environments because agile is distinctly anti-hero. It promotes the concept of the team (not the individual designer or developer) as the smallest unit of labor, and it focuses on that team winning and losing together. A hero designer will undoubtedly upset that dynamic by wasting energy and time on unproductive conversations. Hero designers struggle to collaborate and share their work productively.

Job Transitions

Finally, when discussing job transitions, be wary of frequent changes of employer. The risk here is that your candidate is unable to gel well with their teams. If it has happened once or twice, it could simply have been a coincidental matching with bad teams. If it has happened more than that, though, the issue will typically be with the designer. Maintain a line of questioning around those transitions to see if you can notice any anti-team patterns.

Problem-Solving Over Portfolios

Understanding how your candidate solves problems is the next big hurdle. A portfolio can provide evidence that the designer can create an aesthetically pleasing experience, but it doesn’t speak to the problems that those designs actually solved. Portfolios should be treated as conversation starters. The ubiquity of design tools makes it relatively easy for any designer to “draw a straight line.” Ask your candidate to pick the project on which they feel they had the most impact and to walk you through the problem statement, their approach to solving it, their contribution to the project and the result.

Going through the project’s entire lifecycle will show you where the candidate is strong. Do they engage right away at the problem-statement level? This is critical in agile because you’re constantly working to validate your hypotheses for the solution. Can they articulate an understanding of the target audience when promoting a solution? Again, knowing the customer will help to drive more value to that customer faster: a core agile tenet.

Finally, how interested are they in the success of the implementation? If they are comfortable launching a product without wanting insight into how well it’s performing, then they’re likely not a good fit for your agile UX team. Having an interest in the efficacy of their solutions is imperative. In your agile shop, they will be iterating on their work based on this performance data. An innate curiosity here signals a potentially worthy candidate.

Spend Some Time Together Outside Of The Interview

In assessing how well the candidate will integrate with your team, a critical interview tactic is to plant them with their prospective teammates. This could be as short as an hour-long exercise or even as long as a full day. Have the designer join in on the team’s activities, and ensure that those activities include whiteboarding, brainstorming and general team-wide problem-solving exercises. This tactic will reveal as much about the candidate’s skills as it will about team chemistry and likability. Ultimately, as the hiring manger, you won’t be working as closely with this person as the team will, so let their opinions shape some of the process of deciding on the candidate’s viability.

As a final assessment, have a developer interview the candidate. Like the others, this tactic will reveal several things, including the designer’s ability to communicate with developers. Can they communicate effectively with team members from other disciplines and create a meaningful conversation around the problems that the team is working to solve? Can they inspire the developer through a previous team’s win (or loss — as long as the candidate focuses on the lessons learned)? This final interview should shed more light on the candidate’s chances of success in your agile environment.

Conclusion

Agile UX team hiring is similar in many ways to any other UX hiring activity, with some key differentiators. Besides assessing the designer’s skills, it’s imperative to understand how well they work with a cross-functional team. The tactics mentioned in this article will provide insight into the designer’s mindset and can serve as predictors of their success in integrating in your team. What tactics have you used in interviews to understand the candidate better?

You’ve set up the right infrastructure and hired the right team. In the third and final part of this series, we’ll discuss how to integrate these elements into a productive team.

(al)