After leaving MediaCross as Interactive Creative Director in May 2011, I spent a lot of time getting back into producing work. I found it exciting and challenging to have the opportunity to get my hands dirty again; to actually design instead of merely discussing the finer concepts of what good interactive strategy is. By August 2011, I finally had a break to do some reading and picked up a couple titles from A Book Apart: “Responsive Web Design” and “Mobile First.” I spent three weeks in Ukraine traveling and digging through these titles — I learned a lot.
Sure, I know it seems like I dived into this whole responsive design thing really late in the game, but that’s the nature of the advertising business at a small agency. I thought I was on the bleeding edge; that I knew it all. Suddenly, I found myself in charge of single-handedly developing the interactive division at MediaCross. I was setting baseline development standards, interviewing interactive designers and developers for our team, and defining a bunch of contract terms and goals for the sales staff. I forgot all that I knew… and stopped learning.
Much of what I was encouraging our team to focus on were 960 fixed-width grid systems and cross-browser compatibility hacks. As a leader, I was reluctant to redefine guidelines based upon this new-fangled “responsive” grid system because I didn’t fully understand it. Sure I’d heard about it, but it wasn’t until MediaCross changed their business strategy (becoming a production shop instead of a full-service agency (and I was without purpose as a Creative Director)) that I had time to actually investigate the concepts.
After reading aforementioned titles, I was eager to get started applying what I’d learned. Fortunately, I could do this on a freelance basis. And fortunately, I am talented enough to both design and develop websites. But, I’m working in a vacuum this way. If I were to take what I learned back to my old role and teach what I’d learned to my team, we’d have to start by rethinking our entire design and development process. Take the following excerpt for instance:
“Let’s pretend for a moment you’re redesigning a site with only one page, so you knock out a mockup in your favorite design application. But how do you communicate to your client how that page will appear on a phone? Or an iPad? Or a widescreen display? If you’ve the time, budget, and resources, it might be feasible for you to design each of those alternate views, presenting those comps to the client, gathering feedback, and then revising each as needed. But if you’re designing fifteen pages, or fifty, then it can quickly become impractical to produce every one of those mockups and their alternate views.
Recently, the responsive projects I’ve worked on have had a lot of success combining design and development into one hybrid phase, bringing the two teams into one highly collaborative group. I refer to this new, Voltron-esque phase as “designopment.” (No, not really.)
The open questions are a really great forum for the team to share ideas, to discuss how the design is intended to function on different displays, and to review any particularly complex pieces of interaction. If any design feedback needs action, then the design gets revised. But if the group feels comfortable, or if the revisions are sufficiently minor, then the development team inherits the comps for some prototyping.
“Prototyping before the designs are final, you say?” Absolutely, I say. Our goal is to get beyond the pixel limitations of Photoshop, and begin building a design that can flex and grow inside a changing browser window, that can scale to different devices. So the development team quickly begins producing a responsive design: converting the fixed grid into a fluid one, discussing ways to flexibly handle different types of media, and then finally applying the media queries that adapt our design to different resolution ranges.
During this development process, a prototype begins to take shape. It’s based on the initial mockup supplied by the design team, of course, but as the development team codes they begin making recommendations about how the design should respond to different devices. In other words, during this collaboration the developers act as designers, too; they’re just designing in a different medium. They’re making design recommendations within the browser, rather than in Photoshop—recommendations that will be shared, tested, and vetted by the entire team.”
If you design mobile first, you create agreement on what matters most. You can then apply the same rationale to the desktop/laptop version of the web site. We agreed that this was the most important set of features and content for our customers and business—why should that change with more screen space?
It’s all too easy to fill a desktop browser window with social media toolbars, links to related articles, battalions of RSS links, and tag clouds galore. (This process is called “adding value,” I believe.) But when we’re forced to work with a screen that’s 80% smaller than our usual canvas, nonessential content and cruft quickly fall away, allowing us to focus on the truly critical aspects of our designs.
In other words, designing for mobile devices first can enrich the experience for all users, by providing the element often missing from modern web design: focus. That’s not to say that our client’s pages are light on content, or lacking in features. But by framing our design process with that simple question, we’ve gained a handy acid test to apply when considering each proposed element, each new piece of functionality.”
—Ethan Marcotte. Responsive Web Design (Kindle Locations 1579-1586). A Book Apart.
Do you see now? Responsive design is not just a problem for that design/development team that I used to lead. It also includes the creative teams that are collaborating to create content for a variety of devices.
Because I love collaboration, I’d love to be a part of a team like this in the future. For now, I’ll continue working with my strategic partners, collaborating with this vision in mind.