In this series of blog posts I’m going to take you to the wonderful world of prototyping. First, I’m covering some basic terminology and background in order to get you to the necessary level of understanding any UX-jargon I’m going to use. Hopefully after the first post you will also have a vision why to bother with prototyping in the first place =). In the second entry, I’m covering SketchFlow, a convenient tool for creating and using desktop UI prototypes in your team. In the third post, I’m going to present you some ways to prototype software for mobile devices, mainly SketchFlow for Windows Phone.
What is prototyping?
According to the Interaction design encyclopedia, “Prototyping is a method used by designers to acquire feedback from users about future designs”. This feedback can be gathered from a number of users: from your own colleagues, from the client, or later-on in the project, from the end-users. According to this feedback, the prototype design can then be changed. The earlier the needed changes are found and implemented, the less expensive the implementation of the whole project is.
Prototypes can clarify the software design’s navigational structure, overall “look-and-feel” or some specific user interaction. With the design visions clearly communicated and usability studies executed, prototypes keep teams headed in the right direction.
What is prototyping for?
“The two most important tools an architect has are the eraser in the drawing room and the sledge hammer on the construction site.” —Frank Lloyd Wright
Prototyping can be used as a tool for:
o When you’ll have to clarify your vision to make a prototype, you’ll get to the more concrete level than just ideas.
o Inside your team: getting to a common vision. Sometimes designers use prototypes to clearly express to developers and other designers their ideas. For example, if you don’t have a concrete example of a menu, then you and everyone else will make assumptions. As the project goes on, these assumptions accumulate into completely different visions of the final system design.
o To higher-ups: sometimes you simply have to sell your ideas to the ones sitting on top of the budget. A tangible prototype will then count a lot more than a 10-pager full of small text.
o Prototypes are a great target for usability testing. Testing as such is a topic of its own and will not be covered in this series very extensively (== I’ll skip it more or less every time).
How to prototype?
Different kind of prototypes are needed in different phases of a project.
Sometimes called “mockups”, the low-fidelity prototypes are useful for acquiring user feedback on design early in the development progress. The purpose of lo-fi prototypes is to clarify requirements along with the users or someone representing the user. They are also used for experimenting around different design ideas.
Lo-fi prototypes are simple sketches, and only represent the design ideas, not the final design. They are often drawn by hand on paper, cardboard or even wood. In mobile world, a lo-fi UI prototype can be a post-it note stacked on top of a mobile device screen.
The low fidelity prototypes are fast and low-cost to develop. Because the low fidelity prototypes look sketchy and hand-drawn, the users are more eager to give design-changing feedback and not focus on some graphical details. Also for you as the designer, it will be easier to leave behind early-state prototypes than those with a lot of time invested in.
With low-fidelity prototypes, you can
· Test how your concepts or ideas would work
· Try out alternative design solutions
· Set the basic high-level design structures, e.g. navigational hierarchy
· Identify and verify requirements
· Show off to the client, that you are indeed making progress
High-fidelity prototypes look like the final product. Even the user interaction may be partially implemented (or made to look like it was implemented). The purpose of the hi-fi prototypes is usually to experiment whether the final system or design would work when finished.
The downside is, of course, that hi-fi prototypes are more resource intensive than lo-fi prototypes: they cost time of the designer and in some cases, the developer. They are thus slower, more complicated and more expensive to make. When hi-fi prototypes are tested for user feedback, the results are usually related to specifics of the visual design, rather than actual user experience problems. This happens because the users will easily regard a design as finished when they see design that seems to them as fine-tuned (fancy animations, too realistic graphics, etc.). Also, if the prototype is too fancy, the user expectations might rise to a level unlikely to be achieved in your final product. Summa summarum, you should not put too much effort in refining graphics or other particular features of a prototype.
Hi-fi prototypes are a tool for polishing designs, implementations or interactions, rather than innovating new ones (like lo-fi prototypes). They are usualy created to try out what could go wrong in the next implementation step, so that the UX errors coud be corrected sooner rather than later. They can also be used to promote the design idea for the client or management.
If you want to learn more about how prototyping could fit to your project or situation, see Scott Berkun’s nice article on the topic. If you want to check the dangers of testing with different level of prototypes head over to UsabilityNet site.
About the author: Karl Ots (@fincooper)
Karl is enthusiastic about great user experiences and smart mobile devices. He is working on software research and development. Karl currently studies computer sciences and human-computer interaction at the University of Tampere.