28 replies
9h37m
Something always bothered me: why using "sketch-like hand-drawn pencil" like style for that kind of tools ?
I understand that "wireframing" is some kind of "brainstorming" tool, so it is used with a pencil and a whiteboard in a meeting room and require to draw/erase fast iteratively... so it's the "right" tool for this job...
But as soon as you use a computer instead of a pencil, why not have a "realistic" and "clean" look instead of this kind of quick-and-dirty sketch-like style? It's an honest question
Is it because designers are most used to this style? Is it because it make more clearly appear the essential points (for example: a list) and avoid discussion like "is this text exactly in this color ?"
The reason that I've heard used repeatedly is that a shocking percentage of folks who aren't Technology producers can't separate visual quality from "doneness" of a project. If you show some business folks something that looks like it works, they'll mentally update the project to "Nearly done!" and then everything else after that becomes "Unreasonable delays."
While this is likely true for designs, I believe there's more to it. I switched from straight to cartoon lines for my architecture / planning diagrams and suddenly started getting more unprompted comments about how they're clear and approachable.
Personally I also prefer the hand-drawn style, but can't put my finger on why. There's something about the uneven lines filling out the space better, while still defining the shapes well.
I think you're pointing to the positive case of the same effect, which is that people use "hints" from the level of detail of something to determine the level at which they ought to inspect something.
Lower fidelity puts the viewer in a more conceptual mode of assessment, and there they can more easily perceive the clearness/approachability of your concepts.
I have had prospective clients do it from non-interactive graphic mock-ups -- just pictures! They assumed that was the hard part and just "wiring up the buttons" would be a short simple task. Those were frustrating discussions.
Devil’s advocate … why shouldn’t this be true? That’s how HyperCard worked, right?
A slightly different take.
If everything is either an obvious sketch, or pixel perfect you can get decent feedback, but a design that is just a little off in jarring ways will distract people from the functionality or design intention.
And criticize the colors, shading, exact sizes of UI elements, etc. instead of the underlying holistic UX
I remember in the early 00's this book suggested literally prototyping on paper first. https://www.amazon.co.uk/Paper-Prototyping-Interfaces-Intera...
I think this was then expanded to be "paper-looking".
But yes, for the reasons you state.
This is also what I've heard and experienced.
Actually I don't think "technology producers" are entirely excluded from this bias either. I've assumed more complexity than there was in reality (possibly due to my background in infrastructure and backend), but other developers I've worked with certainly fall more into the trap of "there's a UI? now it's just a simple matter of CRUD."
This is unfortunately very true. You also have to be very careful with word/phrase choice in discussion about future work: people often hear “what we could do, is…” as “there is already a full feature that allows you to configure the tool to do…”.
You really have to drill home that ideas and possibilities are just that, and not concrete features that they could start using tomorrow.
I presented a wireframe to a curator at The Science Museum once years ago - even after lots of "please bear in mind this is just a prototype" type disclaimers, his first response was "surely it'll have more colour and pictures than this?".
So. Yeh.
Yes. This is precisely it. There aren’t two sides to this, just people that haven’t themselves experienced this absolutely inevitability. These sorts of inexact-looking tools are worth their weight in gold for that reason alone.
I think Kathy Sierra used to wrote about this quite a bit. She's actually referenced by Balsamiq I think.
There is definitely this, but also: if it looks "refined", people start getting attached to what they see, and it affects how they react to the final product.
Any change from that haphazard throwaway with nice colors is suddenly a change they have opinions about, because it feels like a change.
If you show them something that's obviously not what will ship, they don't get as attached.
---
This is also partly a "most people don't understand the design process" thing, and just how much reworking and restarting is generally necessary to get an actually-good end result. If they see hundreds of mockups (or even sketches), they'll wonder why you haven't made hundreds of products, rather than those being merely tools used to think along the way.
(to be honest, I find this "pencil-like" look a bit like MS Comics for fonts, ugly and unprofessional... so I really don't understand why designer tool use it so much)
Anybody who's ever been in a few meetings that try to put together stakeholders, designers, and developers, know how it will inevitably descend in painful back and forth about a shade of hue or an icon size. People get distracted by colors and graphics, and fail to provide actual feedback on functionality and layouting - which are the hardest bits to change later.
The point of this style is to communicate that it's a rough draft, so that people focus on the essential implementation and functionality requirements, the hard stuff. It's easy to give it a lick of paint later. (It also keeps expectations low, so that the final result will feel like you're overdelivering. But that's just bonus.)
For those "downvoting" this comment, please: I wrote it right after my initial post, before any answer, to make my initial post clearer. I certainly should have added this to the main post.
Now that I have all these answers, I understand better. But cant delete or modify this comment. So sadly it's here for eternity :-(
Thanks a lot for your insightfull comments to the original post. Actually, I now think that I will use these method to help getting more feedback from users
This style says ‘it's a draft’ ‘it's an idea’. This is very important for communication within the team. It also allows you to concentrate on the essential points and not on the details (I don't like this font, the centring isn't perfect, etc.).
To my great surprise, even for training courses, this style encourages questions and interaction with the students. There's a whiteboard feel to it which suggests that the presentation isn't set in stone.
Right. The more polished a rendering is, the more people are emotionally attached to it. Keeping it rough enables brainstorming, whatifs, etc.
Ages ago, when CAD was new, architects would show customers tracings (of plots). For all the same reasons.
The practice was so common that my buddy (also an architect) created a "hand plot" driver for AutoCAD. "Messy" hand drawn look instead of precise line work. The driver was huge popular.
I usually dont use wireframes like this but one benefit is that it clearly communicates "this is NOT a finished design". Way to many times you bring a figma/mvp to get feedback on the "big picture" like the user flow etc but people get stuck on "the margin on that box is wrong" or "can we use another font?" when they see a design that looks like a "finished" product. You dont have that issue with wireframes.
Sometimes the pixel perfect details don't matter for a use case, so why set the hi-fi expectation for both the designer and developer. The designer can get caught up in choosing colors and pixel-perfect layout, and similarly the developer implementing on that design might unnecessary time attempting to match the hi-fi design.
https://napkinlaf.sourceforge.net (one of my favorites from back in the day)
... and that's the place that I remember where to find this blog post:
Don't make the Demo look Done - https://headrush.typepad.com/creating_passionate_users/2006/...
The infographic in this post ( https://headrush.typepad.com/photos/uncategorized/feedbackim... ) is especially important because the how it looks changes what type of feedback you get.
I had a project where I grabbed the stylesheet and header from another similar project while working on it... and spent a week discussing with management about what color blue it should be when the questions I needed answering were "does this page flow make sense?"
A) Make it easier to focus on the core aspects of the problems instead of obsessing with details (applies to both designers and "reviewers")
B) An "unfinished" messy design is an invitation for critical feedback. If you give people something that looks too polished, they might be afraid that they'll break it, that they don't understand it, that they can't give feedback that is "good enough".
In short: if it looks like a toy people will play with it.
* C) The reason many of these tools look like Balsamiq has more to do with the tech of the late 00s/early 10s. This specific style of vector art was pretty easy to achieve in Flash.
If I draw something in balsamiq, I’m typically “forgiven” for how basic the design looks. Try and do the same in let’s say MS paint and you could be called unprofessional and lazy. But this style seems to communicate strongly that this is a basic barebones wireframe.
Honestly it also looks better.
Psychologically reduces obsession with the perfect drawing.
Exactly. I feel the same way. After lot of research, I settled on Whimsical for doing mockups/wireframes. Good Balance between Simplicity and Power. Only complain is clickable prototyping which is not available. If they add that, I would never leave Whimsical for prototyping.
It’s an abstraction that makes people focus on the part that is relevant for the discussion at hand, and not on implementation details.
Because the final product will require tons of details to have been thought through, which can quickly become bike-shedding derailments. How many times have you had to say “this is just example styling—we can tweak it later”? The hand drawn sketch conveys that implicitly.