Responsive Comping: Obtaining Signoff without Mockups

If you’re making websites, chances are you’ve given some thought to what constitutes a responsive-friendly design process—and you’ve probably found that adding a mockup for every breakpoint isn’t a sustainable approach.

At least, that’s what happened at my company, Bearded, where we had spent years creating websites in Photoshop or Illustrator, having those mockups approved by our clients, then recreating those designs with CSS.

Until now. A few months ago, we stopped making static image-based mockups in favor of designing with code. This is not a new idea—heck, Andy Clarke was arguing for in-browser design in 2008. But new or not, you may still be mystified at where to begin—or feel unmoored and disoriented at the prospect of giving up the approach you’ve long relied on.

But fear not, gentle reader. Let’s take a look at our new mockup-less web design process and see just how easy it can be to get that Photoshop monkey off your back, and have a fresh new beginning with your old friend the web browser.

Let’s talk process#section2

Before we begin designing, we work with our clients to clearly define and prioritize the information that will go on the site. My first question is simple: Why do you need a website? Then I ask, what do you hope to accomplish as an organization, and what is your audience looking for? The answers to questions like these will help us define the functionality and information hierarchy of the site.

Hierarchy, hierarchy, hierarchy#section3

Once we understand the purpose of the website as a whole, we’ll apply that goal to something finite and designable, like the homepage. Before we even get to wireframing, we can express our site’s information hierarchy in the simplest possible way: as a numbered list. For a recent client, the American Association for Homecare, we ended up with a homepage list that looks like this:

1. Branding statement: The primary emotionally communicative element of the design. It does not convey detailed information so much as give users an impression about what AAHomecare represents and help them identify with the organization.
2. Variable featured content: Selected by site administrators, this area will include highlighted items from across the website such as events, pages, etc.
3. Site navigation: This allows users to find the content they’re looking for.
4. Membership: A brief list of the benefits of AAHomecare membership, followed by an invitation to apply.
5. Events: A feed of upcoming events that contains vital information and links to the event calendar and event detail pages.
6. Communications: Feeds of recent items from sources such as the blog, Twitter, or newsletters, with links to the source articles where applicable.
7. Footer content: Includes links for some site navigation, legal pages, corporate sponsors, and social networking pages, as well as location and copyright information.

Without committing to any visual decisions about how to express it, we have created an accurate top-level informational hierarchy for the site’s homepage. We now know that—no matter what the homepage looks like—if it can correctly present this information, it will be a victory for the organization and the site’s users.

My other wireframe is an HTML#section4

Once we understand the site’s content and priorities, our first visual step is to create wireframes. But as you may have already noticed, shuffling text around a Photoshop file can be time-consuming and frustrating.

But you know what’s really great for laying out content in a way that accurately expresses its hierarchy? You guessed it: HTML and CSS! So we give Photoshop a well-deserved break, fire up our favorite text editor and WebKit browser, and start wrapping our content in semantic tags using a mobile-first approach.

When you only have a few hundred pixels of width to work with, priorities become even clearer, and hard decisions even more necessary. You may often find yourself asking, “Does this really need to be here?” By focusing on mobile first, we can have these discussions with clients earlier and more effectively. And the more informational load we can jettison now, the more our users will thank us later.

Once our mobile hierarchy is clear, it’s time to progressively widen the browser and consider more complex layout decisions. Each time we encounter a width where things begin to fall apart, we can add a new media query to adjust the layout.

To help us with in-browser layout development at Bearded, we developed a responsive grid system that allows us to quickly apply nestable column properties with CSS (or, more accurately, SASS and Compass). With these handy mix-ins at our disposal, we can quickly experiment with different responsive layout approaches without a lot of cognitive overhead.

At this point, our HTML/CSS wireframes are looking pretty good. And since we’re working with the same medium (code and the browser) throughout the process, we can naturally evolve our wireframes into the final designs.

When my wireframe grows up, it wants to be a site design#section5

It’s right around this time that we’ll take a brief diversion from our HTML to define some sensible style elements (similar to Samantha Warren’s style tiles or Sparkbox’s style prototypes). This is usually a small Photoshop canvas where we bring in the typography we’ve been working with in the wireframes and start experimenting with color, texture, and imagery. Once defined, we can use these basic visual building blocks to nudge our wireframes toward website-ness.

As we layer in more visual elements, we tend to bounce back and forth between our text editors and Photoshop. But Photoshop is no longer the primary design canvas; it’s now more of a sketchpad. Do we need to tweak our typography to perfection? Nope. Can we just throw a browser screenshot into Photoshop to mock up a new background graphic on the site? Sure! Don’t want to show this sketchy, half-baked PSD to a client? Not a problem—you never will.

Not only does this method reinforce a content-driven approach to design, but it’s also crafting something that’s useful to the final product. The HTML you created for your design comp will also let developers know what kind of markup you’re looking for from the CMS. And if you’re both doing your jobs well, it means the CSS you’re about to write can be dropped into the final site with minimal adjustment.

No longer will you waste away your afternoons pushing pixels in Photoshop, only to perfect a thing you’ll ultimately throw away and rebuild in CSS anyway. Some things are accomplished more efficiently in CSS, while others render more quickly in Photoshop—so we pick the tools that feel natural in the moment. But ultimately, everything ends up in the browser. That’s how we design it, and that’s how our clients view it.

Fear is the mind-killer#section6

“Oh yes,” you might be saying, “clients! How does this new mockup-less world fit into our design approval process?” Glad you asked.

Sign on the line which is dotted#section7

Sending clients in-browser comps is remarkably easy, as it turns out. We just e-mail them a URL. Clients can look at the designs in various browsers and on various devices, resize them, click links and navigation, and check out hover states. Instead of asking our clients to pretend that an image is a website, we show them… a website.

We always provide a permanent project URL with /v1 appended to it, such as aafh-css.heroku.com/v1. From that point on, version one never changes, and subsequent revisions are posted at their own URLs, like aafh-css.heroku.com/v2. This continues until we reach an approved version.

Because each version has a distinct permanent URL (we use Heroku’s free hosting for non-production environments like this), we can still have an agreed-upon number of revisions in our contract, just like we did with static comps. If the project requires more tweaking than we envisioned, it may be time to discuss allocating additional hours to the budget.

This also allows everyone to easily go back and review each comp whenever they want. When we’re done with revisions, clients get the same signoff form as usual. But in place of a file name, the final designs are specified by that version’s permanent URL.

Now, you may be wondering if your clients will accept this newfangled process. At Bearded we’ve had nothing but positive reactions so far. Our contact at AAHomecare even tweeted about it. I don’t know about you, but that’s the first time I’ve had a client tweet about liking the design approval process.

So that’s it. Signoff without a static mockup. Terrifying, right?

Send this part to your project manager#section8

“But wait!” you say, “what about the budget? Won’t revisions take longer? What if the client hates it and we have to start all over?”

That could happen. But couldn’t it happen with a Photoshop mockup, too? And even if we have to start all over with look and feel, it’s likely that at least the HTML and wireframe layouts are good. And really with CSS (and especially with SASS) there are lots of situations where editing in code is significantly faster than editing a Photoshop file. Take, for instance, changing the link colors or font selections site-wide. Faster in CSS or Photoshop? Yep. High-five, CSS!

Luckily my early hunch has thus far proven true. With AAHomecare, our design process took longer than estimated—by about 35 percent. Not bad, in my opinion, for a brand-new way of working. Meanwhile, our CSS hours were less than half what we estimated. So at the end of the day, our project was actually more efficient and more profitable without mockups. I know your PM will be excited about that.

Designing is coding is designing#section9

All of these changes to our process are also making our roles more fluid. With our designers writing CSS, where does design end and front-end development begin?

Overlap or not, there’s still something to be said for expertise. Front-end developers can collaborate with designers throughout the process. They review everything, refactoring redundant or overly complex code and removing vestigial styling. As they find problems, our developers keep a log of best practices for designers to review later, so they can improve their coding skills and avoid repeating the same mistakes in the future.

Our initial designs will also have features and views that we still need to elaborate on, as well as interaction enhancements that we’ve left for later. So not only is our design process more development-y, but our development process is becoming more design-y. As we all work together more, we’re also teaching each other about our respective specialties and becoming a more cohesive team. In my experience, that means building better internet.

This level of collaboration can lead to toe-stepping, so we use Git for version control. Git allows multiple people to work on a central repository of code at the same time, with methods to resolve conflicts and roll back changes when necessary. Technology aside, though, a simple “Hey, I’m working on the calendar CSS” often goes a long way—especially in an environment where collaboration and fluidity are the norms.

Ready, set, implement!#section10

How do we waste less time on throwaway products? How do we make the hours we spend in front of a computer more meaningful, and the end results more effective? These are all part of the same problem.

Responsive design gives us the opportunity to rethink our whole approach to designing for the web. We can stop designing “websites” and “mobile sites.” We can create flexible content delivery systems: sets of rules that define how our content will be presented as its context shifts.

Rethinking our process is hard work, and it may strike you as challenging—even daunting. But ultimately any of the hurdles we’ll encounter are just that. They can be overcome. The internet will change, whether we like it or not—and we must adapt with it.

And really, weren’t you getting bored anyway? Let’s do something better—for our workflows, our users, and our clients. Starting right now.