/Tutorials/ Create the perfect prototype
07/07/2010 | Filed under Develop > Tutorials
Master prototyping and your final site build will be a cakewalk. Odette Colyer of user experience design consultancy Super User Studio explains how to go about it
It’s much cheaper to change a website early on in the development process than it is to make changes later on. Building prototypes – draft versions of your website – is a good way of nipping problems in the bud and getting things right first time around.
At Super User Studio – a user experience design consultancy that offers research, strategy, design and evaluation services to leading online brands – we consider prototyping an essential part of web design. In this tutorial, we’ll walk you through the process from start to finish.
Over the past year we’ve worked with the educational site, Teachers TV, to refine its registration process, introduce new elements to its site and produce the strategy and design for My Viewing Log – a tool that enables you to record how Teachers TV videos impact on your classroom practice.
Before you begin the prototyping process, you’ll need to work on research and strategy for the project. You’ll also need to have worked on the initial information architecture, to map out the world of the product you’re designing and vital user pathways through that world. There’s a range of UX tools and techniques to support your preparation for prototyping, but they won’t all be necessary for every project. The idea is to deploy those that will sufficiently support your understanding of business objectives and user needs, and which you deem most appropriate for your project.
At Super User Studio, before we start prototyping we usually give attention to things like: client brief; business requirements; heuristic evaluation; usability testing; user research; audience analysis or personas; competitor analysis; best of breed review; content/data requirements; features requirements; sitemap; user scenarios; task flows; and user journeys.
Techniques
Your end prototype should be a fairly refined and testable representation of the product. There are several techniques you can use to reach this point, which again will be project-dependent. For example, if you’re working on a fairly simple web application, you may decide to go straight to an interactive prototyping tool such as Axure or iPlotz. With this approach, you’ll consider the information, navigation and interaction design at the same time. However, content-driven websites usually require separate focus on information and navigation design through the use of wireframes. This enables you to work on presenting the information in a way that facilitates user understanding, before you think about how the product has to function.
Remember, your approach should be prescriptive and you may not tackle the prototype in a linear way. Ultimately, your goal is to reach a solution that combines decisions on navigation, information, interface and interaction design, while fulfilling business requirements and user needs.
The simplest way to get started is to use the humble pen and paper. First, refer back to the list of features and content requirements gathered when undertaking your research and strategy. Then sketch out the rough areas of content for each of the major templates or screens of the product. You can do this by dividing the page into rectangles, then label each area to indicate what content or data it represents. The most important purpose of these sketches is to get your team thinking about the experience you want the user to have of the product. It’s an exercise that can be shared with clients and users too, and revisions can be made speedily.
Super User Studio often workshops with stakeholders, using paper, scissors, whiteboards, flip charts, index cards and Post-It notes to produce these early prototypes. Some may move straight to interactive prototyping from here. Others will use the sketching exercise as a means of eliminating more obvious solutions, before digitising the sketches and thinking more deeply about the product’s information space.
For those projects that require independent consideration of information design, there’s the process of wireframing. Much like your early sketches, wireframes are page layouts that illustrate the information space of the product and depict how that information is presented to a user. Getting started on wireframes involves pulling together your sketches, any workshop notes, user research, strategy, content ideas and feedback into a skeletal format. Your first wireframes should be low-fidelity, as it’s important to gradually build detail into them. In other words, you shouldn’t be too concerned about working with specific data or content initially, nor making them look like the finished product. Instead, your focus will be on considering what basic features are to be presented on a page, their relative importance or hierarchy and the behaviour of that information in line with user needs.
Different user-experience professionals will use different tools to produce their wireframes. At Super User Studio, we use Adobe InDesign because we find it fast to use and you can set up a library of reusable components. You can find some components for your project here. Building an asset library ensures you use consistent design solutions across your wireframes. With InDesign, you can also create a lovely, ordered bunch of PDFs to present to clients.
This brings us to the issue of the wireframe’s audience. As well as being an important part of the design process, wireframes have generally become part of the client-facing process too. With this in mind, it’s crucial you keep documentation well organised. At Super User Studio, we refer back to previous IA diagrams to ensure titling and enumeration is carried through consistently. Sometimes, we’ll use subtle shading and contrast to differentiate key elements of a page to promote understanding of the layout. We also provide concise annotations, which we’ll look at later. It’s important to ensure that your varied mix of stakeholders is communicated with effectively.
Ideally, your low-fi wireframes will be reviewed by all key stakeholders, including your project team, clients and users. Before you show them to clients, however, be sure to inform them of the purpose of these greyscale depictions of their product. They may not be used to viewing wireframes, so it’s important to explain that they don’t represent the end layout of the product. Instead, their purpose is to encourage discussion, deeper thought and iteration. At the same time, you’ll need to be prepared to absorb feedback and not get too attached to any early assumptions you’ve made about layout. Dan Brown has a good take on this in his book Communicating Design: “Very rarely, if ever, is design work accepted on the first pass, and sometimes you can only hope to be ‘wrong in the right direction.”
High fidelity
Once you’ve compiled your feedback and made the necessary amendments to your wireframes, you may decide to move on to interactive prototyping. This again will be dependent on the product you’re designing. Developing your wireframes further will give you the benefit of applying greater thought to the layout of information and the ability to move away from familiar structures to something that’s more bespoke for the product and its users.
To move on to high-fidelity wireframes, you’ll need some specific data or content in place. In an ideal world, you’ll have all the signed-off content for the product you’re working on, but in the real world this isn’t always possible. Sample content or data where relevant may be all you need for some projects, especially when you’ve given thought to the overall content or data requirements at the beginning. Having an overview of the product’s content or data requirements and access to actual content in places should give you what you need to produce a sustainable design solution.
This is also a good point to review any competitor research you may have undertaken. This will enable you to assess how competitors tackle any similar data or content challenges and to consider how your client’s product can distinguish itself from them. Re-introduce yourself to the key users of the product too, by reviewing your user research. Reminding yourself of how and when an archetypal user might interact with the product, for example, will directly influence your interface design decisions.
There are lots of resources out there to support the development of your wireframes: try looking up uipatternfactory.com. Alternatively, see how others approach their wireframes at wireframes.tumblr.com.
Annotating wireframes
As your wireframes become richer in detail, you’ll feel the need to annotate. Annotating your wireframes will ensure your information and navigation design decisions are documented and traceable. They should also communicate these decisions to stakeholders as clearly as possible.
Everyone has their own way of annotating. We use number stamps on the wireframe that correspond to notes made in the margin or at the bottom of the page. We prefer to keep annotations on the same page as the wireframes where possible, to aid readability and quick interpretation. It goes without saying that your notes should be as unambiguous and jargon-free as possible.
Just as you put yourself into the mindset of the users when creating the wireframes, it’s the stakeholders’ shoes you need to step into when annotating them.
Designers will need to know the varying visual styles required for a component. Developers will need to know the functionality behind that component, where its information is sourced or how that information behaves. The client will be keeping their eye on how your decisions are fulfilling business requirements. We often colour-code our annotations to highlight who they’re most relevant to. Alternatively, you could try splitting up your annotations into different categories. Whatever your approach, keep it as uncomplicated as possible.
As well as enumerating and titling each wireframe, you may wish to include a brief description of the page. This is particularly important when one web page or screen has multiple states of interaction depicted across multiple wireframes. For example, you could describe a user’s stage in a task flow like a registration process, what key tasks they can perform on that page or even which business requirements are being met at that point.
There’s no need to make annotations on every design decision, though. You’ll only end up diminishing the efficacy of the wireframes if you over-annotate them. Stick to notes on the unobvious or the conditional, such as:
- Navigation & links – where do they link to?
- Functional explanations – how a form behaves with and without Ajax functionality or process rules
- Information sources – unobvious aggregated content
- Changes in the user interface – how the interface alters dependent on information already submitted by the user or particular user type
- Conflicts against requirements – when you’ve made a decision that conflicts with a business, technical or user requirement
- Content or data explanations – what information needs to be contained within a dropdown and reference to where that information can be accessed
- Reference to previous documentation – a note about how other IA or user experience documents (such as personas, user scenarios or task flows) have affected your decision-making
If you do refer to previously delivered documentation, make sure you once again present those documents with the wireframes. We usually redeliver any user profiles or personas we’ve created anyway. This brings you and all stakeholders to common ground when discussing the wireframes. Inevitably there will be differences of opinion, but by keeping primary users and their needs in mind, everyone can ensure that user expectations are equally balanced with business objectives.
Most importantly, think about how these annotations can support your design process. Crucially, by making notes about the reasons for certain decisions, you’ll be able to consider whether any later requests for changes are really feasible. Including some form of version history within your annotations will also help you keep track of the changes you’ve made so far. There’s not always sufficient space to do this fully, so we tend to include just the last set of changes within the wireframes and keep a fuller record within a separate document. Wireframing tools to consider include Visio, Omnigraffle, Adobe Illustrator and Adobe InDesign.
Interactive prototyping
Interactive prototypes are working simulations of a product. They take your task flows, sketches and wireframes into a 2D realm and enable you to consider the interaction behind components. Interactive prototyping is a process in itself. It enables you to test and revise the user interface, refining the user’s interaction with functionality and perfecting their experience as you iterate. For the first time, stakeholders start to see their product take shape.
As Garry Samett, head of digital content, Teachers TV, testifies: “When Super User Studio designed our registration process, having a ‘working’ prototype gave reassurance, especially to non-tech savvy stakeholders. They could see how it all worked early enough in the process to raise issues before coding had started. This saved us loads of time and pain.”
Not all projects will require interactive prototyping. If there’s limited interactivity, you may wish to produce interactive PDFs from your wireframes, but developing a full prototype is unlikely to be necessary. Interactive prototypes are useful for projects that involve either single or multiple areas of complex interactivity. They’re also useful when those areas of interactivity are particularly crucial to fulfilling business or user requirements.
For example, it’s difficult to truly think about the interactivity of a web application or social media site using static wireframes. One component of a page or screen could have multiple stages of interaction behind it, as could many other components on the same page or screen.
You could wireframe out each of these processes, but it won’t really give you sufficient clarity to consider how the interactions could be improved. For such projects, interactive prototypes will support your testing of the behaviour of the components and explore how the user’s experience can be enhanced.
Again, there are many tools you can use for interactive prototyping. Your choice of tool may depend on the complexity of the interaction involved and just how much interaction design you think the project warrants. At Super User Studio, we use Axure, as it can handle quite complex interactions such as mimicking Ajax functionality. It’s not as simple to use as Balsamiq, for example, nor does it have the nice interface of iPlotz, but it does enable you to produce a functional specification to accompany the interactive prototypes. While the users testing the product will not be concerned with functional specifications, your development team will be. The spec offered by Axure needs editing and formatting, but effectively brings together all the annotations you make while creating the interactive prototype. In our experience, annotations on interactive prototypes can be overlooked, so delivering a specification document often goes down well with developers and clients alike.
Your approach to interactive prototyping may be low-fidelity or high-fidelity. This will inevitably be dependent upon the project, its budget, timeline, complexity and so on. However, if you intend to test the prototypes with users, it’s important to allocate time to make them as user-friendly in their presentation as you can. Paying close attention to things such as grid structure, spacing, linking convention and typographical hierarchy will boost the user’s apprehension of the interactive prototype. More importantly, your users will spend less time querying elements of the interface that you’re simply not testing.
To support your development of interactive prototypes in Axure, check out the pattern libraries offered at www.axlib.org and acleandesign.com.
If there is one core insight we’d like to reflect upon in this tutorial, it’s how this entire process is about communication. By focusing on issues of interface and interaction design before visual design, you’re allowing yourself to focus on how the product can more effectively communicate its message to users. You’re focusing on opening up channels of communication with your client and the project team. You’re also inviting communication with users to better understand how the product can meet their requirements to craft the best possible user experience.
About the author
Name Odette Colyer
Company Super User Studio
Site www.superuserstudio.com
Projects Teachers TV, The Guardian, BBC
What do you wish you were better at? Press-ups: no amount of chicken gives me enough strength to do them
Bookmark with:
Comments
Panayiotis Karabetis / 07/07/2010 / 12:55 / http://viminteractive.com
Great article and even better magazine. My company just purchased a subscription here in the U.S. and we all love it. I'm creating an interactive prototype today for a client that has a monster website with tons of pages and interactivity. Even though it's a beast, it's fun to design and create the behaviors in Axure. It makes the clients happy and the designers / developers breathe easy when they get a copy along with the specs sheet.
Thanks for the article!
Wolf Becvar / 07/07/2010 / 22:49 / http://www.hotgloo.com
Congratulations Odette! Haven't read such a profound and comprehensive article about wireframing and prototyping since The Future of Wireframes article on MIX Online.
Would be really great if you could find the time to check out our wireframe app HotGloo. We are constantly improving and would really appreciate your feedback to make it even better.
Regards and keep up the good work,
Wolf
Max K-Thompson / 09/07/2010 / 14:16 / http://www.plugandplaydesign.co.uk/southampton
It's great to read an article which explains prototyping which is such an important aspect of managing any web project. Planning is crucial to the success of any project which requires the attention of detail and level of communication needed when a number of specialist individuals working as part of a development team are dealing with end user requirements, technical briefs and project management tools. I hope that more companies will benefit from using these methods as much as we have.
Garry Samett / 18/07/2010 / 21:04
As head of digital content at Teachers TV I worked closely with Odette and Stu at Super User Studio, they do great work. The icing on the cake was the level of communication with the us, beyond the prototype, making sure we were happy with and understood each stage of development. Keep up the good work!
Odette Colyer / 30/07/2010 / 12:14 / http://www.superuserstudio.com
Thanks for all your comments on the article. Glad you liked it!
hcabbos / 24/08/2010 / 04:32
When I was doing research for a recent project, I evaluated a few of the tools mentioned here but finally landed on HotGloo. Thanks again for a great article. I'll have to frequent this site more often.
David / 24/08/2010 / 12:02 / http://www.helloeverything.co.uk
Nice article, i think making changes to the prototype early on, will speed up a sites overall development.
