Configuring a UX team – are "super designers" the way to go?

To see what new UX projects ICS has been working on, come by our booth at DESIGN East September 18 and 19 at the Hynes Convention Center in Boston.

At ICS, we’ve cultivated a cross-disciplinary UX team. To be more specific, everyone has UX skills of some flavor and everyone has at least some experience with coding. To be even more specific, some of us are designers that learned to code and some of us are engineers that acquired UX skills.

One can imagine numerous advantages with this team configuration, such as better collaboration between designers and developers and more flexibility in resourcing staff. Seems quite ideal on the face of it.

Jared Spool, in his article, Why The Valley Wants Designers That Can Code, makes the point that hiring managers, particularly in start-ups, perceive “super designers” (designers that code) as the ideal way to go. Since startups tend to run lean, they can accomplish a broader range of tasks even with scarce resources. However, designers themselves are split on the opinion of whether super designers can fight for the needs of the user.

Each discipline – usability and engineering – serves a different god, so to speak. When you design interfaces, you prioritize the users’ needs; when you write code, you optimize for the technology. These often are in direct competition with each other. Designers are always asking for simplicity of usability, which translates into lots of iteration. Programmers want simplicity of programming – a spec that doesn’t change.

You might think that all conflicts are solved between design and development if you employ people who have skills in both arenas. But I wonder, does a designer/programmer present a conflict of interest, like a lawyer representing two clients battling over the same inheritance? In a realm where technology holds so much power, will user priorities have the opportunity to be presented vigorously enough.

Jenifer Tidwell (a super designer herself) states in her blog entry, Designers that code: a response to Jared Spool, that while working in a large software company, her programming skills were more highly valued than her UX skills. Her time ended up being more programming heavy and design lite. This unfortunately is the reality – you can ship a product with a bad UX, although your customers may disappear, but you can’t ship a product if the code doesn’t work.

So, hiring managers see a super designer as a potentially more valuable employee. Meanwhile, designers are split on whether super designers can effectively do both. But, what is the best team configuration to achieve a good end product?

Here’s what I’ve observed:

There are circumstances where design/build skills classically work well – technology research, as well as developing product concepts and prototype building. Here bugs and the small details of usability don’t matter much; what does matter is finding ways to synthesize technology and usability.

On a small project, cross-discipline individuals offer more skillsets to a small team.

However on large projects, specialization leads to a higher level of professionalism in each aspect of the final product. If you have a larger team, ideally you want individuals who bring deep, unique skills. You want an animator designing the animation, not a UX designer who made a Flash animation once for a class assignment.

On any project, good communication is paramount. When two disciplines each have their own professional jargon, a cross-discipline individual has more potential to speak the language of both. Thus they can potentially communicate more successfully with team members and customers.

Cross-discipline skills have worked well for us at ICS, because we work on a variety of projects – large and small, research and end-user. A small project may get one super designer. A larger project may require that we each specialize in a particular skillset that we possess, such as wireframing, information architecture or graphic design. We continue to evolve our team and fight to make sure that we are not letting the programming take away from the usability.