Dissecting Design – Part 2

Originally published on Sparkbox in Sept 2013.

Missed part one? Read part one of the article here.

Solve the Problem

I’ve been amazed at how often those outside the discipline of design assume that what designers do is decoration. Good design is problem solving.

This quote from Jeffrey Veen sums it up nicely—“good design is problem solving.” If you’re a designer, you know how true this is. The bulk of the work of design is done here, so we need to carefully evaluate the tools we’re using to solve design problems.

Static Design Tools

As I’ve had opportunity to ask people what tools they use to solve design problems, mostly the answer I get back is a static design tool. It’s really no wonder: people have been doing this for a long time—this is comfortable—and change is hard. There are always the standards: PhotoShop, Illustrator, InDesign. However, there are also a whole crop of new design tools that cost (and do) less than the suite from Adobe. Acorn, Pixelmator, and Sketch are just a few. These newer static design tools tend to cost less than $100 and brag about their “non-bloated” feature sets.

Also, most designers still rely on paper and pencil (or whiteboard and dry-erase marker) to quickly convey their ideas. We do this quite a bit at Sparkbox, and I often find myself taking pictures of whiteboards to save these ideas with the rest of the project files. This can be a fantastic way to iterate on design ideas in a collaborative setting, and it’s an indispensable part of our process.

RWD-Specific Tools

There is a new crop of “responsive design tools” on the market now as well. Adobe has been touting Adobe Edge Reflow as a tool to “design the responsive web.” Froont is a web-based, drag-and-drop interface for creating responsive HTML and CSS. And more recently, Macaw made quite a splash, encouraging us to “stop writing code” and to “start drawing it.”

Most of these tools are a hybrid of pixel-pusher and text editor. They allow you to create grids, set breakpoints, import and manipulate assets, and export HTML and CSS when you’re done. They also allow you to control the style of elements using the properties of CSS that you’re probably familiar with.

The kind of feedback I’ve generally heard about these tools so far is that they’re great for rapid prototyping but not ready for generating production code. I do believe that our industry’s obsession with “handcrafted” code is hugely beneficial but also that it precludes us from giving these tools a fair shake. Regardless, it’s quite exciting to see people striving to solve the problem of flexible design with a UI that hopes to even the playing field. So far, in my opinion, there’s no substitute for knowing the intricacies of CSS and being intentional about how it’s written and structured.

In-Browser

Finally, some are able to jump into their favorite editor and solve design problems with text. Combine a fantastic text editor like Sublime Text, VIM, Coda, or Espresso with a modern browser, and—in the hands of the right person—magic can be made.

Throw in the developer tools shipping with those browsers and a front-end developer framework or two, and this becomes a seriously legitimate option.

Guiding Decision Principle: Fluency

I believe many people in our industry struggle with “design in the browser” simply because they aren’t fluent with the tools needed for working that way. I’ve heard many people say, “Happy accidents don’t happen in code like they do in PhotoShop.” I can testify that this is absolutely not true. Instead, I believe it’s about where you are the most fluent.

As we evaluate the best tools for the monumental task of problem solving in design, I keep coming back to the ideal of fluency as a solid principle on which to base the decision. You can’t write poetry in a language you don’t speak. Similarly, you can’t craft design using tools you’re not fluent with.

It’s also important to draw a distinction in the “solving problems” mode of design between solving layout problems and solving component problems. Brad Frost has written about this recently and others before him (check out 34 minutes in). We do draw this distinction at Sparkbox. I’ve seen that we do a lot of hand sketching in our early thinking about layout, whereas we tend to use static design tools (currently PhotoShop or Sketch) to work through design for modules. What’s primarily important is that you solve design problems where you, your team, your project, and your client need to.

Refine the Solution

At some point in designing for the web we cross the threshold of problem solving and shift into the refinement of the solution. On charts like this, it’s usually called the long tail, and it can go on forever if you let it. Designers, in particular, will move pixels around, shifting and tweaking their design until it’s perfect. I’m not suggesting that this care for the detail of a UI is not critical, only that we must shift into the final medium—the browser—when this refinement takes place. Otherwise, we’ll have to refine twice, and most people don’t want to pay for/waste that time. In order to combat this waste of time, we’ve made a conscious shift toward design pairing.

Design Pairing

At the time of this writing, we have 20 people working regularly in our office. By title, we have one designer, our Creative Director Jeremy Loyd. Jeremy sets the design direction and begins the design problem solving for every project we have. Then, he pairs with our front-end developers to carry out the design in code.

We also happen to believe that front-end developers must have a very keen design sense, and so this is part of how we hire for that role. This gives Jeremy the ability to trust that his design intent will be honored as new problems are solved in the browser. Then, when it’s time to refine the solution, Jeremy can work very closely with our front-end team to refine in the final medium.

Guiding Decision Principle: Efficiency

We have based our decision to avoid static design tools during solution refinement because of a desire to be efficient with our time. As the graph above indicates, this takes a lot of time with a small amount of actual change (even though the value of that change is arguably high). Because of this, efficiency is a critical factor in determining what methods to use for refining your design solution.

Unfortunately, understanding the impact this can have on efficiency doesn’t make it any easier to determine when you’re switching from solving the problem to refining the solution. The ability to recognize this switch is something that must be learned. And, it’s not easy for anyone other than the designer to tell, which means it takes trust on the part of the team and discipline on the part of the designer. In the end, it’s absolutely worth the learning—your customers will appreciate the added efficiency, and your team will enjoy shipping faster.

Your Process for Your People

I’m constantly reminding myself that these kinds of articles can be dangerous. What I’ve documented above is what’s working for Sparkbox today, but every project is different. Many times, we find ourselves veering from these guidelines simply because of a customers budget or timeline. With so many factors to consider, there is a level of improvisation needed to figure out what is appropriate at any given time. Taking into consideration the project, client, timeline, budget, stakeholders, and team members will help you clarify the ideal way to approach design on any given job.

Seeing the separate modes of design as somewhat distinct activities opens up the possibility of combining tools to be the most effective and efficient. We’re always looking for ways to improve, and we’re hopeful that sharing what we’ve learned is helpful for you.