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.
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
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
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
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/
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/
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/
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.
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
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.
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.
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
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.
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.
dmleong
shimabox
wadayusuke
devoc
workspace93
tapompom
nozaki
aethiopicuschan
subomi
hsawaji
minma_curama
hschwentner
morganepeng
dougneiner
eitanlees
shpigford
addyosmani
keavy
pauljervisheath
michaelherold
bkeepers
mthomps
maggiecrowley
geeforr