An Event Apart: The Responsive Designer’s Workflow

by Luke Wroblewski August 8, 2011

In his presentation at An Event Apart in Minneapolis, MN 2011 Ethan Marcotte talked about applying responsive web design principles and workflows to the redesign of a major newspaper Web site. Here's my notes from his talk on The Responsive Designer’s Workflow:

  • Storytelling and crafting an object are intertwined. We create objects that can tell our stories whether they are physical journals or a series of tweets.
  • Physical newspapers contain the most important information for a day then their value is lessened over time. And increasingly they have less relevance as nearly half of all American results get their news through a mobile phone or tablet. The industry is trying to catch up through iPad apps, mobile sites, and more. Responsive Web design is another strategy to consider.
  • What makes a design responsive? Three ingredients: flexible grids, flexible images/media, and media queries. But these three elements are just focused on layout. Layout is not design. “Design is putting form and content together.” Design is the means. The process of how we get there. How do we become more responsive designers? This is the start of a conversation.

Working Responsively

  • Ethan recently got to go beyond layout and apply responsive design principles to a lot of the redesign process for the Boston Globe Web site.
  • Creative process is often managed as tasks. Our thinking is often linear. We finish one task before moving on to the next. We have hand-off points where tasks move between different skill sets like visual design and front-end development.
  • But the design process of a responsive site is not done at any one point. How do you convey how a design will adapt itself in a single comp? You can’t. Process needs to change.
  • Our tools are also stuck in the old model of building Web pages. So new forms of sharing and collaboration need to be figured out.
  • To create a responsive site for Boston Globe, there was unified collaborative design and development team.
  • Designers “introduced” a comp, developers asked lots of questions about why the page is designed as it is, especially the big one: how will the content adapt? How will the interface adapt to touch, mouse, keyboard? Don’t need to have final answers to these questions but want to understand the process and the decisions made.
  • The developers also ask a specific question of every element on the page: what value does this provide for users on mobile? This question help force a mobile first approach to design.

Mobile First

  • Why Mobile first: traffic has exploded, new capabilities, and narrow screens force us to focus. In many cases our mobile experiences are focused while our desktop experiences are cluttered. Going mobile first pushes focus everywhere.
  • A question of context: what are the different goals of people on mobile & the desktop. We can be focused when using mobile and focused as well. We should leave the mind reading to the professionals. Context doesn’t necessarily dictate people’s intent.
  • People click the desktop link because they feel they are missing out.
  • When going mobile first you are making a commitment to the content on the page. Everything needs to be there. What is the value of every element on the page? This applies to all device experiences.
  • Content first allows you to determine what needs to be in the design. Mobile can be used as a forcing function for simplifying things on all device experiences.

Prototyping

  • You need to move past comps quickly then prototype like the wind to explore responsive designs.
  • Figure out the proportions of a flexible grid using: target divided by context equals result.
  • Can use Scott Jehl’s responsive images code can serve appropriately sized images to the Web browser by swapping out img src attributes. It defaults to the smallest image. Or you can use img max-width 100% if appropriate.
  • Media queries: first look at the devices you are trying to support. Then identify common breakpoints. Small screens, portrait & landscape, tablets portrait & landscape, and widescreen.
  • Media queries are like conditional comments for CSS. Allow us to serve up different code for different device attributes. Media queries support different break points and define adaptation points.
  • Designing in the browser allows the developers to make recommendations for how things adapt and doesn’t require a design comp for very single resolution point.
  • Web fonts are limited to desktop resolutions due to files sizes and readability concerns
  • Verify your work live on different devices in an interactive design review. How well does the layout adapt? Do individual modules still feel usable? Do any elements need additional design direction? Rinse, repeat, and refine as needed.

Flexible Foundation

  • A flexible foundation is really key for responsive design. A flexible foundation allows you to quickly refine new breakpoints. It also means less code to write. And better adaptability.
  • The mobile Web allows us to revisit the talk of inclusion, progressive enhancement for everyone.
  • A responsive layout meets mobile first. Default to a linear, small screen friendly design. Media queries based on min-width scale up, not down.
  • Media=”only-all” is a test to see if site supports media queries. Can create a reading experience that works on less capable devices.
  • Then use a few lightweight tests. Test to see if you have @media query support or IE. If so, take the basic stylesheet out of your document entirely. You can also adapt based on touch support and Javascript functionality.
  • A designer’s choices are a small limited form of tyranny. The philosophy of a responsive design might not be appropriate for the audience you are supporting. The decision to build a responsive or mobile site is often more about the team’s capabilities and decisions than anything specific to devices.