The Curious Incident of the Developer in the Design Team: Thinking in the Same Language
Are you spending more time arguing than implementing? Gain insight into the inner workings of Twilio’s unique cross-functional team of designers and developers who can talk the same language. Danielle and Nina will illustrate how they compliment each others’ skill sets and leverage their differences to benefit the user. This talk will showcase how they collaborate and build a great product from sketch to ship.
Danielle Leong - Twilio, Front End Web Developer
Nina Mehta - Twilio, Interaction Designer
Just Call Vip call girls Fatehpur Escorts ☎️8617370543 Two shot with one girl...
Swanky talk
1. THE CURIOUS INCIDENT
OF THE DEVELOPER
ON THE DESIGN TEAM
THINKING IN THE SAME LANGUAGE
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
2. DANIELLE LEONG
DEVELOPER
@tsunamino
NINA MEHTA
DESIGNER
@ninamehta
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
3. TWILIO IS CHANGING COMMUNICATIONS BY
EMPOWERING SOFTWARE PEOPLE TO BUILD
VOICE AND MESSAGING INTO ANY APPLICATION
@tsunamino @ninamehta
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
4. SHIPPING
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/
5. A DEVELOPER ON DESIGN @tsunamino @ninamehta
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/
6. PLAY ON THE SAME TEAM @tsunamino @ninamehta
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/
7. /* 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
REAL TALK if (pos > (this.$items.length - 1) || pos < 0) return
if (this.sliding) {
return this.$element.one(‘slid’, function () {
that.to(pos)
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(activeIndex == pos) something doesn’t look or
if
questions when {
work properly. Asking the right questions and return this.pause().cycle()
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.
8. CRITIQUE EARLY & OFTEN @tsunamino @ninamehta
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
9. HIRE PEOPLE YOU WANT TO WORK WITH
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.
11. OUR POINT @tsunamino @ninamehta
Both
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
12. OH YEAH
SHOULD DESIGNERS CODE?
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.
13. BUT
DEVELOPERS SHOULD DESIGN
Danielle
But! Developers should design.
Whether or not you design for your job, you should be able to understand the creative
process.