Process

Direction and Action

| Jorge Arango

Invariably, the most popular posts on this site are the ones that deal with tools and practices. Whether I’m railing against wireframes or showing you a way to make language visible, if it features a concrete tool or technique, the post is likely to have traction. This doesn’t surprise me.

My tool-centric writings fall on the craft end of the craft ↔ philosophy continuum. Philosophy is a harder “sell” than craft. Most people would rather know what to do rather than how to think; they want things they can put in practice on the proverbial “next Monday morning.” The more actionable something is, the better.

Except that action can be undirected. And effecting action towards the opposite of “Good” (perhaps unintentionally) makes things worse. Direction without action frustrates; action without direction muddles.

I don’t aspire to give direction in my more “philosophical” writings. Instead, I’d like you to entertain the possibility that direction matters, and that you ought to discover one for yourself. The world provides ample evidence of things that are going well and things that could be better; it’s up to you to determine what those are and what you can do about them.

Against Wireframes

| Jorge Arango

Yesterday I led a bright and engaged group of folks through my Information Architecture Essentials workshop. Most of them were new to the discipline, and wanting to know more. We talked about many things, but had an especially active discussion about wireframes. I don’t like them and haven’t used them in my work for a long time. I thought it worthwhile to document my reasons here, in case it helps anyone.

Wireframes are a design artifact that has long been associated with information architecture. I’ve heard people ask to be “sent the IA” meaning they expect something that looks either like a sitemap and/or a set of wireframes. I consider these “deliverables” to be tools from a prior — more “waterfall” — era of web design and mostly a waste of time today, if not outright misleading. (I include sitemaps in this statement, even though I’m focusing on wireframes here.)

Although I’m sure it’s been written about at length (and better) elsewhere, here are some reasons why I don’t like them:

  • Wireframes are too abstract and not abstract enough. Wireframes are an attempt to explore the relationships between elements in a screen. Often this includes the relative visual priority of things. However, they attempt to extract aesthetics (the “visual design”) from these visual explorations. As a result,
  • Wireframes confuse stakeholders. I think of design artifacts as tools that allow people — both designers and stakeholders — to make design decisions. Wireframes are mostly clear to designers, but not to stakeholders. Asking folks to comment on the relative hierarchy of elements in a visual document while also asking them to ignore the aesthetics of the thing is a tall order.
  • Wireframes are ineffective as decision-making tools. Visual design affects the perception of the relationship of elements on the screen. Font and color choices affect the relative prominence of elements. More abstract wireframes fail to convey these important distinctions. On the flip side, less abstract wireframes are close enough to visual design to derail the conversation towards the lack of aesthetic nuance. As a result, wireframes are seldom effective in helping people make design decisions.
  • “But,” you may protest, “we don’t use wireframes to make decisions. We use them to convey decisions to developers.” Alas, wireframes are also ineffective as design documentation. Wireframes require more effort to produce and maintain than lower fidelity artifacts (like freehand sketches.) Evolution of the design seldom stops when the wireframe deck is complete, leading to either the deck becoming outdated or — worse — design being “fixed” because the wireframe deck is now “signed off.”
  • Wireframes give the impression that things are more polished than they are. I’ve seen designers present early-stage ideas as wireframes. (Perhaps because some folks are uncomfortable drawing freehand?) These artifacts can look very clean and beautiful, leading the viewer to assume that the ideas they present have been thought-through. Often they haven’t.
  • Wireframes are relatively expensive to produce. Given that so many organizations are using design systems these days, building a comp using a tool such as Sketch isn’t that much more work than making a more abstract artifact such as a wireframe.

So what’s a better way of doing it? I prefer freehand drawings, which allow designers to vary the fidelity of artifacts on the fly. Nobody confuses a freehand drawing with a more polished artifact. Freehand drawings are fast, cheap, and disposable; if somebody has a great new idea, you can draw it on the spot. Yes, this requires that designers learn to draw. (I’m still astonished that some people protest this; communicating visually is essential to design work.)

My preferred way of sketching freehand is to use the Concepts app on the iPad Pro. This app treats the lines I draw on the screen as vector-based “ink”; I can select sets of lines and copy them, paste them, delete them, stretch them, mirror them, etc. This allows me to reuse elements (such as window chrome) across drawings, speeding up the process tremendously. Concepts also allows me to share drawings directly to Slack, email, or other channels. The result: very tight feedback loops that enable the design process to move much faster.

What if you’re communicating design intent to developers? In that case, comps or prototypes do a better job than wireframes. It’s not unusual for developers to ask to be sent Sketch files so they can pull out things like colors and element sizes.

Of course, there may be exceptions to all of this. Some teams may have particular circumstances that allow them to move fast using wireframes. Some industries may require them as official documentation. But in my experience, they aren’t very effective. If you’re a stakeholder, don’t waste time and money by asking your designers to create wireframes. And if you’re a designer, learn the basic principles of drawing by hand (such as the use of distinct line weights, how to start and end lines, etc.) You’ll get better results faster.