[Editor’s Note: Our Tech Blog isn’t responsive yet, but it will be soon. We hesitated a little before publishing an article about the responsive process on a site that hasn’t gone through it yet — but decided to go ahead and publish it anyway! For some examples of where Constant Contact is using responsive design successfully, we recommend our product site or our marketing blog.]

Responsive design is a hot topic, but it seems like nobody really knows how to do it. It’s alarming how few people understand that “going responsive” isn’t just a matter of getting a few extra designs, installing a plugin, and adding a few extra days of work. An effective responsive process requires dramatic changes to our day-to-day workflow.

In this article, you’ll learn what happened when we tried to shoehorn responsiveness into our regular workflow, how we learned a better approach, and what you can do as a project manager to make your next responsive project go more smoothly.

Ethan Marcotte’s “Responsive Design”

Not sure what exactly responsive design is? The term comes from a popular article by web designer & developer Ethan Marcotte, calling for developers to build web pages that actively adapt to devices like phones, tablets, netbooks, or whatever media your visitor happens to be using.

In his article, Marcotte writes “the three technical ingredients for responsive web design [are] fluid grids, flexible images, and media queries.” Using a fluid grid means designing to screen proportions instead of fixed pixel values. Flexible images mean delivering and formatting images that are appropriate for the device requesting it – for instance, a Samsung Galaxy S4, a 13” MacBook Air, and a Microsoft Surface might not all need the same image. Media queries are little bits of inline logic for your CSS that allow you to deliver style rules to some visitors but not others, based on things like resolution, color depth, aspect ratio, etc.

It isn’t just an extra step

But the problem isn’t that people don’t know what responsive means – it’s old news! That popular Ethan Marcotte article was published in May 2010, nearly four years ago — if you went out to buy the newest, shiniest iPhone on the day that article was published, you came home with an iPhone 3GS. The problem is that most people don’t know how to go about building a responsive site. It’s more than just asking designers to deliver more mockups for different resolutions, and asking developers to implement a new CSS grid. It means fundamentally changing the way your team works.

How we learned about “making it responsive”

My team started talking about making an alternate version of our sales and marketing site where we could rapidly test new ideas and technologies.

What if we:

• Delivered a pared down experience with a stronger focus on signing up for a trial?
• Translated that site into one language or another based on geolocation?
• Enabled pages to grow or shrink based on the size of the visitor’s display?

This all sounded exciting, so I volunteered to lead the development on the project while my colleague Chris Chiusano led the design. He researched mobile designs and made mockups in Photoshop, while I researched coding techniques to build a mobile-friendly site.

Chris started with mockups for desktop purposes and Web pages. Everything seemed modular, which would put us in a great position for making all the pages’ elements mobile-friendly. I focused on obviously written markup that anyone could pick up and reuse.

Then the mobile mockups started coming in, which also looked great … until I compared them against what I had already built. I worried about drop down menus and buttons appearing in illogical places, and things that would need bigger conversations, like how we were going to deal with hover interactions on touch screens where the concept doesn’t make any sense.

What concerned me the most was that the designs showed mobile versions of page elements that simply couldn’t share the markup I’d already written for their desktop equivalents. I’d basically need to rewrite significant parts of the page. Aside from the obvious time issue with building two versions of the same page, how mobile-friendly would the end result really be for visitors with potentially slow or unreliable Internet connections? Deliver twice the markup, just to hide half of it?

Collaborate, collaborate, collaborate

I got frustrated and started thinking maybe Ethan Marcotte and his responsive design article were one philosophical Sun Tzu quote away from being totally full of it. Not only did his prescribed approach seem like a fairy tale, it was incompatible with our tried-and-true “design it, then develop it” process. Putting all that aside, Chris and I knew that we’d have to change the way we were working if we were going to deliver on time.

We had to change our workflow, and work together — basically pair programming. No more of this waiting for mockups nonsense; we could make things happen in the browser. Together, we fiddled with every page component.  All the changes were on the screen, happening live. I didn’t have to explain to him why the headline didn’t fit – the headline was right in front of us, not fitting. Working together and testing new solutions, is when we started getting traction.

Identify obstacles early

From a coding perspective, the biggest technical challenge we faced was the pricing table on our new site, which needed to show a number of rates. It was an absolute circus in regards to typesetting: subscript, superscript, precarious vertical-alignment, varied kerning, a dozen different font sizes, etc. And of course after I’d built it on desktop, it was time to “make it work” on mobile.

It was the definition of a time sink, and a great example of where it would have been smart to get involved in the design process sooner. Part of the collaborative process means knowing when to push back on designs; there were plenty of other ways we could have displayed that same information that would have taken less time to code.

I think developers are great at taking designs, banging away on our keyboards for few hours (or days), and then coming back with successful implementations. Unfortunately, that skill isn’t as useful because the new responsive process doesn’t work that way anymore. It’s not effective to make something for desktop, and then retrofit it for everything else. I call this the build it, then make it responsive approach, and it totally misses the mark.

Instead, get designers and developers talking much earlier in the process than they traditionally do. If you see something that’s going to take a lot of time, make sure that it’s important enough to justify the hours. If it’s not, the pressure is on the developer to offer some alternatives as early in the process as possible. The trick is that it’s not always obvious what’s hard and what isn’t until we start building it.

Where to start?

A restrictive, low-resolution (mobile) display is the smartest starting point. Besides being a useful exercise in content prioritization and identifying your site’s goals, it’ll help keep you from falling into a situation where you’re delivering two different blocks of content just to hide one or the other based on resolution. Let your markup help to guide your design process.

Here, web developer Brian Doherty describes delivering content just to hide it for a pricing table that called for a way to toggle between basic and advanced views.

“We were delivering the simplified version to both [mobile and desktop visitors]. On desktop we’d have a button underneath the simplified version to toggle out the more complicated version. So then you’d see the gigantic table with a billion things on it. We started to talk about, from a dev perspective, ‘How are we going to try to finagle this in [to mobile]?’ We were looking at it like, ‘I have no idea how to tackle this thing,’ and we brought up that this was going to take some time. The question came: ‘How do we display it on mobile?’

“The answer was: ‘Well, we don’t.’”

Instead of spending time trying to fit a ton of content on a small screen, the team decided it didn’t belong in the mobile experience. “The idea was the button to toggle was hidden on mobile, so you’d actually never know that it even existed,” Brian explained.

Eventually, that overwhelming pricing table outlining possible discounts eventually got scrapped altogether from desktop experience.  “We did an A/B test with removing the button that allowed you to toggle it, and they found out that just not showing all that extra information was actually better.”

Just do it

In the end, we need to stop asking about the status of the responsive designs, and start building things in the browser sooner. Invite developers to the design conversation earlier, so that they can have a strong presence in that conversation. But your project should move from conversation into creation quickly, because the difficult things are not always going to be obvious to developers right up front.

Let your design and development team start within tight design constraints (mobile) and work their way out to bigger resolutions and devices with more capabilities. We’re all still learning how to build responsive sites, and the best way to do that is by actually doing it. So start building!

Share the challenges you face implementing responsive into your product, and how you’ve conquered them in the comments section.