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
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 ﬁrst female engineer. She specializes in responsive site and email creation, company branding, and ﬁghts the good ﬁght 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
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 notiﬁcations - Zendesk and Hulu’s help desk call centers - Airbnb & Match.com calls in the browser
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 ﬁnish. Photo: http://www.ﬂickr.com/photos/automaton_be/4477406732/sizes/l/
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 ﬁrst. http://octodex.github.com/
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 ﬁgure out how we all ﬁt 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.ﬂickr.com/photos/deanmccoyphotos/5795006771/sizes/l/
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 speciﬁc 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 ﬁnish. But this starts by hiring people who want to work like that. Photo: http://farm3.staticﬂickr.com/2494/3742918775_f3b2aee5be_z.jpg?zz=1
26, 13 Nina So ﬁnd 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 ﬁre. Waiting to ﬁnding great talent who wanted to work with, was a big win for us.
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.
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’ ﬁxing 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 ﬂyer 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
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.