The Choice of Two Teams

Jared Spool

June 1st, 2011

[Continuing on the theme of designers who can code.]

If you’re a designer, imagine you had a chance to work with two development teams.

Team 1: One team has top-notch developers who know virtually nothing about design. They can code miracles, but the designs of their applications are horrible and frustrating to use. And they show no desire to learn anything about design — how it’s done, why it’s important, and what makes a good design versus a bad design.

Team 2: The second team also has world-class developers, but these guys are hungry to learn about design. They’ve already taught themselves a fair amount and are truly interested in learning more. In addition to producing amazing code, they are regularly producing applications that look good, work well, and delight users.

As a designer, which team do you think would more fun to work with? The team that has no interest in designing or the one that really enjoys it?

Practically every designer I’ve talked to about this choice has told me, without hesitation, they would love to work with a development team that appreciates good design and wants to learn more about it. Those designers won’t be constantly battling for the simplest of design choices, instead be focusing on the hard problems with a group that wants to see the best outcomes.

Guess what? Developers feel the same way. If they had a choice, they’d rather work with a design team that understands development and craves to learn more, than with a team that doesn’t make any effort to learn what development is all about. Not just simple front-end coding either. They want to work with designers who understand the architecture and infrastructure, who can relate to the challenges they are up against and can appreciate it when the team has pulled off something amazing.

Learning to code doesn’t just give you new skills, it makes you a more desirable team member.

10 Responses to “The Choice of Two Teams”

  1. Bryan Says:

    This has all the markings of a strawman argument, but sadly it needs to be said. People generally want to work in an environment where there is mutual respect between discplines, it’s the assholes who don’t that mess it up for everyone else.

  2. UrbanImpressionist Says:

    It’s a very valid point, but… I’d like to see a topic on why often even the second team has such an unbalanced ratio of devs to designers. How do companies think they can accomplish a well thought ought project and quickly, with a 6 to 1, or 12 to 1, or even much greater ratio? Why is it common assumption that far more devs than designers are required!? (tongue in cheek) Are devs not as smart and capable as designers?

  3. The Choice of Two Teams at myninjaplease Says:

    […]> […]

  4. Jonathan Says:

    Are actually teams like these? In the last 10 years I don’t think I’ve seen either of these teams in the wild. At least not in web development shops (I’ve not worked at IBM or C&W though so maybe that’s the issue).

    @UrbanImpressionist: the imbalance is because development is unfortunately rather more time-consuming (and possibly more complicated) than design in most cases. It might take you a month to research, design and produce a design solution, but for a developer to get it all working might take an order of magnitude longer than that.

  5. UrbanImpressionist Says:

    @ Jonathan I have to disagree. That’s the kind of misnomer which hurts design and the development process. Often development takes more time because of scope creep, mgt indecisiveness, and (relative to the conversation) lack of quality, universal, detailed design direction. I have often seen devs take long to complete tasks because they had to do superfluous work that could have been avoided if the team had a greater design presence/effort.

  6. Anne Gibson Says:

    @Johnathan I believe I have the dubious honor of working with both types of teams in my day job right now. (I’m an interaction designer at a big financial firm.) One team actively argues over any design decision that makes coding harder – even if “harder” is “put the new data row in the middle of the table with like data”. The other seeks me out for guidance on anything that goes near the UI if they need to think through a problem. Since they’re both working the same project, I started with both teams at the same time, & neither team knows I have a master’s in software engineering, I can’t chalk the difference up to anything but personality.

  7. Kevin Says:

    I’ve found that thinking like a user often means forgetting the architecture, the infrastructure, the engineering challenges (which I do understand because I’ve written code) and looking at the product “naively.” The insistence that UX designers understand the code seem quite similar to the unrealistic expectations that developers have of user sophistication. To me, the whole point of UX is to use naivety and unsophistication to help guide the process.

    I think Jared has been told by some developers that the friction between designers and developers is because the developers feel unappreciated and misunderstood, and if only designers would learn to code and appreciate the developer perspective, the friction would go away. As a UX designer with a computer science degree, this hasn’t been true for me. I haven’t found that less technically-inclined UX designers on my team had a harder time working with developers than me.

  8. Jonathan Says:

    So as Bryan says in the first comment – people prefer to work with other people who respect what they do.


    So – if you’re a UXer and you think developers are lazy asshats – repent!

  9. Igor Says:

    The engine (underlying code) and the form (the content and representation) should be separated from scratch as two different layers. Developers code and the designers do the interface without affecting each other. Sure, one our of ten developers can contribute to interface design (e.g. myself, he-he) and one out of ten designers can contribute some coding ideas, but that’s not the goal or even a typical situation. So, separation is the way – both teams are happy doing what they love, may they never meet 🙂

  10. Davide 'Folletto' Casali Says:

    I think there’s a third kind: a team of developers that take pride of their work, but while they aren’t interested in design at all (“I don’t get it”, “I’m not able to do it”, …), they are keen to work with a designer because they respect that work and know it will make their app better. I found teams like this. 🙂

    In the end, I think that it’s not a matter of skills or will to learn, but a matter of respect: if as a designer I respect developers, it doesn’t matter if I know or don’t know about developing. The reverse is the same: if as a developer I respect designers, it doesn’t matter if I know or don’t know about designing.

Add a Comment