Why Designers Should Code (But Shouldn't Push Code to Production)(jlzych.com)

almost 6 years ago from Jeff Zych, Head of Product Design at LaunchDarkly

  • Ethan BondEthan Bond, almost 6 years ago

    Kind of a shame to see such a well-considered and approachable argument followed up by a totally unexplained and arbitrary caveat.

    Because a person's job title has "designer" in it, they shouldn't be able to push to production? Hiring UI engineers (a decision I agree with) does not, in any way, change the impact that a designer can have in the codebase. They're independent variables.

    If you can't write production-worthy code, then don't push to production.

    4 points
    • Jeff Zych, almost 6 years ago

      The point isn't that designers can't write production code ever. But if they're expected to code their own designs, then that isn't a good use of your designer's time, nor will you have well architected frontend code. You should have full time UI engineers writing most of the code.

      But if designers want to make smaller changes, like tweaking CSS and whatnot, then that's fine. Does that make sense?

      1 point
    • Aaron SagrayAaron Sagray, almost 6 years ago (edited almost 6 years ago )

      Not addressed in the article, but alluded to: A big part of a designer's job is to be a bridge between customers and implementation engineers by providing insights to engineers that customers have expressed. Call it "manufacturing empathy" "customer discovery" "usability research" – or whatever. They are subsets of the same core task.

      This task requires that the design team spends significant time out in the field with customers doing research – and only then producing design solutions. That doesn't leave a lot of time in the day for production implementation.

      I agree with Jeff that a designer must have a basic understanding of software engineering in order to empathize with the implementation team, and work within their platform constraints.

      Small teams are often forced to draft anyone who is able to produce production code, but it doesn't scale long term. As an org becomes larger, it's a better use of time as a designer to be a bridge.

      1 point
      • Jeff Zych, almost 6 years ago

        Yep, completely agree

        0 points
      • Alastair TaylorAlastair Taylor, almost 6 years ago

        This all really comes down to resource though. It has very little to do with the skills of designers being good enough to write production code. If your team has loads of research experts, is it a good use of designers time to conduct the research when they could be concentrating on digesting that research and turning into something that works?

        My design team works on research, visuals and often writes production code and we're lucky enough that we're in an environment we can do all of that, and still meet the deadlines that the business expects.

        Agile has the concept of a specialising generalist which when you think about it from a designers point of view means you can conduct research, create designs, or write production code, all based upon what the project demands at that point.

        0 points
        • Jeff Zych, almost 6 years ago

          Yeah, I agree with all of this.

          These recommendations are tough because every person and every team is different, hence the backlash against my pithy claim. I meant for that to be a guideline, not a hard and fast rule, but I clearly worded it too strongly :)

          0 points
          • Alastair TaylorAlastair Taylor, almost 6 years ago

            I think people (myself included) tend to get very defensive when somebody says "you can't do that". It's a good discussion point though, and something my team has been debating too. Good to keep debate in the industry :)

            0 points