Dissecting Design – Part 2
The full article was originally published in Sept 2013 on Sparkbox.
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
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.
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.
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
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.
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
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.
More with Ben Callahan
Check out Ben’s virtual seminar,
Responsive Workflows: Because There’s No Such Thing as a Perfect Process.
About the Author
Ben Callahan is President of Sparkbox, Founder of the Build Right workshop series, and an author and speaker with a focus on building more flexible teams.
Share Your Thoughts with Us
What tools do you and your team find most efficient and effective in solving design problems? Tell us about it at the UIE blog.