Episode #146 Bill Scott - Design Patterns for Multiple Platforms
As we use a multitude of devices to access the same content, we expect a similar experience across platforms. If you have a great user experience on the desktop, it would be easy to rationalize that your mobile experience, for example, shouldn’t be painful. User experience professionals now need to consider how and where their applications and content are being accessed more than ever before. Developing rich interactions across all of these platforms can be a daunting task. Bill Scott discusses how employing design patterns can help ensure that your users have a great experience wherever they use your product.
As we use a multitude of devices to access the same content, we expect a similar experience across platforms. If you have a great user experience on the desktop, it would be easy to rationalize that your mobile experience, for example, shouldn’t be painful. User experience professionals now need to consider how and where their applications and content are being accessed more than ever before.
Bill Scott knows this. Bill is the Director of UI Engineering at Netflix. Users can access Netflix on TVs, mobile devices, tablets, not to mention on the desktop. Bill believes that it’s not just the devices themselves, but also the context in which they are used that designers need to keep in mind. Developing rich interactions across all of these platforms can be a daunting task. Employing design patterns can help ensure that your users have a great experience wherever they use your product. Patterns develop a common vocabulary and create a shared understanding amongst the team.
Listen to the podcast to hear Bill address these points:
- Are design patterns about establishing a vocabulary?
- Is there any truth to the idea that patterns stifle innovation?
- Are patterns used more to lay out a path than to declare “absolute rules of engagement”?
- Do you ever push something out that is less than optimal and rework from there?
- How do you ensure that what you hand over gets implemented as you intend it to?
- Do you employ “hack days” to generate new ideas?
Jared Spool: Welcome, once again, everybody to our current episode of the SpoolCast. I have with me today the wonderful Bill Scott, Director of UI Engineering at Netflix. And he's going to be speaking at our User Interface 16 Conference on Monday, November 7th. The conference itself goes from Monday to Wednesday, November 9th, but he'll be speaking in a full-day workshop on designing rich, interactive experiences, and that's what we're going to talk about today.
Bill Scott: Hey, I'm glad to be here.
Jared: I'm glad to have you here. So, let's just start talking here. I've known you for a really long time. You and I go way back. You were at Yahoo and before that at Sabre, and you've sort of always been in the center of what's been happening in terms of this rich interaction stuff. Really bringing out over the web and through devices the ability to control and give access to data through all sorts of gestures beyond just a simple click of a button or a link.
How did you come to pick all that stuff up? What was your journey like?
Bill: I think my start, just to real quick go way back, was running one of the first games for the Macintosh actually, a game called GATO Submarine Simulation.
Jared: Oh yeah!
Bill: That was in 1985... early '85, late '84. And it was this whole thing of, we've got this new world with a mouse, with menus and icons, and how do you actually design a game? We didn't actually have any examples in front of us, but we just thought we'd take the best of what was in that world and meld it into a video game.
And you know, I feel like we were pretty successful. That game was actually a best seller, number one on the best selling list for a while and at least the top ten the first year or two. Not a lot of sales compared to today's market, but a lot for back then.
That really got me hooked on the power of -- for example, we could add a mission editor for the submarines, right, and that wasn't in part of the original spec. We just added that because we thought, well, with drag and drop and stuff you could create your own islands. You could create your own paths for the bad guys to come, and you know we added path editors and such like that. It was just so much easier to do with the mouse and everything. That sort of got me hooked.
And then, over time, I was always designing and developing together, because in the late 80s and early 80s and early 90s, there weren't really that many disciplines that were pure user experience. You had to be in HCI or something like that. So it was always very pragmatic and always kind of tried to understand what were these emerging patterns? What could you do with technology, because there was always kind of a limit to what you could do.
That just kind of evolved over time into thinking about patterns. I remember discovering Christopher Alexander's book on design patterns, and then finding some of Jenifer Tidwell's work on cataloguing patterns for rich experiences, you know, for the desktop. That got me thinking.
Then as I moved to the web, I immediately went back to sticks and mud, because there was no way to do anything. You had that horrible request/response cycle, and you couldn't do anything without refreshing the page. So we immediately started using some of the stuff in IE to get around that. This is early 2000, 2001, whatever. And then we finally, when Ajax came on the scene, when Google Maps came out, it really became possible.
And in that we just saw the melding of showing examples of patterns as well as implementing those patterns. Because design patterns were a good way to bridge the gap, really, between design and engineering, because it creates a vocabulary. It names things that are hard to describe otherwise, instead of saying, "Well, you can take you mouse and you can click something."
Of course, we have drag and drop, and we can say that in shorthand. That was a very early form of that in the early 80s. But as you go forward, things you know, page slides and hovers, accordions, and all those sort of things like that, and when are they good and when are they bad. I have sort of this reductionist mindset anyway, where I try to reduce things to simplicity. Maybe that comes from a software background, too, but I felt it played real well with the patterns.
Then, when I came to Yahoo and joined there as the Ajax evangelist, the Yahoo pattern library had already been started by Erin Malone and Matt Laycock. They had done a great job, but most of the patterns were really of the older school because this had just started emerging.
So I just started writing patterns for that pattern library. I had about 50 or 60 I added that were new, that were rich, and I started just cataloguing like crazy. At that time, in 2005, at Yahoo we were just starting to experiment with Ajax and get really into it and what could you do with the web, and it just led to more and more cataloguing.
Then, because I had actually written most of the patterns in the library, or at least half of them, I said to Erin Malone that, "Well, maybe I should, in addition to my other job, just take over the pattern library" since Matt was moving to something else. And so I did, and then we launched it as a public pattern library and got a lot of great feedback from what we put out.
And that just kind of kept me going down that path of doing that. But I've always felt like patterns were really about being able to take something and boil it down into just a few words so that I didn't have to explain it over and over again, and you could just make it part of your toolbox.
Jared: Well, and this is interesting to me, because I was just discussing with somebody this week that I thought that a big piece of the value that comes from patterns just comes in establishing the language, the vocabulary. The sort of discussion of, what is it we're trying to do, and what is that subtlety and nuance? And the more complicated these devices get, the more that subtlety and nuance happens.
Do you think that design patterns are really about that vocabulary creation, or is there another value that comes out of them that I'm missing?
Bill: No, that's exactly right. And when we released the Yahoo design pattern library, you know, it wasn't about, "Oh, hey, this is the only way to do it." It was more about, "This is what we're discovering. Let's start a dialogue about this."
There are people out there who are very, very semantic about the way they define patterns and go about and document those patterns. I appreciate those folks. I'm not one of those folks, because it's like getting too far in the meta where you're straining in a nat. And the reality, people just need examples. And I felt like that was actually the biggest contribution I was making was just collecting lots and lots of examples and putting those in the screen casts so that people could see those and associate those with an idea.
And then, once you have that picture there, that vocabulary, something somebody can see, you can talk about the nuance of it. You can talk about, well, why does it work in this situation and not this other situation? Because design is all about that nuance and the context.
And just exposing people that haven't been through the design-thinking process, that maybe come from another background, there's some very objective things but there's also a subjective piece to it. The objective part is these patterns, but the subjective is how you apply them. And I think that helps a lot of people who especially don't come from a design background. I think it helps people with a design background, too, but I know that what I've shared a lot seems to resonate especially with developers.
Jared: One of the things that came up in this conversation that I was having was that one of the folks felt that they'd seen design patterns used as a way to sort of stifle innovation. I've never seen it that way. His thinking was that the organizations that were using these patterns were being so rigorous about documenting and enforcing the patterns, more in a style-guide notion, that people couldn't do things that made sense to do that fell outside of the patterns.
Whereas, when I've seen them used, they get used in less of an enforcement mode and more of a, "Here are what your options could be, and here's the language you use to describe it. And if you come up with something better, that's great. Just document it and add it back into the library."
Bill: My hunch is that there definitely are groups like that, just like any bureaucracy. You have the police mindset, and you have the "I'm here to assist" mindset. When they become a resource, they're good. When they become a stifling set of rules that have lost their context, right? That's the whole thing. And you can't crystallize these things. You can't define every nuance and every context in those patterns. They get way too unwieldy.
I do know, in chatting with a few people, I've seen people try to go down that path, and I've tried to encourage them: "Don't get hung up on the enforcement side of it. Really get excited about assisting and helping the teams and providing them with lots of resources and a common vocabulary. If you did just that, you would be successful." But some people start to feel like they get measured by--they're a central group in an organization. I was talking to a company a few months ago that'll remain unnamed. A large social network. But anyway.
Bill: Anyway, I won't go any further. Because there's several of those, so I can leave it like that.
The people in the group were not of the ilk to do that, but I think they were feeling pressure that, well, shouldn't they be getting more adoption? They were asking, "When you were at Yahoo, what was the adoption rate?" I said, "Not really that great, with our central guidelines and our central practices, but everybody grabbed the patterns idea and took it from a vocabulary perspective. So..."
Jared: Yeah, I mean, do you think that it's really about making the designer and the teams that they work in a bit smarter and a bit more savvy, in terms of being able to talk about what they're trying to do and sort of laying out a path that is proven, more than it's about declaring what the absolute rules of engagement are?
Bill: That's right. Yeah. Whenever you have groups that are seeking the best idea, the best solution, things work well. When people put some kind of stake in the ground, well, it's like our political system today, right? You've got the two parties. It's almost that same sort of mindset, where it's no longer about solving problems; it's about posturing and position. And I hate it. When the patterns come that way, I get very uninterested.
At Yahoo, we had a user group that I set up for pattern authors to join and I quickly lost interest in that mail list because there were these endless discussions about what was the canonical pattern, a pattern for a pattern.
Jared: [laughs] Oh God, that sounds miserable. [laughs]
Bill: And arguments about what kind of examples should you have, and whether they were four sections you should have versus eight sections. I don't care. At the end of the day, the business has got to be successful, and design and engineering's about bringing something to life.
Jared: Customers are not going to get excited because you've defined your patterns rigorously.
Bill: It reminds me of, this is back in the software world. I worked with a very bright engineer who had gotten the Gang of Four book, "Design Patterns for Software," which was the first, really, application of Christopher Alexander's patterns into the field of technology, and it's a great, classic book. This was back in about, oh, probably '94, '93, something like that.
And one day he came around the corner and he had this big smile on his face, and he had the book in his hand and he was shaking it back and forth, and he says, "I did it!" I said, [laughs] "What did you do?" And he goes, "I've implemented all the patterns in this book in our software." [laughs]
And a few years later, I'd left that company and I came back--actually, it was Sabre--and I came back, and through a quirk of a bunch of funding changes, for a while I ended up taking over his code, and was not a happy person, because that did not make better software, just applying [laughs] all the patterns blindly. So, same thing with design.
Jared: Yep. So, to sort of change directions here for a second, the work you're doing at Netflix now, you're involved in a lot of the day-to-day production of what goes out on the Netflix site, right?
Bill: That's right, yeah. My job right now is much more focused. On purpose, I took a more focused role around acquisition. I hadn't worked in that area before with marketing. And so it's really around the sign-up flow and it's around account services, probably what, in some ways, is seen as the less sexy stuff. I was involved with the member side for a good, long while, and still am tangentially.
But I just find it kind of fascinating to see just how fickle--that's maybe one way to put it--the whole acquisition and conversion channel is. So it's been an interesting education in that.
Jared: By acquisition and conversion, we're talking about getting new people to realize that Netflix exists and then converting them into customers. And you guys have been moving into new countries, too, right?
Bill: That's right. We've announced that we're going into 43 countries in Latin America, and that will be in the not-too-distant future we will be launching that.
Jared: So there's lots of new customers to acquire.
Bill: That's right, and they're different. They don't have the same bandwidth. They don't have the same movie watching habits, TV habits. They don't have the same devices. They don't have the same kind of payment methods. There's a whole bunch of things that vary. Cultural differences, how you state things, you know all those sort of things come into play.
Jared: So now, what are you learning in terms of the rich interaction stuff that you can draw on to use in this new role that you're focused on over there at Netflix?
Bill: Well, one thing we tried... And it's interesting. This is a good example of where, even though you can do something, it may not be the thing that really works. So I'll give more of a counter example I guess.
One of the things we experimented with was a single-page sign-up. So that, you just come to the page itself and you know, you do everything in one page and you're signed up, that's it. We've seen success around that with hotels and other things that have gone to a very simple flow like that.
The thing is, when we did that we actually saw a drop in acquisition, and our theory on that is because people need that second screen. They get the first screen, they put their email and a password in, and they need the second screen to really digest the whole payment area. And then, once they've done the payment they're done. We've simplified the flow down to just the two steps and the confirmation.
But to get to that one step, we're not there yet, and we've tried a few things. I think people need that break, go to the next page, digest the payment, feel comfortable that, this next step I'm going to actually be paying and not doing it in a one-step process.
So, even though we were doing a rich experience there, it ended up not actually working. We'll definitely revisit it again with some different approaches.
Jared: Yeah, I mean, by bumping into these things you get a chance to learn what works better going forward. How do you get everybody involved in understanding what the goals are so you don't push something out that is less than optimal? Or, do you push stuff out that's less than optimal and then you just sort of regroup and figure it out?
Bill: Oh, yeah. That's one of the mantras here is to fail often and fail fast. Everything you try is an experiment. A lot of times you don't have full confidence. You have misgivings about some of the stuff you're going to try. But you know you have enough volume that with customers, especially around the acquisition channel, you've got some pretty clear metrics about success or failure.
It doesn't mean that, for example, that one-page sign-up would never work. We just may not have hit on the right way to do it yet, right? So you can't throw out the whole concept. You can only say, "Well, with these particular tests it didn't work."
So what we do though is, you know marketing does a good job they're, in essence, like our product managers providing us with a business context. And Netflix as a whole, there's not any business information that's not shared all the way down. It's not just limited at the director level; it goes all the way down to employees.
So, everybody's kept up to date on all the strategies and purposes and what we're doing. There's nothing hidden from the employees, which I think is really good. A lot of organizations don't understand why the decisions are being made, and we have a very open culture about that. I think that kind of starts right at the top.
And then the business ideas are there, and then design and engineering understand that early. And then, in the process of, you know, raising issues and having conversations, it's not like one team is just dictating and somebody goes off in a corner and implements without any knowledge. I've seen that happen in the past too many times, but we don't do that.
Jared: Right. How do you make sure that when you're designing something up and you're handing it over to the folks who are going to implement this thing that ... I guess there are two issues, right? One is, is that what you're asking can be implemented, and second, that they get it enough that they can go off and do it the way you intend it to be happening?
Bill: Well, some of the things we've done in the past that have worked really well in that is, for a while to get everybody on the same page, we started having round tables where we get design and engineering together and have conversations.
Because design may put together their Photoshop assets in such a way that it actually causes a lot more work on the developers. And also, developers maybe have ideas or techniques that the design team doesn't know about that are possible that are actually pretty easy to do that they could make part of their bag of tricks.
So, having an open forum that design and engineering can get together pretty informally, and not driven from top down but more bottom up. Anybody in the team can bring up a topic and make that the topic, or several topics, for the conversation. What that does is it gets vocabulary out in the open.
I remember the member design team. Some of the people in the member design team like to use the term "lockup," because they came from an advertising background, describing the area where you have a box shot of the movie with the rating and whatever else goes around the particular movie title.
They call that a lockup, and half the developers didn't know what the heck a lockup was, and once that was explained with the background ... That came out through the round tables. I don't think it would have ever come out and disseminated in normal hallway conversations or anyone would have sent an email about it.
It's putting people together. It sounds pretty simple, but actually it's one of those things we forget. It's sort of like, how do you understand users? Well, you get with users, right? Obviously there's more to it than that, but often those very, very simple things don't happen.
So like, for example, the brand marketing design team, I've spent time with them. I did an HTML5 presentation, CSS3, et cetera and walked them through what is possible first on WebKit, because our TVs and our devices, our new devices that we're going onto, most of them support WebKits, so we have all the capability of WebKit for those.
And then for the website, you know, what are the current browsers we're supporting? What can they do in the HTML5 world and CSS3 world, et cetera, versus what can be done in flash? And those sort of conversations have been really helpful to them.
So, it's really about that shared understanding concept, where engineers have a shared understanding of business and design, and designers have the other two and et cetera. And marketing, you know, even educating them on what developers go through and what their process is at a very high level, gets everybody in the same ballpark where they really understand each other and get a sense for what's hard, what's easy, get a sense for the time crunch, get a sense for all those sort of things.
It sounds pretty touchy-feely, but I like the term "shared understanding." I think that sort of captures the essence of it. You could put as much process or as little process to shared understanding. It could be very detailed wire-frames, or it could be just a hallway conversation, depending on what is needed for that organization in that context.
Jared: I think that the shared understanding has got to be critical. And I think, when I look at the organizations that we work with that really struggle at getting good designs out, you can go back to surprises that happen in the process, where it comes from people not having that shared understanding, you know, "What do you mean that's difficult to implement? You did it over there." Or, "How come that's going to take five weeks? Isn't it just a simple changing of a few words?"
They just don't have a sense of what's going on. Of course, on the other end, it's the devs and designers saying, "What do you mean that when you click here, it has to go to this other screen you didn't tell us about, or it has to produce a message, or you're going to want to extend this in the future to have these other options?"
Bill: That's right. Yeah, exactly.
Jared: And so that shared understanding piece really does make a lot of sense. One question I have in terms of this is you had shared with me a while back that you guys were doing all this cool hack day stuff. Do you still do that on the acquisition side? You have a hack day type thing that happens?
Bill: Well, it happens company-wide. So it happens with facilities, where they may be doing something around hacking the phones. [laughs] It could be the content team, hacking stuff down in Beverly Hills, hacking together with some engineers. I did a hack with them a year or so back where you could go to Google Map and zoom in somewhere and see all the films that were shot in that location. Right?
Jared: Oh, cool.
Bill: And then, for fun, I added a little extra dimension in it where there was two little buttons. One was Mars and one was the moon. You could click on Mars, it brought in a Google Earth plug-in and flew you out to Mars and showed you some of the movies that were shot on Mars. [laughs]
Jared: Very cool.
Bill: [laughs] It was a joke.
We've had a number of things come out of the hack days. One thing we continue to test is how to find related content really easy, kind of like the six degrees of separation, Kevin Bacon kind of thing, right? We had a "more like this" kind of feature that came in in one of the hack days, where you have a page where the movie sits in the middle and then all the other movies that are related to it in some fashion are around it, and then you click one of those, it slides to the middle and more come out around it. We actually implemented it on the site. It didn't test too well.
Of course, what we find out often with the media consumption we do is that anything that feels complicated at all, people don't tend to do. It has to be really simple. But what's happened is that thought has continued to have, I don't know, at least maybe six or eight different incarnations. None of them have actually fully worked yet.
We have one example on the device that worked better than control. And on device, on our TVs--PS3, I think it was, we were testing this--you had a row showing up on your TV, and when you move your arrow back and forth and land on a movie or a TV show, below it, the next row, is all the related content. And if you go down to one of those and select it, then the row below it becomes related to it. So it's almost like a tree navigation, but it's just rows, right? That actually did pretty well.
The problem is, how do you integrate that back into something like the normal experience, where you're showing just, here are your areas of interest, which we call sub-genres, or micro-genres, we've built and based out of your taste input and what you watched and stuff, like quirky, funny movies from the 1700s. I don't know.
Bill: So, how do you tie that into that? So there's some tests around doing that that are coming out to play with that.
Jared: So the neat thing about the hack days is, do you feel that has a huge effect on the shared understanding? I mean, do things sort of burst out of that and people go, "Oh"?
Bill: Yeah, I do. I think there's a lot of stuff, like some technologies on the edge, that not everybody's getting a chance to play with that somebody brings in. Like when the Kinect stuff first came out, you know, there was a pretty cool hack around that and sort of opened some thinking up around some other stuff.
Real early on, some guys had hacked the iPhone so you could control the Roku player with it. And those were quite interesting. But a lot of it is just you sort of get a chance to see what other people consider to be problems they're trying to be solve. Right? What are the itches that are trying to be scratched around the organization? And I think that's pretty helpful.
Jared: So in November, you're going to join us and spend an entire day sharing this wealth of knowledge you have, and the stuff that went into your book and a variety of insights and details and videos and techniques on building interactive stuff. You're going to show us how to deal with the flow in the application, how to deal with input, how to deal with responsiveness and all the sort of techniques that you've put together. I'm really looking forward to this session.
Bill: I am, too. I did a workshop similar to this, but this has more material, especially now adding a little bit with the device world and tablet and TV and mobile back in Lisbon. And the workshop went really, really well, and people seemed to really enjoy it. I know it sold out really fast. So I'm hoping the same interest is here in this. I believe it will be.
Jared: I think it will.
Bill: And really, I guess people that are considering whether to come to something like this, my goal is to make it as pragmatic as possible. When people hear "patterns," sometimes they think of the theoretical. It's not at all. It's really just about lots and lots of examples that work well and don't work well. And when you come out of the workshop, what you really should have, I think, is just a pretty rich vocabulary of what's possible and what maybe to avoid, and then you can go back and share that with the team and have a toolbox. Expanding your toolbox is really what it's about.
Jared: Cool. I'm looking forward to getting my toolbox expanded.
Jared: Excellent. Thanks for taking the time to talk about this with me today.
Bill: I'm always happy to talk, Jared.
Bill: And to talk with you is icing on the cake.
Jared: There you go. And I want to thank our audience for joining us today and for supporting everything we do. And, as always, thank you for encouraging our behavior. You can see Bill at the User Interface 16 Conference in November. November 7th through 9th. You can find out details about that at uiconf.com. Hope to see you there. Thank you very much.