So I've got a confession to make: When we started working on the new Boston Globe website, we had never designed a responsive site before.

This shouldn't come as some huge shock. I mean, raise your hand if you'd built a full responsive site back in November 2010. (You can put your hand down now, Mr. Marcotte, that was rhetorical.) Since so few had done it — and certainly not on this scale — we kind've made things up as we went along. In fact, the entire Boston Globe team worked in a laboratory environment.¹

Here at Upstatement, we experimented with how to solve design and layout problems within a responsive framework. We learned a helluva lot as we went, like how to choose the right design software, strategies for thinking through breakpoints, and some best practices for designing in the browser.

Ready? Good. Cos here we go …

Choose Your Weapon

Before laying down a single pixel, there was an important decision to make: What design program to use?

Eventually design would be done directly in the browser — there's no better tool for interactive design, especially when you're working with fluid layouts (more on all that later). But first we needed to establish the aesthetic and plan high-level pages. It helps to answer the big questions before getting to the browser — and it was imperative for a site as sprawling as The Boston Globe, with lots of specific page templates and multiple iterations for each breakpoint.

So we lined up the usual suspects from Adobe. Who would be our partner in crime — Photoshop? Illustrator? InDesign?

Hands down, the answer was InDesign. At its core, BostonGlobe.com is a publication website, and InDesign is the best tool for laying out publications and content. Yes, there are huge differences between designing print publications and designing for the web, but consider this: Most web pages are simply a combination of photos and text. And where Photoshop excels at manipulating images (but sucks at type) and Illustrator is exceptional at typography (but sucks with images), InDesign is built for both.

Even better, InDesign's internal logic parallels that of web design and development. Every new document begins with a grid. It uses type and object stylesheets that should be familiar to anyone who has used CSS, allowing you to change the characteristics of every headline (or object) from one master style.

InDesign stylesheets

For type, you adjust all the attributes you'd expect (size, color, font, kerning, tracking), and others you might not like space before / space after (which is basically just margin), and CSS3 techniques like shadow and gradient. This way of working maps directly to development work, from the style names down to the design characteristics.

InDesign's master pages palette

Like the web, InDesign also has a notion of templates. We used master pages to hard-code common elements and create a baseline for every section, article, or project page. Heck, you can even nest InDesign files inside of InDesign files. Change the header once and it automatically updates in every template — just like using an include.

Try creating a complex system like that in Photoshop.²

And Now It’s Time for a Breakdown

With InDesign locked and loaded, we were ready for the fun part — the design itself.

Knowing that we'd nail down details in the browser, early designs aimed to answer big questions. What are the key breakpoints? What do major templates look like at each breakpoint? What do the header and footer look like? What content appears on the homepage, various section fronts, and article page? What's the overall look and feel?

Lucky for us, there was an all-star team in place to help us answer some of these questions. We had Scott Jehl, Todd Parker, and the super-smart crew at Filament Group as well as two hired guns/all-around badasses in Ethan Marcotte and Mat Marquis. From the Globe, Miranda Mulligan expertly guided the whole process.

We sat down together at the beginning to lay out some of those high-level design decisions. Most important were the breakpoints, the screen widths where we would optimize our designs. A fluid grid would fill the spaces in between and adapt the design to widths that we hadn’t explicitly considered (like the funky size of the Kindle Fire, which debuted a full year after we chose our breakpoints).

To figure out the breakpoints, we surveyed the available devices — smart phones, dumb phones, tablets, laptops, PCs, etc — and set some limits for ourselves. For a minute we thought, “What if we designed for TVs!” But the use case was too narrow. In the end, we settled on six breakpoints, heavily influenced by standard smartphone dimensions and the dominance of the iPad:³

• 1200px (which we also set as the max width)
• 960px
• 768px
• 600px
• 480px
• 320px

With breakpoints established, we used InDesign's master pages to create templates with appropriate grids for every breakpoint, then designed key pages for every width.

Designing Downward

“When I get to the bottom, I go back to the top of the slide ...”

– The Beatles

Y'all might've noticed something in the last section. I talked about the design breakpoints from largest to smallest. Gasp! That's not a strictly Mobile First approach. Uncool, man.

Well, while I love the sentiment and certainly practice it when coding a responsive site, it just wasn't the way we designed.

Our designs began at 960px, arguably the most complicated breakpoint, with several columns of content. Maybe this just came naturally after years of designing for that width. But I think it's more than that. It's easier to design with more screen real-estate — you see more at one time, you have a more nuanced hierarchy. And it wasn't just for this project; we've designed subsequent responsive sites the same way.

So starting at 960, we designed downward. Every decision informed the one before it and the one after; we flipped back and forth between breakpoints a lot. As the Mobile First mantra suggests, designing for mobile was most instructive because it forced us to decide what was most important. And since we refused to hide content between breakpoints, the mobile view could send us flying back up to the top level to remove complexity.

The process felt a bit like sculpting. We started with a big block and worked our way down, paring as we went, giving the site its shape. Later, when we started coding, there was a shift. Design had answered the big questions, freeing the development to take a layered approach, with a stylesheet that defined the base and then added more complexity (up and up and up) based on device-width and capability.

We loved working this way. As I design anything, I'm asking myself what's absolutely necessary and how I can simplify. The responsive design process regimented this way of thinking. Stepping through each breakpoint helped us stay simple.

Putting it into Practice

The header is a great case study in designing responsively. Even though it was the first design element that we completed, the team kept iterating on it. We continually refined the design while Scott and Ethan rewrote the code to make it perfect for every situation.

But let's start with the basics. The header needed to support The Boston Globe flag, search, weather, classifieds, account info, basic site utilities, not to mention the navbar, itself a world of complexity. The nav has eight standard sections that derive directly from the newspaper (News, Sports, Arts, etc.), plus Today's Paper and My Saved List.

960px

Again, we started at 960px. The header does some heavy lifting — lots and lots of requirements up in there. We settled on a balanced arrangement that followed our simple design aesthetic. In the nav, everything fits perfectly across a nice horizontal line. And what fits at 960 also fits at 1200px (not pictured). So far, so good.

With so much content in each section and the multitude of subsections (each one has at least six), we designed a super-dropdown in the navigation that allows quick access to top stories and subcategories within each section.

768px

At 768, things start to condense a bit. Space is getting tight. We ask ourselves, what are the shortest possible section names? Is it necessary to take up precious real estate with a section called "home"? (Answer: No.) What happens in between the major breakpoints? Can we use longer section names with ellipses? (Answer came in code: And, ummm, no way. Not unless you're comfortable asking folks to click on "Today's Pap …")

In these designs, My Saved was excluded from the navigation, largely because of space constraints. At larger widths, we expected it to appear fixed at the bottom of each page. But — oops — fixed positioning has sketchy support on some tablets, so we decided to roll it into the nav.

600px

OK. 600px. No way everything fits. We've got to do some organizing and make some judgment calls. First thing to go is the super-dropdown. It's a progressive enhancement and besides, isn't a key feature.

Now space is tight not only in the nav, but around the Globe logo. We ask ourselves: What are the most important navigation items? What's absolutely essential? Certainly search. That's not going anywhere. It's tough to prioritize the individual sections, so they're organized into a section called, creatively enough, "Sections." Today's Paper and My Saved are the odd ones out. They're sections, sure, but they're fundamentally different than the others. Plus, we really want to promote My Saved, which is a personal list of saved stories that you can read later (even offline).

480px

The first major design change occurs at the mobile breakpoint for landscape view, where weather pops up to the top and the flag lines up with the navigation. This keeps the header compact. Otherwise, users wouldn't have seen much of anything on the first screen.

We also ran out of room to support Today's Paper, which folds into the "Sections" dropdown. To save space on search, it turns into a button that shows the input box when clicked.

320px

In mobile portrait view, we regain some vertical screen space, so the header stacks again.

Here's another example where we simplified things in code. The initial design called for different dropdown styles for the sections at nearby breakpoints. But with coding comes clarity. Eventually we realized that it was easier to employ the same design for each breakpoint.

Looking at the header, I ignored one key element: Weather. Clicking weather at any breakpoint opens a drawer with the five-day forecast. While it doesn't deserve a play-by-play account, the progression is worth a look. You can see how the layout transforms from horizontal to vertical, and condenses as it goes. This design barely changed in the transition to code.

On the Benefits of Designing in Browser (Or, Why Static Designs Kind've Suck)

Before we get too far, let's get something straight: We hate trying to show all the complex facets of an interactive design using design software like InDesign or Illustrator. It's inefficient, inaccurate and incomplete.

Only a masochist could enjoy producing page after page of comps just to show a simple link state or a dropdown animation. I can't tell you how many times I thought I had things like that figured out only to throw it away once coding commenced. All that time is better spent just coding the behavior.

And in the end, your design isn't an accurate representation of the final product — it's not usable. You can't place it in front of users and get much feedback of any value (unless you like to let users dictate your color scheme).

It's also easy to leave things out of a static design. What happens when the user clicks here? What happens to the design between these breakpoints? In code, you've got to answer these questions. With static pages, it's easier to ignore.

Getting to the Browser

Obviously, we wanted to move into code quickly. As soon as the big design questions were nailed down, that's just what we did. This point actually came quite early in the process — after a couple weeks of static design, we started iterating in code.

Here's generally how things worked:

• Upstatement discusses requirements with Miranda and starts designing
• Each week, the entire team meets at Filament's offices to review the latest comps and ask questions
• We do a round of revisions based on feedback
• Filament Group takes the comps and starts to code
• At weekly meeting, group reviews coded comps and asks questions
• Rinse
• Repeat

This is what Ethan refers to as Design-velopment. (Yeah, we still don't have a better name.) The heart of it is really in the conversation, the discourse between design and code. Everyone around the table was an excellent designer, and we all made contributions in different ways.

During the static comping phase, Upstatement was at the wheel, driving the design. When we delivered designs, of course we hadn't thought of everything. But everyone else was there to ask lots of questions about what was best for the user, what worked on different devices, and how the designs translated at different widths.

When the conversation continued into code, Filament took the wheel and everyone else was still there to ask questions.

In between our weekly meetings, we volleyed back in forth using different mediums. Sometimes we'd send simple code notes and sometimes they'd send quick Photoshop mockups to communicate design thoughts. Code is fast, but these tools are still often faster for quickly communicating a concept.

The process was a total joy, and we've adopted it for the projects we've worked on since. The key is understanding that the design conversation is a long one, it may start with static comps but it continues through development. The more you can fuse the two (in your process and in your personnel) the more successful you'll be.