BlogmyQuery – BMQ

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

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

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

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

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

“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

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

“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

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!

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.

Translations:
Italian

RSS readers: Don't forget to join the discussion!

I’m ready to admit something: I don’t really prepare for a client pitch. Well, OK, that may be a slight exaggeration. Sometimes I pre-load some web pages in a browser in case there’s no Internet access. If I’m going to show logos or before/after shots, I have been known to throw some images in a PDF template. But I don’t write speeches. I don’t have elaborate slideshows. I don’t really “present” in the traditional sense. So what do I do? And why don’t I run out of the room to throw up when they all turn to me and someone says “we’re really looking forward to seeing what you have to show us?”

One of the bands I used to play in was a free improvised music group called Unstable Ensemble. We would tour the US once a year, and every night the music was different — we just sat down and played.

What I learned from the Unstable years, more than anything else, is that playing music well is about listening. “Open your ears,” we used to say. You hear what the other players are doing, you start to see where they’re going and — when the time is right — you join the conversation. You adjust your playing as you go based on the feedback you’re getting from the other musicians. And the further you go down the road, the clearer the “plan” becomes. Once you’re really all in synch, everybody can see the ending coming a mile away.

This is improvisation. You may have some vague plans about what you’re going to do when you sit down. But you’re always listening, watching, and ready to throw all your plans away if a better avenue presents itself. What you really bring to bear in the moment is not a rehearsed plan, but the sum total of your cumulative knowledge and experience to that point.

In a client meeting, I take a similar approach: I allow the whole group to lead. I listen, and let my potential new clients talk about themselves and their organization. What they think the project is, what they think the problems are. When it seems like the right time, I begin weaving in themes from my own knowledge and experience: how we might approach their problems, examples of similar things we’ve done for other clients, or examples of relevant solutions that other talented people have created that come to mind (explicitly credited, of course). I always try to keep one eye on people’s reactions, and help adjust our trajectory appropriately. When everyone seems bored, it’s time to move on to another subject. When everyone’s suddenly rapt, maybe I should expand a little on what I’m talking about. Following these cues helps keep the experience closer to an interesting conversation, rather than a hit-or-miss presentation.

In college I saw a video of Bill Evans, the famous jazz pianist, talking about improvisation. His primary message was this: to be a great improviser, you must learn music theory and technique so well that it’s automatic. You relegate it to the unconscious, freeing your conscious mind to make creative decisions in the moment.

Meetings are the same. They are a performance, but you are not the only player. If you know your subject well enough (you should, you live it every day) you don’t need to sweat it. Just bring your brain and, just as important, your ears.

I once pitched to a potential client against two large international marketing firms. After we won the (for us) considerable contract, our contact there confided in me that the other firms had superior “dog and pony shows.” But after interacting with us in a less-prepared, conversational manner, he was convinced that we would “get” their project and the challenges involved more than the others.

Ultimately your clients don’t need to be blown away by a fancy presentation. They need to see that they can work well with you for the coming months, or even years. Don’t give them a presentation, give them a demo. This your opportunity to say to them, “this is what we’re like to work with, this is how we listen, collaborate, solve problems.” Wouldn’t you rather hire someone you knew you could work well with, rather than someone you knew could put together a wicked-hot Keynote presentation?

So forget the slideshows. Open your ears. Improvise. Be genuine — the person that you are every day in your job — right there in the room with them. Then you’ll win the clients you should win. And, hell — let someone else have the ones you shouldn’t.

Translations:
Italian

RSS readers: Don't forget to join the discussion!