Ask DN: How do you work with development teams as a designer?

over 3 years ago from , UX Designer

I'm a UX designer embedded in a semi-agile team (we have standups and retrospectives, but don't do everything to the letter). I find I do a variety of things, like logging bugs and helping with customer support, that don't fall under the typical job description of a designer. Sometimes, I feel like this helps me learn more about the product and the user base. Other times, I feel like it's a waste of time that I could be using to do research or design (i.e. the tasks that I was hired for).

If any of you work closely with or are embedded in a development team, how do you contribute to the team? What do you do that helps you mesh with the team better while still leaving plenty of time for design?


  • Jeff Zych, over 3 years ago

    At Optimizely, engineers are on teams that use a scrum process to manage the work and deliver it to customers. Designers are paired with PMs and work with the engineering scrum teams to ship work, but we manage that work differently from engineering work, since it's a different type of work. We use a discovery process that gives designers and researchers time to understand the problem and explore solutions, before we commit to engineers building it.

    This doesn't dictate the type of work you're doing, but it does set clearer expectations between engineers and PMs about what designers are doing and what the deliverables are.

    I wrote an article about our process here: https://medium.com/design-optimizely/discovery-kanban-at-optimizely-7b3025066d54#.z9qv9ny1p

    2 points
  • Ix TechauIx Techau, over 3 years ago

    "Other times, I feel like it's a waste of time that I could be using to do research or design"

    Wearing many hats makes you more well-rounded in the long run. Being a designer in a small team often means you'll spend at least a third of your time not designing, it's just the way it works for the most part. As you say, logging bugs and getting involved with customer support results in you learning more about the product, which then helps you designing for it in the future.

    Knowing the product inside and out is the best starting point for design. The research you think you're missing is actually not missed at all - you're doing it while bug hunting or talking to customers.

    1 point
    • Thompson GeorgeThompson George, over 3 years ago (edited over 3 years ago )

      I Agree.

      Logging bugs and getting involved with customer support is likely the best form of research you could do? You have your users and their problems right in front of you.

      What else would you be doing, reading some poorly written Medium article?

      0 points
      • Caitlin G, over 3 years ago

        You're both absolutely right. I've spent too much time lately reading poorly written Medium articles because there's not been much design work that's needed immediately. I spent most of today logging bugs and feature requests in Jira, which somehow feels a lot more valuable. Imagine that.

        In the past, however, I've had a lot of design work and have gotten sidetracked by other work (mostly customer support-related) which has kept me from getting the design work done on time. I haven't decided how much of a problem that is, but my instinct is to want to prioritize design work since there are fewer people at my company who can actually do it.

        0 points
  • chetty arun, over 3 years ago

    At the startup that I work for, we don't have PMs. We (designers) work closely with the front-end team and one of us take the responsibility of the entire project (which removes the need of PMs). Not even a single decision goes without discussion. Right from the start of the project the front end team has the knowledge of our designs and we have a basic knowledge of how they are going to implement it. Everything goes in sync. This helps us a lot. This doesn't make us "Freelancers" in a company.

    As for the time allocated to customer support, logging bugs etc, we do it too and it helps a lot. Customer support gives us knowledge on what the customer wants and what all problems is he/she facing and how can we solve it through design. Everyone in the design team has access to our GitHub where people can file an issue if they face a bug while testing. We do extensive testing before shipping a product and help the development team with finding the bugs.

    0 points
  • joe andersonjoe anderson, over 3 years ago

    How big is your company and the team you work on?

    0 points
    • Caitlin G, over 3 years ago

      My company's medium-sized (around 150 people), but the product / dev team is small. For 4 products, there are about a dozen developers, 3 PMs, 4 QA, and 2 designers (of which I am one). I spend most of my time as an embedded designer for one product, but jump around to other products and projects as needed. The dev team for my product consists of 1 PM, 4 devs, and 1-2 QA.

      1 point
  • Ben S, over 3 years ago (edited over 3 years ago )

    Everything we do is taken from the chapter on integrating Lean UX into Agile in the book Lean UX, as that was the inspiration for how we work.

    As a designer/team of designers, the single biggest area of friction is the 'why' of your work; what are you trying to achieve with your designs, why is this element here, etc etc. It is imperative to work side-by-side with the people who will be developing the feature to ensure they have buy in and empathy for what you as a team are trying to achieve, as then they will work harder to produce what has been envisioned.

    Work in cross-functional teams, with all of the dev/QA and design roles present throughout the lifetime of a feature (for us it's 1 UX and 1 UI designer per team of 5 devs, normally). Have a feature kick-off where all the ideas and assumptions you have are brain farted out. When you test assumptions with users always have at least one other member of the team with you to understand the constraints we face or mistaken assumptions you've made. As you iterate through MVPs review them and comment on them as a team.

    The biggest change for us was regarding job titles as competencies, not roles; I'm not the only person who can interview a user or draw a box, and similarly I can code to a prototype level quite comfortably. Being less precious about who does what really helped the team grow as a team rather than a group of people doing different stuff.

    Seriously, the Lean UX book changed my life. I'd highly recommend it.

    0 points
    • , over 3 years ago

      That book has been sitting on my desk for over a year now, and I still haven't finished reading it. I'll get on that, thanks!

      0 points