Sketchy Wireframes, the Comic Sans of UX

A Sketchy WireframeSketchy-style wireframes, have wiggled their way into user experience documents the world over. With awesome tools like Balsamiq Mockups and a range of stencil sets to choose from, like as not, when an artifact describing the layout, features and workflows of a site is sent around the office or to a client, it’ll have squiggly lines.

Caveat: This post is about the sketchy style used in wireframes, not sketching in general. Sketching is an important part of the wireframing, workflow and design processes. Many a brilliant idea started life on the back of a napkin.

The reason most so often cited for the use of a sketchy style is that the squiggles convey that the document is still a work in progress. A secondary reason often follows with a claim that the sketch look obviously isn’t the site’s final design.

But sketchy style wireframes inevitably convey the opposite of what is intended, and worse, they come with additional negative implications overlooked by the proponents of the squiggle. In truth, sketchy wireframes imply that you don’t think your client is smart enough to separate crisp lines from a final design.

Simply put, the sketchy style is unprofessional. Yeah, I said it.

Would You Accept a Contract in Comic Sans?

I wouldn’t and I’m willing to bet that you would question any professional who provided you a legal document reminiscent of Garfield and Family Circle.

Wireframes aren’t supposed to be zany – they are supposed to be informative.

While our industry is young, and the tool set, younger still, we have many examples from which to learn. Architects and engineers are expected to deliver crisp lines and readable notes when they produce plans for a new home or skyscraper. The same holds true for engineers of all stripes.

Documents of any importance need to reinforce your experience, your expertise and the decisions you made as you produced them. The sketchy style does quite the opposite.

Sketchy Wireframes Imply a Lack of Importance and Conviction

Just as the final design for the site will convey a certain mood, the visual presentation of the wireframes should reinforce their importance to the success of the project. When you use a sketchy style your documents encourage the client to “fix” them.

Sketchy Wireframes Imply that Your Client Can’t Mentally Separate the Structure of a Site from its Design

While you may think this the case, you are either underestimating your clients, which is condescending or you should search for new ones, as clients who can’t understand the concept of a blueprint will likely struggle in their own endeavors. People are smart, and while you may have to explain the concept of a wireframe to a new client, the concept is easily understood.

Sketchy Wireframes Impede Comprehension

The goal of the document is to demonstrate the hierarchy of information and features and the relationships between those pieces. Wireframes are the blueprints for key business and design decisions. Adding visual clutter in the form of wavy lines, odd angles and handwriting fonts distracts from this singular purpose.

So, for the love of UX, save the sketchy look for the design phase where it belongs. Give your clients what they deserve – professional documents that aid their decisions and reinforce their selection of you for their important projects.

What Do You Think?

Am I wrong? Am I missing a key point? Do you agree with all your heart?

Leave a comment and let me know.

Comments

  1. Annette says

    Nice post, Alex!

    In my experience, providing examples of real world sites done in sketchy style can more quickly facilitate client comprehension of wireframes that aren’t “done”. Showing clients a screen cap of Facebook or another popular website alongside wireframes of the same site in different fidelity can be a great starting point and helps in setting expectations.

    While I do agree that it’s nicer to provide clients with a more finished work product, what about agile? The client may have or want an agile design process where things aren’t solidifed until the approach is validated with customers. This way they’re not paying for any design elements that won’t be used in the final version.

    It all comes down to style. Sketchy doesn’t *have* to look hand drawn or cartoony. Wireframes can still be crisp and sharp in low fidelity. Placeholder content / items can help. From a user research perspective there are also valid reasons to go “sketchy” – you’re more likely to get honest (negative) feedback from users when they know that a design isn’t complete. The higher the fidelity, the more likely folks will just nod their heads and smile. ;)

    Looking forward to other comments and discussion!

    • says

      Thanks for replying Annette. The key issue I have with “sketchy” is that people imply that it’s a lower fidelity than the same wireframes that have straight lines. It simply isn’t true – the fidelity is the same, but one has a style applied to it that distracts from the document’s purpose.

      I agree that many projects, especially agile ones (both cap-A agile and lower case) gain a tremendous amount when there are quick iterations of wireframes.

      For me, the very definition of “sketchy” is an artificial, hand-drawn look. That’s the visual style being applied to the lines and annotations created on a computer, which is very different from actually sketching a wireframe on paper or a whiteboard.

      A quick sketch is valuable, and doesn’t have to lead to an electronic version, but when it does, that electronic version should be professional. Doubly so if it’s being shown to a client.

      I am curious about the user research side, which you have a much deeper experience in than I – do we know how the unfinished, scribbled look impacts the user’s perception of the product/project? Is it possible that they provide more feedback because they feel there is more need for it? Is the difference in the “honest (negative)” feedback impacted by the lack of a professional presentation?

      It’d be really interesting to test that…

      Thanks again Annette, my mind is racing!

  2. says

    Alex – I agree.

    The sketchy-ness is a style in and of itself, versus the “absence” of refinement used as the justification for its use.

    You can’t get simpler than boxes with straight lines.

  3. Warren says

    I’m not sure I’d call it the Comic Sans of wireframes. Personally, I see the style as an attempt to emulate hand drawn blueprints. The “sketchy” style is popular for architectural drawings and landscape design. However, how the style is implemented and render does have a great effect on how it’s perceived. There is sketchy like on hand drawn blueprints and sketchy you find on a napkin. The prior still has the heft of professionalism while the latter borders on being a doodle and in that case it does mirror the use of Comic Sans.

    • says

      Interesting take Warren. I tend to view a sketch on a napkin as being a valid part of the process (Assuming discussions are in a restaurant or bar etc.). A few people have compared sketchy to landscape design and blueprints in response to this post, but I have a hard time with the comparison. For the most part, hand drawn blueprints are an early fidelity versions, rarely expected to be accurate to the level they must reach for final build. Once blueprints are in a final state, they’ve been created or redrawn on a computer, and those versions do not include psuedo-human inaccuracy in the form of squiggly lines.

      What it really comes down to for me though, is the very act of trying to emulate hand drawn, when the available tools provide a higher level of accuracy. That visual emulation belongs in the design phase.

      Thanks for commenting Warren, I now have a bit more to process as I shape my thoughts on the topic.

  4. says

    Damn Alex! You made me think!
    I think your title sums it up pretty well. But I deal with small to medium business. The ones that most often come to the table with “how” they want their website to look as opposed to “what” they want their website to do. In that world the “sketchy” wireframe definitely gives the idea that what they see is a draft of a vision. Usually the vision I present is different than the vision they came to me with. The squiggly lines and absence of color imply a work in progress. I’ll present a color comp after this.
    That is if they will pay for any of it. Whether or not they pay for it I create a wireframe for myself and then may use it as a visual aid if they need a visual for my verbal explanation.
    Now, what would be cool is if you could apply a style to a wireframe so that you could start with “sketchy” and then switch to “final” – taking the Comic Sans metaphor to it’s conclusion.
    BTW, in my 16 yo daughter’s world “sketchy” means weird or odd all the way up to pedophilic. :-]
    Thanks for making me think. Damn it.
    Todd O’Neill
    Managing Director
    DoingMedia LLC

    • says

      Glad I sparked a few neurons for you Todd and thanks for commenting!

      Your point on using sketchy to convey that the wireframes are in a draft state is the number one reason I hear for people adopting the style. I like to think that the idea is wishful thinking, but based on conversations both here and in person since I posted this piece, it’s possible I’m wrong on this one. My view may be skewed by my experience and clients over the years. I’m not quite ready to cede the point, but I’m getting close. ;)

      I love the idea of being able to change the visual theme of a wireframe from a “Draft” state, which may or may not look sketchy – both in visual terms and in your daughter’s definition ;) – to a clean representation. PowerPoint’s model for themes is a good example of this. It would be a killer feature for Balsamiq…

  5. says

    In speaking with Steve Stedman last night at Refresh Austin, he brought up a great point that I hadn’t heard before. Steve noted that the sketchy wireframes allow him to work faster as their imprecision meant he wasn’t distracted with pixel-precise layouts in the wireframes. This frees him up to get everything laid out quickly and think from a higher level perspective.

    This is quite possibly the one reason I could see for using the sketchy style – maintaining a state of flow. The equivalent in writing is to disable automatic spell check to ensure a focus on writing as opposed to correcting anything with a red underline.

    What do y’all think? Are there benefits I’ve overlooked? For that matter are there any other detrimental effects?

    • says

      I would definitely agree with this. I’ve heard it recommended that you start sketching at a small size or using a thick marker to keep yourself from focusing on the details. I think a sketchy wireframe is the digital equivalent. I also support the opt-mentioned rationale that clients sometimes better understand that the wires are not recommended design. I can’t tell you how many times I’ve had to reiterate to clients that my polished, pixel-perfect wireframes were not “rather boring designs”. What a waste of time communicating something that could have been made clear by a different line style.

      A few detrimental effects might include:
      – Looking “unprofessional” – this was a criticism levied by a former manager of mine at an ad agency, who felt that everything client-facing needed to be absolutely polished and totally thought through. The problem with that model, in my opinion, is that you’re sharing wireframes — which probably aren’t either of the above (nor should they be). Wires are an artifact of thinking in progress… so who cares if they dont look like finished masterpieces.
      – Limited stencils – this is my biggest beef. Balsamiq offers a limited set of stencils, and I haven’t found a stencil set for Visio, Omnigraffle, or Axure that was easy to add to. This is a problem when there’s an element you need to include that doesn’t exist — and its one of the problems I’ve run into most frequently. It can end up taking MORE time if you’ve gotta detour to create an element of similiar sketch style just to use in wireframes.

  6. says

    Hey Alex, I was about to lay into you based solely on your article’s title. For me, the argument for or against using Comic Sans has always been far too layered to be applied in the way I interpreted you to be doing here. But, I’m glad I read all of the comments and replies that have followed. As political stances go, and this article certainly feels like one, I’d say “sketchy” doesn’t represent an either/or set of choices. Just as there are a multitude of “handwriting” fonts that improve on the basic premise of Comic Sans, there are looser and tighter wireframing styles that either suit one’s work environment/client personality or don’t.

    I occasionally use “sketchy” for the very fact that it connotates an unfinished state–yes, I know it’s uber-simplistic and unsophisticated, but so what? It also forces me NOT to design sometimes, since sketchy is an aesthetic in and of itself–why try and fight it? All that said, I really don’t have a strong opinion one way or the other as to whether it’s a “good” thing or a “bad” thing.

    I will say that I think it’s a mistakenly Utopian attitude to say that there are only two roads, one where my clients are smart but, uniformed and one where they are dumb, potentially trouble and I should ditch them. I use all sorts of devices to move the process along and visual metaphor sure is a great one. I’ve had clients who struggle with “tight” wireframes and not because they’re bad clients or because I’m a poor educator (I AM an educator, actually). Clients aren’t interaction designers and we shouldn’t expect them to not react to the visuals in a wireframe simply because they’ve been told or emailed not to. Nor should we rely solely on squiggly lines to convey an unfinished state. The way I see it, issues that arrive from using or not using “sketchy” should be fairly easy to remedy.

    Anyway, it was an interesting read/conversation. Cheers, Art

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>