Jared Spool says it’s important to focus on the ‘comb-shaped’ professional, rather than the ‘T-shaped’ professional when building a skills-based team. Which, simply put, is a generalist. He disputes that notion by saying a generalist is “equally good at all things.” This is an erroneous assertion that only leads to a debate over semantics, so I’ll digress. No matter if you call it comb-shaped or generalist, a UX professional that can span the UX spectrum from research to design, or some portion in between, is often times more valuable than a specialist.
“…it is valuable to a product team when you can bridge the gap from one skill to the next.”
This is not to say a specialist isn’t worth their weight in gold in a given situation. I’ve know pure researchers and pure designers who could run rings around their generalist counterparts. However, the specialist is often not required to complete the task at hand, depending on a multitude of variables. Furthermore, the specialist roles can lead to a mini-waterfall hand-off from insights to solutions. My preference is for my team to have skills that bridge that gap from problem space to solution space. I like to see an interaction designer with solid research skills, or a UI designer with coding abilities. That is not to say you have to be a unicorn, but it is valuable to a product team when you can bridge the gap from one skill to the next. Some of the best researchers I’ve ever worked with used to be designers, and that knowledge and ability helped to make them better researchers, as a result.
While my preference is toward the generalist, the team makeup must fit the project needs. I have been very fortunate to work with great specialists and generalists over the course of my career, most notably at my current company, Ventera. Due to the large and complex subject matter we tend to face on some of our government projects, specialists, researchers in particular, are integral to our success. I would not trade them for the world. However, most roles still benefit from an overlap in skills, and offer greater value to the product teams as a result.
written by Shane Close, originally appearing here