This week’s guest author is Bill Scott, Director of E-commerce UI Engineering at Netflix and co-author of the fantastic book Designing Web Interfaces: Principles & Patterns for Rich Interactions.
Years ago I was in an off-site with the design team for a well known, successful web site. During the course of the day I heard designers complain that what went live was often embarrassingly different from what they had handed over to engineering, even though they handed over static HTML/CSS for the page. So I asked if anyone knew what the disconnect was…what happened between the time they handed the code over and when the user visited the page? Their answer: “We don’t really know. We just know that they cut up the pages into JSP files”. I found out that none of the designers knew what that fully meant so I suggested a stunningly simple solution: “Let’s get the engineering team to train you in their job. Pretend you are a new hire and let them teach you how to cut up the page.”
The result was enlightening. In JSP there were tags that defined reusable components and common HTML idioms. The result was the HTML had to be mapped into JSP syntax and often the components did not map with the variations that design called for or things were lost in the process. Understanding the whole process led to changes in the way the design team created the code and the way they communicated changes to the engineering team. This was a moment of shared understanding.
Building a shared understanding between team members can bridge the gap between different ways team members think and work. Being fortunate to have observed both design and engineering worlds I see the maxim that designers are from Venus and engineers are from Mars holds true more often than not. While a generalization, the personalities attracted to these roles tend to force different world views and thus can lead to communication breakdown.
While at Yahoo! I was privileged to work with Karon Weber, who had previously worked with two engineering-heavy teams: the Pixar animation tools team and Xerox PARC. Karon taught me valuable lessons on getting stuff live quickly by creating a shared understanding in the scrappy teams she formed. At Pixar, it’s all about the story. For this reason Karon is a firm believer in something she calls getting “design into the wild”. Instead of locking design up as bits in Photoshop, the real power is getting design in front of others: on posters, on foam board, and out in the hallways where the commerce of ideas mix. A lot of the hack culture that imbibed Yahoo! at the time flowed from the merry little band that worked with Karon. Her story telling is just another form of shared understanding.
One of the things I was most proud of at Netflix (the first time I worked there) was building a strong user interface engineering organization. But the success of that engineering organization was dependent on the design team having a shared understanding with the engineering team. It was not the case to begin with! The design team had a fuzzy view of the engineering teams challenges and concerns. And the engineers had little idea what the design team truly valued over what was just a nice to have.
To help fix this one of the guys on my team, Brian Cox, did a simple thing: he started a Friday round table. Bring your ideas, complaints, kudos, and suggestions to a round table. No manager agenda. Just talk. It did wonders to create a shared understanding. Vocabulary came together. We decided rounded corners weren’t critical. Designers found out what was really hard and what was really easy. Asset delivery streamlined. And we streamlined the interface technology to deliver more features faster. All because of a shared understanding.
Just last week I met with another very savvy design team. Inspired by the work that Erin Malone, Matt Leacock, myself and others did by launching the Yahoo! Design Pattern Library, they have their own pattern library. As we talked about documenting patterns we really settled on the core concept that made the pattern library successful. More than anything the patterns created a vocabulary. Engineers, designers, and product people could use the patterns as a way to gain a shared understanding.
Building a shared understanding is not really about a specific process or tool or whether everyone can code or design. Having a shared understanding is about getting everyone to walk in the other person’s shoes a little. It’s about building respect, building vocabulary, and gaining enough insight to build solutions together that in the end make a better experience for our users. It’s how we build an experience right? We seek to understand our users. We observe them. We study them. How about doing the same with your co-workers?