team meeting
PHOTO: Climate KIC

“I really love the idea of our engineering teams working more with UX, and I want to push for this at my job. Which of the people already working at my company would make the best UX worker? Maybe a business analyst or a product manager?” This question came from an engineering conference attendee for the UX speaker.

It may sound obvious, but the best UX worker is a UX specialist, hired because of their experience and expertise with specific processes and approaches. 

Why do we continue to promote the idea that everybody on a software development team should have all of the skills for all of the roles? “Somebody who has specialized in a particular domain is much better at it than someone who is learning it for the first time. A team made up of flexible people with complementary specialized skills is much better than a team of generalists. But the specialists must be prepared to cooperate with the rest of the team, to teach their skill to other team members and to play other roles in the team when required to get through a bottleneck,” according to a business agility consultant on LinkedIn.

The consultant is implying that if you don’t believe you should teach others your job, you are uncooperative. Another assumption is that everyone on the team will have the same natural talents, ability to learn and be equally good at UX tasks. Ideas like this also ignore the inefficiencies engineering will have to face when team members are taken away from their story points to “do the UX.”

All of the flexibility, cooperation and desire to solve a bottleneck won’t matter if we are giving unqualified teammates work outside of their area of expertise or capability. Amazingly, agile and scrum are often hungry to give engineers “UX/UI” work, yet when an engineering bottleneck arises, nobody rushes to teach the visual designer some coding. Does anybody want to quickly upskill the UX researcher to also handle some DevOps? Didn’t think so.

UX Is a Core Value Creation Function

If our cross-functional teammates understood UX, its importance and the customer value we are driven to create, they would see that UX goes way beyond asking customers questions or sketching some screens. They would want it done by qualified specialists.

If it’s people over process, we need to care about which people are doing which elements of the process. We must upgrade our definition of “done” to include depth and quality. It must be done well or else we shouldn't consider it done. Your customers will not praise you for getting it done if they hate or struggle with what you release.

Agile teams can go quickly from planning to designing to coding to testing to done, but no rule says this must all be done by one or more frantically juggling generalists. We will get the best product and outcomes when we play to people’s strengths.

Related Article: Design Thinking Isn't User Experience

Domain Experts Should Decide What's 'Good Enough'

T-shaped competence means someone is an expert in one area (the long bar of a capital letter T), while the top of the T refers to the ability to collaborate with experts in other areas and a willingness to use the knowledge gained from this collaboration. The top of the T connotes capability, not expertise. For example, someone might be an expert in interaction design and good with UX research, and call themselves T-shaped.

The concept of T-shaped gets a little fuzzier when used by people promoting agile software development approaches. You might hear that having all team members be T-shaped will improve collaboration, productivity and reduce the dependency on specific individuals. This typically assumes the short bar of the T will be something you can do well enough, and often involves non-UX roles doing UX well enough to get work done.

Again, this works when we have low standards for what we consider “done.” The domain experts should be the ones deciding if others have good enough skills, talent and experience in that domain. We don’t want a Scrum Master deciding which UX tasks a developer without UX talent, skill or experience can do. A UX expert must decide who can do UX well enough.

Related Article: Should a Project Manager Become a Scrum Master?

Swarming Is an Option

If there is a bottleneck, swarming is an option. Like pair programming, this is where two or more engineers might work on the same user story to speed up the work. If there is a UX bottleneck, allow UX to swarm with other UX practitioners. See if someone else from the UX department can lend a temporary hand, allowing specialized tasks to be completed by qualified and knowledgeable people.

Like “good enough,” swarming only makes sense when it includes people who can do the work well. You wouldn’t drag in your marketing teammate to quickly learn QA testing and automation because there's a bottleneck there.

Related Article: The Collaboration Problem No One's Discussing

Reducing Defects

We must stop telling ourselves that work will only get done efficiently when everyone becomes a generalist, or when we all learn each other's skills, or when people outside the specialty take on the work. It may sound great in theory, but ultimately makes no sense if you consider realities and outcomes.

When a product is poor, customers notice. Lean, agile, Six Sigma and others are aimed at working efficiently but being dedicated to higher quality and reducing defects. Teammates must learn that UX tasks aren’t grunt work that anybody can take on. If we want our products to provide a less defective user experience, we must leave that work to specialists.