Future Practice Interview: Bill Scott

Posted on | 6 comments

  • As part of our Future Practice webinar series, we’re interviewing presenters to give you a preview of what they’ll cover. Next up is O’Reilly author and Netflix Director of UI Engineering Bill Scott on the topic of interface engineering.

    His webinar Bringing Design to Life: What Every Designer Should Know about Interface Engineering took place on February 26, 2009 (7 minute preview here). Use code RMWBNR for a 20% discount off your purchase of the recording.

    Lou Rosenfeld: Bill, what are some of the biggest disconnects between design and engineering?

    Bill Scott: This depends on the role that design and interface engineering play within an organization. Sometimes the designer’s final product is an interface specification that might include wireframes, mockups, interface diagrams, and so on, with the engineers producing the HTML, CSS and other interface code. In other organizations designers actually produce HTML and CSS, and the engineers take this code and carve it up to work with various user interface technologies (like JSP/ASP/PHP/Rails). Regardless of the actual split, there is a natural disconnect in the actual “product” that each team is responsible for.

    Design teams feel finished when they have produced a comp and the necessary graphical assets (or HTML/CSS). But the interface engineering team is just starting their work. The trick is to get interface engineers involved much earlier in the process (through design reviews and prototyping) and to get designers to stay engaged throughout the full production cycle (by understanding what issues arise from their designs and by setting their goal to be the full delivery of the experience.) Engineers are production focused. Designers are often ideation focused.

    Lou Rosenfeld: Don’t many of the problems come down to the lack of a shared vocabulary?

    Bill Scott: Absolutely; a recent round table discussion at Netflix brought that to light. The terms “component,” “simplified visual framework,” and “lockups” were discussed and very quickly we realized that engineering had a different definition for components and visual framework, and had no clue what the design team meant by lockups. The term lockup comes from advertising and was used to describe the movie box shot, movie title, add buttons and the star rating. Component had a much more rigid meaning for engineers as an interface control that could be packaged as a reusable software module (like a carousel control). Designers thought of this as being modules on the page (titles, header, footer) as well as the carousel control. The “Simplified Visual Framework” is a term we use to describe the system of grids, tempates and common site elements on the design side and on the engineering side to include proper semantic markup, unobtrusive JavaScript as well as the Struts2/Tiles2 page generation frameworks. In fact, despite 6 months of having this common terminology and numerous presentations there are still occassional disconnects that arise between the teams over just what the other means by this terminology.

    Lou Rosenfeld: How do you get team members to start speaking the same language?

    Bill Scott: Constant communication between the teams. What also works is adopting a common language to describe interactions. The use of design patterns is a powerful way to disseminate common thinking and approaches to common problems. I have been pleasantly surprised when language that design and engineering use to describe certain bad approaches (anti-patterns) gets in-grained even in our product managers vocabulary as well.

    Lou Rosenfeld: What do engineers wish designers understood?

    Bill Scott: I spent a good deal of time thinking about this question when preparing this talk. In fact I pinged a number of people I highly respect in both design and engineering. After listening to hundreds of comments and reflecting on my own experience I boiled it down to five simple ideas that developers wish designers understood.

    1. The site is dynamic. Photoshop is static—the site is not. The site is dynamic in content, layout and interaction. It’s too easy to forget all of the details that come about when users get involved. But engineers end up having to fill in the gap where the designer has not accounted for all of these dynamic concerns.
    2. Technology is critical. Web design without technology is just art. You must understand the magic that gets it on the site. Designers that “get” the unique challenges of getting their designs live can make smart choices up front and anticipate problems or even better arrive at more elegant solutions.
    3. Components are key. Developers think in terms of reuse. Designers often think in terms of new ideas. To be effective you must plan for the common elements and interactions as this will map into a better experience as well as a more efficient use of engineering time.
    4. Partnership is imperative. It’s tempting to design and toss over the wall. But the real magic happens during collaboration. Communication and constant iterative engagement are key to fielding a great user experience.
    5. “Yes We Can!” Interface engineers have the power to say “yes” more than ever. And there are a lot of technology advances coming that if you are aware of as a designer you will enlarge your toolkit of tricks. Good interface engineers see problems as challenges and instead of trying to whittle your designs out of existence they will try to make it happen. Good engineers want to say “Yes”.

    Lou Rosenfeld: Give an example of something that is surprisingly difficult for user interface engineers to produce that designers would think should be easy.

    Bill Scott: Almost anything on Internet Explorer 6 🙂 I joke, but any engineer worth his salt will have a list of things they hate about IE6. But more generally the DOM (document object model) was designed for documents—not application development. So engineers are always “working against the flow”. The browser rendering engine is geared first and foremost to layout text and images, all the while marching down the page in a vertical flow. User interface layout is about modules with equalized height or items aligned vertically or items placed in a grid or side by side. Understanding this one fact that we are trying to do interface layout in a document rendering engine goes a long way to understanding why some things that should be easy turn out not to be trivial. Especially in light of making it work on IE6, IE7, Safari, Firefox, Opera and Chrome.

    One example is vertically aligning interface elements. Now it is trivial to vertically align “inline” elements like spans of characters, etc. But attributes like “vertical-align” don’t work with “block” elements (e.g., divs). And if you aren’t resorting to the brittle technique of trying to force height on everything, you will find it to be particularly challenging. One solution is using display:inline-block. It allows block elements to be treated like inline elements. But alas this doesn’t exist for Firefox 2 (although a Mozilla proprietery property that sort of works like it does). And for IE it only works on elements that are naturally inline! So one has to trick IE into thinking the block element is inline and then set it to inline-block. And one has to trigger an internal IE flag for “hasLayout” to get the magic working completely. So yes it is possible. With the correct magic CSS formula (and for FF2 a little extra markup) you can get block elements to vertically align along an axis! Now if that sounds painful, imagine dozens of other seemingly simple tasks that require numerous hoops to make it work across browsers and you will begin to appreciate how frustrating this is for talented developers to spend their time figuring out.

    Lou Rosenfeld: Bill, it does sound frustrating, but it’s good to know that problems like these might be alleviated when engineers and designers can talk and, ultimately, understand and value each other’s contributions. I know that both your webinar and your forthcoming book will get us one step closer to that happy outcome; thanks for sharing your wisdom!

    Bill Scott

    Bill Scott has always enjoyed technology (25 years). And he has always enjoyed people (even longer). It was a natural to blend the two loves together. For a long time he couldn’t decide if he was a designer or an engineer. He finally gave up trying to classify himself and just decided to live in both worlds as much as possible. This passion has led him to found user experience teams (Sabre), build Ajax frameworks (OpenRico) lead engineering organizations (Netflix), found design pattern libraries (Yahoo!), talk a lot about it (Ajax Evangelist) and even write a book about Designing Web Interfaces (O’Reilly).

    6 Responses to “Future Practice Interview: Bill Scott”

    1. Good stuff! I found #3 to be core to gaining greater understanding on both sides. I might phrase it a little differently–designers (in my experience) tend to want to address each view in a UI individually; developers want a theme/stylesheet they can just throw in there and reuse everywhere. I guess it comes from the distinction in professional focus, but as you say, understanding that can help in more effective collaboration.


    2. This is a great discussion and I’m glad to see the focus put on collaboration. It also underscores the need for the UX role in general; it is a natural discipline to help foster that collaboration.


    3. @Ambrose.

      Yes, I actually like your phrasing slightly better than mine. It gets to the real heart of the problem.

      The nuance that I was mentioning is due to the fact that I have been fortunate to work with designers that do get the concept of reuse, but still think of reuse differently.

      But you are right, the problem generally is deeper than I stated in the interview above. The way design problems (product requirements) come to design naturally works against thinking of reuse and instead solving the problem at hand (i.e. pages in isolation).

      And worse, if the engineering team is not seasoned or talented they too will fall in the trap of doing lots of one-offs and falling prey to reuse by “copy and paste”.

      This, unfortunately, is actually the more common case.


    4. I found it interesting that credibility wasn’t addressed here. Is this less of a problem because interviewee and interviewer are men? Or perhaps you have a few gray hairs? Or you’ve known your developers so long you don’t have to worry about it?

      In any case, in working with different engineering organizations, I find that about 25% of the time I have a credibility problem that I have to address before we can make any progress at all. Some things that can help:
      – simply being professional, serious, dressing professionally, listening, and being thoughtful and articulate
      – sharing engineering deliverables from the past, emphasizing rigorous documentation and getting the engineers what they need to do their jobs, including visual specs, functional specs or prototypes, maps, copy decks, whatever strikes their fancy
      – showing an openness to them by starting with what they love and hate about the design and their work to this point (they may have been doing design work in the past and love it, so we need to surface that) and listening well and being responsive
      – asking them what they’ve received from designers or design teams in the past that they love or hate (may also unearth something here)
      – really working to understand what they’re up against, how the application is structured, and being willing to get a little dirty in the guts of the thing, reading database schemas, etc.
      – treating engineering as one of many clients (even if you’re internal), and a clear understanding that if they don’t get something useful and some good support out of design, the designer might as well not have bothered

      When I was much younger and had that working against me too, I remember an engineer at Netscape who could never suppress a sneer whenever I had something to say. I was constantly waved off and ignored. Finally, thanks to my mathematics background, I had the opportunity to make an offhand joke about Zeno’s Paradox. He looked at me in utter shock — his jaw actually fell open. From that moment forward, I never had a problem with him and we worked very well and happily together.


    5. I thought of another one:
      – succinctly but explicitly describing your background, especially if you’ve worked closed with heavy-hitting engineering teams like Netscape or Sun


    6. Great read! thanks for this… very helpful information that i will definitely be sharing with my dev team!

      #4 has really been vital to the success of a lot of our recent projects… making sure that communication is open and that we speak one another’s language is so key and increases the value of our products, and productivity of our team.

      ~Aaron I


    Leave a Reply