Wireframes as Thinking Device
Will Evans has written a piece entitled Shades of Gray: Wireframes as Thinking Device, on the role of wireframes in the UX design process (for an upcoming book on UX design by Russ Unger).
The whole post is interesting, but I like this bit in particular:
I think it is quite common for UX folks to view design as problem solving. For me, designing through the use of wireframes is a search in a problem space of alternatives; it’s a process of problem setting as much as it is a process of problem solving, which means that I always start with the context.
I like this; “problem setting” rather than “problem solving”.
The whole piece can be found on Will’s blog, along with wireframe examples he has created for the book.
(This may just prompt me to finish a long-running draft on “the truth about wireframes” which I have been working on for some time. I guess wireframes—or more accurately how they are abused—are a pet hate of mine :)
A “design problems now all solved” mentality would suggest that you think everything done after what you do is not design but manufacturing or implementation wouldn’t it?
I will admit that some IA/EA/UX people may not have an appreciation of the design aspects of technical development (the ‘beauty of the code’, if you will). And in that respect, yes, thinking all design problems have been solved before the site is built/functional/live is a tad premature.
However, those of us that believe the IA/EA/UX role remains in play until the very end—albeit in a diminishing capacity—could get away with such a statement as you highlighted above :)
I was thinking purely in terms of how you talk about wireframes for problem setting and how that suggests that the first wireframe isn’t the full design story. In other words, you’re not designing wireframes. That seemed to go nicely with my thinking that software design is not finished before the code is.
Oh right! well yes I agree. It’s only through exploration and iteration that we can set and then solve the problem. Which is why I think wireframes need to be sketchy and fluid until as late as possible.
I’d agree with both of you.
Exploring the problem space and looking at the problems you are trying to solve through the context of a person using a design is one of the key things about designing well.
I’d say that there is never one solution to any problem, but there are solutions that are more optimal (understanding what you are optimising for is a whole other story).
I think the “sketching user experience” book talks a bit about this need to explore spaces in a relatively rough way, before pursuing a particular direction.
If we flip back to the UCD process, testing early and often with real people enables us to continue exploring the problem space even while we are refining the design and reducing the set of possible solutions, that’s really what makes iterative design and testing so powerful.
Just a quick edit to note that David Malouf has written an interesting article on sketching mentioning Bill Buxtons book, discussing the above topic about exploring design spaces in a bit more depth you can find it at: JohnnyHolland
The “Sketching User Experience” book introduced me to the terms “Problem Setting” & “Problem Solving” that Will uses. I like Buxton’s suggestion that the first is to “get the right design” the second is to “get the design right”. There is a great diagram on p388 where a “spiral closing in along a single trajectory” illustrates engineering prototyping/usability engineering which I think he characterises as problem solving whereas design/problem setting is illustrated by set of branching lines showing “branching exploration and comparison”.
Will’s post describes a solo wireframing process where “the scope of my designs narrows as the wireframes speak back to me” & the finished wireframes need to “plead” their case with the help of annotations. While I enjoy the process and think many discoveries are made doing polished wireframes like these they are all about problem solving. Problem setting and collaborative design seems to need something “low fidelity” like sketches where many more variations can be generated, explored, discussed and discarded by collaborators & users. One question I still have: do users need a highly polished representation (wireframe or mockup) to evaluate designs?
I don’t think we need to have a polished interface in order to get value out of involving people/users in the design process.
The quality of the representation directly affects how much input and impact people feel they can have on the product. From my personal experience if you give someone something on paper that looks like you drew it the night before, they are more prone to discuss general topics like, overall feature sets, and preferred functionality, fitness for purpose etc.
As the designs become more refined you will start to get more insight into specific interactions (widget functionality) and usability issues. That’s why I’m all for multiple small sets of iterative participant input throughout the design process, and with different levels of fidelity in concepts.
Back in the day (sigh) I used to provide at least 4 different hand drawn concepts in my initial rounds of collaborative design and give the participants scissors so they could munge, fold and mutilate at will, that sort of design process always gave me a lot of insight into what works well and what doesn’t, and helped me refine the design space to something more manageable.
I’m going to publish this comment now to gazump Mr Kennedy who is busily penning his missive :-) .
My gut reaction is no, they don’t. I’ve used sketches to elicit feedback from users. The obvious objection to doing this is that the users may not understand what you’ve sketched because it doesn’t resemble what they are used to using (in the case of websites). But if you’re using sketches early in the design process, the resemblance to a finished website is not as crucial as roughly communicating the functionality you’re intending to offer them.
That said, I look forward to hearing other people’s thoughts on this question.
Buxton sort of answers this question p383-387 by citing a paper “Does the Fidelity of Software Prototypes Affect the Perception of Usability?”(Wiklund, Thurrott & Dumas 1992 - I can’t find a version online to link to). Unfortunately they didn’t include a hand sketched prototype in the study but the results do suggest fidelity of a prototype does not affect quality of usability evaluation/users rating.
I think provided the sketches are legible they should work fine. The likely absence of detail should mean you get feedback about the things that matter at that level of fidelity. Another “doh!” realisation for me: if you want users to creatively suggest pros & cons of a design you need to show multiple versions of a design so they feel free to explain what works & what doesn’t. This is easier to do with quickly created sketches.
In recent moble research I asked users to sketch interfaces for mobile applications they said they would be interested in using. Results varied by participants, some struggled, but the majority came up with something interesting and their explanations & justifications may prove valuable.
Does using low fidelity prototypes on users influence your experimental design?
I’m wondering about whether you might inadvertently start measuring something that you don’t want to… particularly if you have varying degrees of fidelity across different tests.
Patrick, when you start using words like “measuring” I get antsy :)
What we’re really talking about here is design research rather than usability testing (the latter term suggesting something more akin to a science experiment where precision and measurability are key—it’s a distinction that has seen quite a lot of debate lately, including my own blog post).
When we’re talking about using sketches to get feedback/input from users, it is likely to be early in the design process, when we’re setting the problem or perhaps starting to nut out possible solutions. So it’s not about measuring anything, it’s about understanding.
But to answer your question, the fidelity would influence the way in which we go about designing our “experiment”. But that Wikipedia definition of experimental design bears little resemblance to what we typically do for UX design. The only experimentation I would do is show a number of design alternatives and listen to what users had to say, or as Angus was saying, get them to come up with the alternatives.
I think I’m munging some terms here :)
It was a process question…
The fidelity could make people focus on different things, particularly those components that are most complete. This could mean you’re getting feedback (not necessarily measurement) on things when you might want feedback on others.
So the question was about how you set the stage to get the most benefit from the people in the design research sessions… which I think you’ve answered.
One other thing to note is that in most cases, particularity with paper / sketches or non functioning prototypes is that you are usually conducting a guided session. This means you can explore areas where there is little information using the right sort of probes.
Participative design sessions, obviously, require participative and inclusive capture mechanisms. Clearly, Visio won’t cut the mustard. So sketching provides a handy, quick and low fidelity solution.
However, sketching (i.e. drawing) isn’t, a priori, a better mechanism for design capture than wireframes during the conceptual phase. Really, it’s about the designer being able to adopt a tool that suits them and they way they work best. For some this means the tool allowing them to generate as many designs, as easily and as malleably as possible.
For me, personally (and I must stress this,) I find it much easier to use Visio to produce a physical manifestation of my thoughts than drawing on paper. In the early conceptual stages I don’t feel the need to invest large amounts of time on precision. For others, sketching by hand might be the quicker process (I just find making modifications, communicating them electronically (i.e. emailing) and keeping tab of versions laborious).
But, what about the issue that higher fidelity wireframes communicate to the user a more finished result, and consequently limit their freedom of thought around a design?
Well, if required I’ve found the use of sketching stencils for Visio really great in the past. In this way you have the both worlds, the convenience of CAD with the low-fi affordance of sketch. It’s worth checking out ‘Visio - the interaction designer’s nail gun (3rd edition)’ and ‘Updated Sketch GUI Shapes for Visio’.
Oh Chris, just admit you can’t draw :)
’tis true!
[...] comments Patrick Kennedy on Documenting Interactive WebsitesChris Khalil on Wireframes as Thinking DevicePatrick Kennedy on Wireframes as Thinking DeviceChris Khalil on Wireframes as Thinking DeviceStephen [...]
[...] The UX book club was pretty interesting last night. This idea popped into my head when Penny Hagen started discussing the fact that “great designers” have an inherent awareness and observational skills so they were really always doing user research. This discussing got me thinking, if there were different levels of fidelity in customer research much as there are in sketching and design deliverables. [...]
The IA Institute mailing list has been throwing this same topic back and forth after someone posted a link to Balsamiq Mockups. The reaction from members has been typically divided, and some of the points raised include:
The moral of the story still seems to be “horses for courses” (or “whatever floats your boat”).
[...] tool and communication tool (at least that’s the ideal I like to subscribe too and one which Pat’s already blogged about) and in the case of product groups that we work closely with over extended periods of time, they [...]