How I think about design specialization.
If you have a hard time understanding design roles, here’s a shortcut: design is a spectrum from conceptual to practical.
Research → Experience → Interface → Prototyping
Research is where you gain detail on your users and the challenges they face. A talented researcher will uncover insight and empathy by monitoring and interviewing users. They’ll build tools (e.g. user personas) that will ground your team in a deep understanding of the problems you’re solving.
Experience covers the pattern of interactions, feedback, and information that define the way a user will engage with your product. Experience designers produce wireframes and flow charts that choreograph a user’s journey from their first impression to their mastery of the product.
Interface designers create visual components and screens that influence the look and feel of your product. They work with color & contrast, visual hierarchy, and animation to create a blend of familiar interactions with a unique visual identity.
Prototyping provides the team with interactive mockups for testing and iteration. Prototypers work in code or using specialized tools to quickly create experiences resembling the end product closely enough to test with users in context and rapidly iterate.
Most designers working on product teams will have expertise somewhere along this spectrum. In most cases they’ll also have some skills in adjacent domains, for example many experience designers have skills in interface design or user research.
How is this useful?
This is a quick way to understand designers and design teams, their strengths, and any gaps that might exist. If you’re a small company looking to hire your first designer, then it helps to understand which set of skills you’re looking for and which candidate is the best fit. As you grow your team you can use it to balance complimentary skillsets. At Human Collective, when we’re helping a client decide where at start, we always recommend hiring from the inside out and maintaining a balance that matches their needs.
A word of caution: any useful model is a generalization, and is therefore destined to be wrong around the edges. That said, I’ve found this to be incredibly useful when explaining design roles to non-designers.