Dissecting Design – Part 1

Originally published on Sparkbox in Sept 2013.

Already read part one? Read part two of the article here.

For some time now, the mystery of “designing in the browser” has haunted web designers around the world. Andy Clarke was the first person I remember speaking about this, but since 2008, this idea has polarized our industry. At Sparkbox, we see designing in the browser as one of many tools needed to be successful in building for the web today. The question then becomes, “How do we advance design through a more collaborative web process given the tools we have at our disposal?” In order to make good decisions about our tooling, we need to dissect design.

Establish the Aesthetic

In the past few years, we’ve recognized the danger in jumping headfirst into full-comp design before we really understand the design direction. Other disciplines have recognized this for a long time—think mood boards in branding—and taken steps to ramp up their design effort. The goal here is to establish the basic building blocks we’ll use in the rest of the design process: things like color, type, texture, illustration style, photography treatment, iconography. Once these are established, the success rate for the rest of the process is greatly increased. There are a number of ways to do this on the web; let’s look at a few.

Style Comparisons

My friend, Dan Mall, shared this idea in our presentation at the first Artifact Conference. He’s also written about this idea in the context of working with a contractor to build a new office space.

I could create an illustration or a 3D rendering of what I want my new office to look like, but that doesn’t take advantage of [the contractor’s] great ideas. It’s dictation, not collaboration. Instead, I show him a Pinterest board my wife and I created. I tell him that I love these beams or this mix of materials and we can have a conversation. I revise my ideas through his expertise, and vice versa.

In the context of the web, we might start the conversation with our client by showing opposite variations of these basic building blocks, asking these kinds of questions:

• Would a dark site or a light site be better for your brand online?
• Would an illustrated style or photographic style work better?
• How about a flat look or a textured look?

And, ideally, we don’t just ask these questions; we show them some options. In a matter of a few hours any reasonably talented designer can put together a presentation with opposing examples of these questions. Giving our clients a series of visual A/B options can often help us identify the appropriate direction very quickly.

Style Tiles

Samantha Warren introduced the idea of “a mood board for the web” when she created Style Tiles. She defines them as:

…a design deliverable consisting of fonts, colors and interface elements that communicate the essence of a visual brand for the web.

She creates these in a static design tool and exports them as images for her clients to review. Often, she’ll create several for a specific project to present a variety of options, again with the goal of determining the design direction-establishing the aesthetic.

Style Prototypes

Rob Tarr and I had an opportunity to hear Samantha present style tiles at SXSW Interactive in 2012. The concept made a lot of sense to us, but we left that presentation with the idea that this could just as easily be done in the browser. Shortly after, we started using style prototypes at Sparkbox and have never looked back.

Essentially, these are very similar to a style tile, but built with HTML and CSS. We’re able to get the same benefits of style tiles, but with the added ability to show real web type, demonstrate more accurate color, and introduce the conversation about browser support very early in the process. We ask our clients to review them in their browser of choice, which means they can open them in old IE or on a small screen device—whatever they prefer. Not only are we establishing a solid design direction, we’re combatting the problems that static design deliverables introduce by managing the expectations of our clients. We have several of these online for anyone to take and use or modify as they need.

One additional benefit of doing this in the browser is that these style prototypes can evolve into pattern libraries for your project. There are many benefits for providing your customers with a simple method to view all the components in their design system. Dave Rupert said it best: we should be delivering “tiny bootstraps” to our customers.

Guiding Decision Principle: Comfort

In evaluating what tools to use to establish the aesthetic of a web project, I believe the most important factor to consider is comfort. At this point in the process, you need to explore possible design directions with your client. Doing so in a comfortable way as you learn how to work with this specific customer can help establish a great foundation on which to build a long-term working relationship.

Much of the conversation around design deliverables in responsive ends here. However, once we’ve established the aesthetic, there’s still a lot of work to do. Let’s talk about solving problems.

In part two, Ben continues dissecting design by talking about solving problems.