Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Curious Incident of the Developer on the Design Team

The Curious Incident of the Developer on the Design Team

Getting developers and designers to talk to one another is hard enough. Getting them to get along is even harder. Our talk is about how we approached this problem at Twilio.

Danielle Leong

February 26, 2013
Tweet

More Decks by Danielle Leong

Other Decks in Programming

Transcript

  1. THE CURIOUS INCIDENT
    OF THE DEVELOPER
    ON THE DESIGN TEAM
    THINKING IN THE SAME LANGUAGE
    1
    Tuesday, February 26, 13
    We are here today to talk about improving developer/designer relationships. This talk, The
    Curious Incident of the Developer on the Design Team, is how we approached the issue of
    being able to think in the same language.
    This talk was held on Tuesday, February 26, 2013 at Twilio HQ, 501 Folsom Street, San Francisco, CA at 6:30p.
    http://www.eventbrite.com/event/4537648228

    View Slide

  2. DANIELLE LEONG
    DEVELOPER
    @tsunamino
    NINA MEHTA
    DESIGNER
    @ninamehta
    2
    Tuesday, February 26, 13
    Danielle Leong is a Front End Web Developer at Twilio. After graduating UC Irvine for
    marketing, she taught herself to code and joined the Twilio design team as the company's first
    female engineer. She specializes in responsive site and email creation, company branding,
    and fights the good fight for better cross-browser compatibility. In her off time, she teaches
    latin dance and bakes gourmet cupcakes. Follow her on Twitter at http://twitter.com/tsunamino
    Nina Mehta works and plays at Twilio as an interaction designer. She's worked with startups
    disrupting translation, investing, travel bookings and even the modern web browser. With a
    former career in journalism and a Master's in HCI, Nina has done design work and research in
    Tokyo, London, Cape Town and around the Bay Area. She does live visuals at clubs to explore
    the broader meaning of experience and physical space design. Follow her on Twitter at http://
    twitter.com/ninamehta

    View Slide

  3. TWILIO IS CHANGING COMMUNICATIONS BY
    EMPOWERING SOFTWARE PEOPLE TO BUILD
    VOICE AND MESSAGING INTO ANY APPLICATION
    @tsunamino @ninamehta
    3
    Tuesday, February 26, 13
    Danielle
    Twilio is changing communications by empowering software people to build voice and
    messaging into any application.
    Some examples of how people use Twilio:
    - Uber & Taskrabbit text notifications
    - Zendesk and Hulu’s help desk call centers
    - Airbnb & Match.com calls in the browser

    View Slide

  4. SHIPPING
    4
    Tuesday, February 26, 13
    Danielle
    At Twilio we need to ship things quickly in order to get new material into the hands of sales
    and marketing. The design team sits between Marketing (the owners of the message) and
    Engineering (the owners of the website). It’s our job to make sure quality things ship on time.
    This created a need to bring a developer on the design team to usher the message through
    from start to finish.
    Photo: http://www.flickr.com/photos/automaton_be/4477406732/sizes/l/

    View Slide

  5. A DEVELOPER ON DESIGN @tsunamino @ninamehta
    5
    Tuesday, February 26, 13
    Danielle
    Why put a developer on design? Why not hire someone on engineering?
    We needed someone to care about the message and how it was implemented on our
    website. If you’re working with a developer from another team to implement designs, their
    team’s priorities will always be first.
    http://octodex.github.com/

    View Slide

  6. PLAY ON THE SAME TEAM @tsunamino @ninamehta
    6
    Tuesday, February 26, 13
    Danielle
    But what if you can’t hire a developer on your design team? What are some ways that you can
    improve communication between your existing developers and designers? In order to work
    well together, you need to learn your teammates’ working styles and motivators. We spent
    time doing a few studies and reading about working styles of introverts and extroverts to
    figure out how we all fit together as a team. Some people need certain things in order to work.
    As an introvert, I need some time to focus on a problem before I present it. As an extrovert,
    Nina sometimes needs to talk her ideas out loud to a person. Some common motivators we
    found at work were deadlines, data, collaboration, and technical challenges.
    photo: http://www.flickr.com/photos/deanmccoyphotos/5795006771/sizes/l/

    View Slide

  7. REAL TALK
    /* CAROUSEL CLASS DEFINITION
    * ========================= */
    var Carousel = function (element, options) {
    this.$element = $(element)
    this.$indicators = this.$element.find(‘.carousel-indicators’)
    this.options = options
    this.options.pause == ‘hover’ && this.$element
    .on(‘mouseenter’, $.proxy(this.pause, this))
    .on(‘mouseleave’, $.proxy(this.cycle, this))
    }
    Carousel.prototype = {
    cycle: function (e) {
    if (!e) this.paused = false
    if (this.interval) clearInterval(this.interval);
    this.options.interval
    && !this.paused
    && (this.interval = setInterval($.proxy(this.next, this),
    this.options.interval))
    return this
    }
    , getActiveIndex: function () {
    this.$active = this.$element.find(‘.item.active’)
    this.$items = this.$active.parent().children()
    return this.$items.index(this.$active)
    }
    , to: function (pos) {
    var activeIndex = this.getActiveIndex()
    , that = this
    if (pos > (this.$items.length - 1) || pos < 0) return
    if (this.sliding) {
    return this.$element.one(‘slid’, function () {
    that.to(pos)
    })
    }
    if (activeIndex == pos) {
    return this.pause().cycle()
    }
    7
    Tuesday, February 26, 13
    Danielle
    For our design team to work well together we also really need to understand each others’ tools
    and technical skills. This helps us ask the right questions when something doesn’t look or
    work properly. Asking the right questions and understanding each others’ processes allow us
    to understand better when something just isn’t right. Though I don’t design things at Twilio, I
    still understand creative suite, typography, layout and a good ux.
    Nina
    Though I don’t get into the codebase at Twilio, I know HTML, CSS and Javascript. I can work
    through a complex flow with backend engineers and find out what’s possible to build and
    through all phases in a design cycle. Our creative director even codes in python on the
    weekends.
    Knowing each others’ skills gives us a shared language that gets us through sticky
    roadblocks and helps us empathize when something just isn’t working like it should.

    View Slide

  8. CRITIQUE EARLY & OFTEN @tsunamino @ninamehta
    8
    Tuesday, February 26, 13
    Nina
    We make sure to have formal and informal critiques every week. Because we understand
    each others’ skills, it’s much easier to articulate ourselves and when looking over a project.
    This help iterate on designs much faster. When a design is in the process of being built, we
    can look at it together and quickly tweak details to ship something we like.
    Danielle attends all design reviews so she knows how the project is supposed to look and
    what it’s supposed to do before she ever starts coding. But we all have lots of meetings, so it
    might not makes sense to bring developers to your design reviews. See if they can pop in
    when going over one specific part of your project. Or do short but frequent recaps at design
    milestones throughout the creative process.
    Doing this helps everyone tell the same story and see the message through from start to
    finish.
    But this starts by hiring people who want to work like that.
    Photo: http://farm3.staticflickr.com/2494/3742918775_f3b2aee5be_z.jpg?zz=1

    View Slide

  9. HIRE PEOPLE YOU WANT TO WORK WITH
    9
    Tuesday, February 26, 13
    Nina
    So find people you want to work with.
    Bring on someone who not only has the right technical skills but also someone you can see on
    your team. This sounds obvious, but a collaborative team knows and wants to talk each other.
    This is important because you’ll need to trust they’ll do their job well but also will be willing to
    work together as a team instead of in a black box. There’s no room for unicorns, gurus or
    ninjas.
    We found some people who applied for positions on the design team wanted to use it as a
    stepping stone to other kids of work or weren’t very collaborative. We were patient and found
    people with great talent that also cared about design and shared our values.
    You’ll likely spend more time with these people than with your partner or roommate. Be patient
    with hiring, no matter how many things are on fire. Waiting to finding great talent who wanted
    to work with, was a big win for us.

    View Slide

  10. OUR PROCESS
    10
    Tuesday, February 26, 13
    Example slide about how we created this presentation and the iteration process we went
    through. Point is: communicate often and frequently and remember to think about what the
    true purpose of your task is. Don’t get distracted by the things that you want to do, but stick to
    the things that you need to do.

    View Slide

  11. OUR POINT @tsunamino @ninamehta
    11
    Tuesday, February 26, 13
    Ok, so what’s the point?
    The point is not to be able to do each others’ jobs.
    The point is to know enough about each others’ to ask the right questions. When everyone has their own specialities but
    shared knowledge, it becomes easier to make thoughtful decisions faster.
    Some things you can do:
    • Start by communicating. Let people on your team know you want to understand their process. Danielle helps me
    understand our codebase and frameworks, we share our knowledge about the shipping process with marketing and our
    sales engineers let me sit on calls (with permission) to learn about where our customers are getting stuck. And developers
    on our engineering team now know it’s ok to ask, “how can I make this less ugly?”
    • Designers, invite developers to your design reviews. The design process is often seen as a black box. It seems like we
    somehow get an idea, draw a bunch of doodles, scratch our head a few times, click and drag a few thousand times and out
    the other end comes “the design”. Debunk the black box and show what’s happening in those doodles and clicks. It helps
    developers understand how the design got where it is and what elements are important for which reasons.
    • Developers, pull in designers while you’re building. It’s your job to keep the project on track but doing this can save lots of
    ‘design bug’ fixing at the end. It will help designers on the team understand why and how their work gets implemented. While
    it sounds like it costs more time, it will actually make everyone’s lives easier. But, both parties should be explicitly mindful
    when there’s an opportunity for a redesign and when there’s time for just tweaking.
    • Practice learning each others’ tools. Danielle coached me up on how to build something with a responsive design for a
    personal project and she leaned on design team when making a flyer for a class she was teaching. Learning how each
    others’ tools work helped us be empathetic and understand why what each other does is fun but also hard
    • We also recently started going to each others’ conferences. Doing this gives us a shared vocabulary and ideas to pull from
    when talking through a project

    View Slide

  12. OH YEAH
    SHOULD DESIGNERS CODE?
    12
    Tuesday, February 26, 13
    Nina
    Should designers code?
    This is debated in all kinds of Quora threads and all kinds of blogs and talks.
    But we say yes. Whether or not you code for your job, you should code. Some even say,
    unless you work at a very small startup, it doesn’t even make sense for designers to ship
    code. But knowing how to do it can help you make prototypes to communicate your ideas
    and above all ask your developer smart questions.

    View Slide

  13. BUT
    DEVELOPERS SHOULD DESIGN
    13
    Tuesday, February 26, 13
    Danielle
    But! Developers should design.
    Whether or not you design for your job, you should be able to understand the creative
    process.

    View Slide

  14. QUESTIONS
    14
    Tuesday, February 26, 13

    View Slide

  15. THANKS!
    @tsunamino @ninamehta
    15
    Tuesday, February 26, 13

    View Slide