What You Should Know About Prototypes for User Testing | Boxes and Arrows

There are several important factors to consider when you are planning to do prototyping for user testing. You will want to make careful choices about fidelity, level of interactivity and the medium of your prototype.

Degree of fidelity

“An information architecture wireframe is NOT graphic design. I swear, it’s really not!!!”
Fidelity is the degree of closeness to the “depth, breadth and finish of the intended product” (Hakim & Spitzer). Opinions vary a great deal on how much a prototype should resemble the final version of your design. Usability practitioners like Barbara Datz-Kauffold and Shawn Lawton Henry are champions for low fidelity —the sketchier the better! Meanwhile, Jack Hakim and Tom Spitzer advocate a medium- to high-fidelity approach that gives users a closer approximation of a finished version. You’ll want to make a decision about the right approach for you based on the needs of your project.

Low fidelity
You can use hand-drawn sketches to create a paper prototype. If you go this route, you may also want to help your users get into the spirit of things during the test by creating a complete low-fidelity, paper environment. This could include a cardboard box made to look like a computer and an object to hold to point and click with. These techniques help users to suspend their disbelief and get their imaginations involved so that they can better visualize the interface. The advantage of using rough sketches is that users will have an easier time suggesting changes. They may even grab a pen and start making their own changes (Datz-Kauffold and Henry).

In theory, low-fidelity sketches are also a time-saver, but this really depends on your point of view. Personally, I like to draw diagrams and wireframes in Visio where I can revise and move things around without erasing and redrawing. If you prefer to work this way too, and if time allows, you can always have those Visio drawings hand-traced or use them as a roadmap for making sketches to test with. You might even find a graphics tool with a filter that will convert a Visio-generated graphic into a hand-drawn sketch with wavy lines.

High fidelity
This approach takes you as close as possible to a true representation of the user interface —screen-quality graphics. All of the blanks on the page are filled in, and it looks good. However, you might not have all of the technical or backend problems worked out yet, or you might have only a small part of the entire site rendered. That’s why it’s still considered a prototype. For example, it might consist of a small series of Photoshop images or HTML pages with just enough functional links to convey the feel of the site’s flow. You may need to enlist the help of a graphic designer or web developer to build these in a reasonable amount of time. Advocates for high-fidelity prototypes argue that they are easier for users to understand just by looking at them. There is no disbelief to overcome, and it is easier to determine when they really do not understand the design. If you choose a high-fidelity prototype, make sure the you have enough of the design fleshed out so that users can complete several tasks. Decide on these tasks early, so you know which areas of the design need to be represented for your tests. Otherwise, you will be in for a great deal of preparation work.

Medium fidelity
In the grand tradition of Goldilocks, I find myself drawn to the middle approach. A medium-fidelity approach tends to include some visual design and a level of detail somewhere between high and low fidelity. Does this sound familiar? As an information architect, I’m accustomed to creating wireframes I can hand off to decision-makers, graphic designers, web developers and programmers. An information architecture wireframe is NOT graphic design. I swear, it’s really not!!! But… I’ll admit that it has enough visual design to convey a rough version of the user interface. Because I create these with drawing tool software, they tend to have more polish than hand-drawn diagrams. Hakim and Spencer are champions for medium-fidelity prototypes because they fit more seamlessly into the design process while providing more realism for users. I found this to be true during a project to design a search interface for Egreetings with my colleagues at Argus. I created rough draft wireframes for the prototype, and after testing I revised them for use in my deliverables.

Interactivity describes how your prototype behaves. Does your prototype react to user inputs with feedback? Can they “click” on something to go to another page or fill in a form? Will buttons appear to depress and drop-down menus work?

Static prototypes
Prototypes used for testing are static if they are pages or page elements shown to users, which don’t provide any feedback. It can sometimes work well to show a page to a user and ask them to explain it to you or to guess where they can go from here. In this kind of test, the user interprets the prototype rather than interacts with it. This is a good way to validate your design by checking to make sure users understand it. It’s also easy to score this sort of test when you have a standard list of questions to ask about each page.

Automated prototypes allow users to make choices that cause changes. The testing prototype provides the user with feedback. Elements are “clickable” and forms can be filled out. The interface reacts to the user while the tester observes. One way to do this is to create the prototype in HTML or some application that allows interactive elements such as Flash, Visual Basic or even PowerPoint.

Another way to achieve a kind of pseudo-automated interactivity when you have chosen a paper prototype is to pretend (Datz-Kauffold and Henry). Have you ever seen children at play pretend that they are driving a car by setting up chairs for the front and back seats, drawing a dashboard on a cardboard box, and using a Frisbee for the steering wheel? If you have set up the right environment for your users, you can ask them to pretend scraps of paper on a table are their computer screen. When they “click” on a drop-down menu by touching the element with a pointer, a tester assigned to the role of the computer provides feedback by swapping the closed menu for an open one that shows choices. The “computer” may need to write on some elements before showing them to the user, i.e., “Your search retrieved 523,621 hits.” It takes a few minutes to get test participants used to the idea, but if you encourage them to have fun with it you will learn a great deal. You can also easily try out different possible reactions to user input.

This method worked well during the Egreetings project. We especially emphasized the technique of asking the users to click and then provide feedback. We found it useful to laminate the screen components so we didn’t need to produce a clean copy of the test for every subject. The users could write on the laminated pieces with thin whiteboard markers when making selections and entering search criteria. Of course, this meant that we needed to take careful notes because of the need to erase between each test subject.

Here are some other tips to try for low-fidelity testing with simulated interactivity:
  • Bring extra paper so you or the respondent can sketch out an idea if the opportunity arises.
  • As with any user test, it really helps to ask the respondent to think aloud.
  • If you have the luxury, bring a team of three to the test: someone to take notes, someone to play the “computer” and another to facilitate.
  • Use a piece of posterboard as your “screen.”
  • Cut your design into separate pieces or zones as appropriate and ask the user to rearrange them in the order they prefer.
  • Attach the folder tabs that come with hanging files to components so they are easier to grab.
  • Invite users to throw away or cross out components that they don’t think are important.
  • Number the pieces so that you can easily refer to them in your notes and keep them organized.
  • If you do decide to bring separate copies of the test materials for each session, tape down the components to a larger piece of paper as arranged by each user so you have these artifacts to analyze later.

Prepare a kit for yourself containing:
  • Scissors and tape,
  • Different sizes and varieties of sticky notes (which make great drop-down menus),
  • Markers and pens in various colors and sizes,
  • Paper clips and binder clips for keeping slips of paper organized, and
  • Objects that the user can pretend are the mouse pointer, such as a feather or a small toy.

There are many possible combinations to choose from for building your prototype. One of the first choices to make is whether you want to have your prototype viewed on an actual computer screen or if you’ll be working on a tabletop with a paper prototype. Believe it or not, fidelity and interactivity are independent of the medium you choose. It’s probably most natural to think of the extreme cases. An automated HTML prototype is often high-fidelity and, of course, the medium is a computer screen. Likewise, a natural medium for a low-fidelity automated interactive prototype is hand-drawn sketches on paper. However, you can also have the following:

  • Low to medium-fidelity wireframes built in PowerPoint that show only lines and boxes with text;
  • animation features provide automated interactivity,
  • Static Photoshop prototype pages shown to users on a computer screen, or
  • Same as above, but printed out in color on paper.

Deciding on Fidelity, Interactivity, and Medium When Prototyping

Mixing the variables
You can mix these three variables (fidelity, interactivity and medium) in many different combinations. The exact combination you choose should match the goals you determine for your testing. Possible goals for an IA prototype include:

  • Testing the effectiveness of labels and icons.
  • Finding out the right balance of depth and breadth of a topical hierarchy.
  • Determining the right options to offer for narrowing a search.
  • Choosing the most important metadata elements to show on a search results screen.
  • Settling the question of whether your target audience accomplishes tasks better with a task-oriented organization scheme or with a topical organization scheme.

If you live and breathe NetObjects Fusion and don’t have much time, your preference might be to create a medium-fidelity prototype. That way you could test that sitemap you are working on using some rough placeholder graphics or text instead of the finished graphic design. How you mix the variables depends on the time and budget you have available, as well as your work style. Try experimenting with different approaches to learn how prototyping will work best with your design process.
via boxesandarrows.com

Recommended and really interesting article by Chris Farnum for Boxes and Arrows: The design behind the design. “What you should know about prototyping for user testing” deals with valuable tips delivers distinctive definitions for the fidelity degrees.


Top 10 Wireframe Tips | UX Booth

Top 10 Wireframe Tips

Start Sketching
Sketch them first with a pencil and paper for a quick sanity check. This should take about 30 seconds and opens up the possibility of getting early feedback. This can save a lot of time and money. The feedback can be gained through peer review or, best of all, from some early and informal user testing (you may need to spend a little more than 30 seconds on the sketches if they’re for user tests).
Focus on Communication
The key point of wireframes is to communicate. Don’t forget this. Keep them simple and stop working on them as soon as they communicate their key information.
Use Proper Documentation
Since wireframes are meant to communicate something, provide some accompanying notes. Whenever possible, each wireframe should include documentation, i.e. revision date, author, page title, interaction notes, etc.
Host the Wireframes
If possible, host the wireframe files yourself, rather than sending them out as email attachments. My preferred method is to export the files as PNGs and then embed them within some simple HTML files. This way they’re easy to share and update.
Don’t Forget the Goal Of the Page
Keep the goals of the page in mind when designing a wireframe. Focus on driving action. Organize the information into a hierarchy that serves the goal of the page.
Pick Your End Point
Prior to commencement, work out who will be consuming the wireframes, how they’ll consume and what level of fidelity is required. Remember that there’s a relationship between the level of fidelity and type of feedback. Will quick paper sketches suffice or will they need to be fully interactive with accurate dimensions? Keep in mind: the less precise the wireframes are, the more liberty and creativity a designer is going to take with them. On the other hand, if you they look perfect designers may feel inhibited and merely “color in” the wireframes, preventing the design process from really getting going.
Loop the Rest of the Team in
Wireframes are not just for clients. All members of the web team should provide feedback on them, buying into the process at an early stage.
Consider the Content
If your wireframes aren’t sketches then be realistic about the amount of content that will be added to the page. This holds true also for number (and length) of links in navigation. If practical, use accurate sized fonts, images and consider what will happen when more text than is ideal is added. Nothing on the web should be etched in stone, so ask if the design will flow as required.
Use Common Elements
If designing a set of pages, use tools that allow you to make multiple changes to all common page elements at once. Moreover, as you’re creating the wireframes, look out for design patterns that repeat. Leveraging these is key to gaining efficiency and consistency.
Get Feedback
Don’t be afraid to test your wireframes in a couple of informal user tests. Grab people from around the office and ask them to find various bits of information or explain what they think the function of certain elements is.

Top 10 Wireframe Tips brings you a couple of insights on how to improve your wireframing. Top 10 Wireframe Tips is an excerpt from Neal McGann’s article: Wireframing: Tips, Tools and Techniques (Pt2). Pls visit UXBooth for the full article.


Match the Tool to the Problem | 52 Weeks of UX

How long has it been since you’ve heard designers argue about which method is better: sketches, wireframes, mock-ups, or HTML prototypes?

Probably not long enough…

One designer will claim that you shouldn’t do anything without sketching it out while another claims that doing anything less than full-on HTML prototypes is a waste of time. All of these tools have a special purpose so there’s no point in discussing which one is better. That would be a lot like an electrician saying his wire-cutters are better than the plumber’s pipe-cutters. Within the context of cutting wires it makes sense, but everywhere else it’s just silly.

There is one thing all these tools have in common: they help remove layers of ambiguity within a project. Think of them more as communication tools that help you clarify and demonstrate your intentions to other designers and to your clients. Occasionally they become deliverables, but it’s important to remember they can never provide the final answer.

This piece is about bringing clarity to this discussion. It will help you decide which tool to use without worrying what other designers are arguing about.

Match the tool to the problem

Sketches are usually hand-drawn graphics that contain screen ideas or explanatory graphics outlining the high-level problem or solution. They are the most valuable when the idea hasn’t been fully formed, explored, or realized in any way. Sketches will help you understand what general pieces are needed to accomplish your goals.

Wire-frames tend to be computer generated graphics illustrating the organization of content, features and functionality. Prioritizing the elements of a design and determining general page layout can be a very messy part of any project. A well built wire-frame will help you pull apart the individual pieces and make sure they are appropriate to the goal of the page.

Mock-ups are rich graphics intended to simulate the look and feel of a project so you can understand the impact visual elements have on the brand. A mock-up can set the right impression and communicate emotions and personality. Without actually building the website (which a lot of people do), there really isn’t any other way to concretely define what a website should look like.

HTML Prototypes are partially-complete versions of a website used to understand how pages interact with each other and flow from one area to another. More complicated interactions between sophisticated components might require a fully functional prototype to actually understand. When there are a lot of moving parts and goals have multiple steps involved, HTML prototypes can really help you find the gaps in your plans.

Let’s play with a few examples

You’re building a Basic Marketing Website and you already know the website’s goal, are confident in the assumed layout, and understand how the pages interact. Jumping directly into the mock-ups will be the best use of your time. That way you can get as close to the final result as possible in the least amount of time.

It’s the ninth time you’ve built a Well Understood Application and you deeply understand the goal and know how all the pages interact, but want to make it fit perfectly with your client’s team. This is where wireframes really make a difference. They can help you communicate how the application is organized and identify potential ways to make the interface more intuitive.

You’re starting a Brand New Idea, and the hardest parts are grasping the concept and determining how the pages will work together. For this to happen, you’ll probably need to jump back and forth between sketching and HTML prototypes until you’re confident the core purpose is captured. These initial HTML prototypes can also become great tools to illicit feedback from your team or potential customers (alpha/beta testers).

Now what?

Every project may need one or all of these tools in various order depending on the challenges you’re confronted with. So the discussion shouldn’t be about which tool is better or how to align them into a formal and rigid process. It should be about which one, at any given time, can give the most clarity and boost productivity.

Article by Daniel Ritzenthaler released on 52 Weeks of UX. Dan is a web design consultant based in Boston. He makes videos about common questions he hears from clients on Design Thoughts, and can always be reached on Twitter @danritz. Learn more about him at http://wurkit.com/.

In this article Daniel sums up why it is important to look at design tools as communication tools and how to choose the appropriate tool for the right task.


The future of wireframes? | Made by Many

I have a love hate relationship with wireframes. In the last 10 years they’ve been a part of every web project I’ve worked on. There have been times when I can’t imagine how we would have solved a particular problem without them. Yet there are also times when I’ve been completely exasperated at the amount of time and energy they’ve consumed, seemingly to very little reward.

This frustration has forced me to change the way that I approach wireframes. And as my approach has changed, I’ve been able to extract more and more value from black key lines and grey boxes…

From functional to visual

Functional wireframe

10 years ago the first wireframes I used were about as functional as you can get – a long list of page elements: static text, dynamic text, input text, radio button and so on. They were universally awful. About the only concession to help people understand how the page worked was to group common functionality into individual tables.

The wireframes were functional rather than visual as they were used to describe how the page should be built. Certainly, when you consider the screen from a developer’s perspective a list of different functional elements is probably quite logical.

However, from a user experience point of view this was a killer. Functional wireframes are incredibly difficult to read – the method of presentation gets in the way of being able to translate the information into a real screen, especially at the review stage.

Side by side comparision

Looking at this image it seems obvious that wireframes should be visual, however, IA was in it’s infancy ten years ago. Everything was new.

Wireframes also took a long time to produce. Changes to one wireframe often meant updating countless others. Change to the global nav? Certainly. Just one moment whilst I update 120 wireframes with that one.

Understandably, this hampered attempts to create wireframes that more closely represented real life screens. To help get around this, when they did become visual, they also become modular.

Modular wireframes

The modular approach to wireframes also reflects the reality of building sites. Functionality and snippets of code are built once and then reused over and over again. So why not create wireframes in the same way?

Visual wireframes also started to break down a belief that information architecture can be considered in isolation to information design. The information is the interface. How can the two possibly be separated? Join them together and you start creating wireframes that can be read and understood by everyone on the team, including the client.

Of course, this can raise the problem of clients expecting the final screens to be identical to the visual wireframes. “In the wireframes the submit button is on the right of the drop down, but in the designs it’s below. Why?” This requires careful client management, but it can be largely avoided if the wireframes concentrate on getting the ideas and thinking across, rather than just laying out a page.

Early visual wireframe

Once wireframes are created using information design as a technique rather than just a visual conceit, they can be used to explain how a site will be experienced by the end user. In the example above the different colours represent different areas of content, targeted at different types of users. The client and the team can then get inside the screen and understand how it works and what the priorities are. It’s a very different world from 1999 – a list of functional elements that only be read by the one person – the author of the original wireframe.

As wireframes have evolved, the methods behind creating them have changed too.

Isaac Pinnock speaks from his own 10 years of experience and from his personal lessons learnt when it comes to wireframing. This article is wrap up through the history of wireframes: the past, the present and the future peppered with tips and best practice models. This article is only an excerpt for the full version or commenting please head over to the Made By Many blog.


Bedrift 2.0 Documentary | Webdesign

Third Episode of the web documentary Bedrift 2.0 by citomedia recorded at this years Frontend conference in Oslo. The topic of this week is going to be the key factors of successful webdesign feat. Aral Balkan, Daniel Burka, Paul Boag …


Why It’s Important to Annotate Your Wireframes | UX Movement

Have you ever deliv­ered your wire­frames to a client only to have them quickly tell you what things they dis­like and want you to change? The prob­lem here is that biases occur when peo­ple judge some­thing before they under­stand it. One can­not objec­tively judge a design unless they thor­oughly under­stand it. It is likely your client is not well versed in the prin­ci­ples and prac­tices of user expe­ri­ence design. This is why it is your respon­si­bil­ity to com­mu­ni­cate your ratio­nale for your design deci­sions on your wireframes.

Anno­tat­ing your wire­frame ele­ments with clear and con­cise expla­na­tions is impor­tant and nec­es­sary, so that clients can under­stand your design before they judge it. If you leave them off, your clients have the power to assert their biased judge­ment on your design, which can cre­ate a breed­ing ground for sub­jec­tiv­ity. To pre­vent this from hap­pen­ing, it’s impor­tant to anno­tate your wire­frames and offer rea­sons and ben­e­fits about why your design is effec­tive. This will give them insight to your think­ing process and allow them to think about the things that you think about when you design. Below is an exam­ple and four best prac­tices on how to anno­tate your wireframes.

1. Keep them short and to the point

This is where your writ­ing skills come in handy. Giant blocks of text aren’t attrac­tive to read. Keep your expla­na­tions short and to the point. You may have a lot of anno­ta­tions, which is why keep­ing them short will make for a faster and eas­ier read. Any fur­ther elab­o­ra­tion could be fol­lowed up with a meet­ing if needed. How­ever, clients are usu­ally scarce on time, so I wouldn’t count on it. Get every­thing you want to say on your wire­frame, but keep it concise.

2. Focus on user benefits

Every design deci­sion you make should ben­e­fit the user. Thus, your anno­ta­tions should focus on explain­ing how each design ele­ment helps the client’s users. Focus on the ben­e­fits because that’s what clients care about.

3. Use numer­i­cal mark­ers and order them

Enu­mer­ate your anno­ta­tions and order them from left-to-right going down the page. This makes it eas­ier to read and will pre­vent clients from hav­ing to jump around the page to read each annotation.

4. Keep them in a col­umn on the right

Keep your anno­ta­tions on the right next to the wire­frame, so that clients won’t have to look too far to read them. It fol­lows the nat­ural left-to-right pro­gres­sion peo­ple use when they’re reading.

Anno­tat­ing your wire­frames is an extra step in the process, but it is well worth it. If you truly believe in your design you will go through great lengths to help your clients under­stand it. It’s hard for clients to look at a wire­frame and notice every grain of detail you have put into it. Anno­ta­tions allow your clients to look at your design with­out pass­ing judge­ment. As a designer, your job is to think objec­tively. Some­times in order for a project to suc­ceed you will have to help the peo­ple you work with think objec­tively as well.

Don’t use notes just for feedback use them for guidance! Anthony explains in this article why it’s important to put notes next to your wireframes.


Bedrift 2.0 Documentary | Interaction Design

Episode 2: Interaksjonsdesign

Second Episode of the web documentary Bedrift 2.0 by citomedia shot at Frontend2010 conference in Oslo. This time the topic is Interaction Design and Usability feat. Aral Balkan, Daniel Burka, Rob Goodlatte …


Flexible Fuel: Educating the Client on IA | A List Apart

Information architecture (IA) means so much to our projects, from setting requirements to establishing the baseline layout for our design and development teams. But what does it mean to your clients? Do they see the value in IA? What happens when they change their minds? Can IA help manage the change control process? More than ever, we must ensure that our clients find value in and embrace IA—and it’s is our job to educate them.

If we want our customers to embrace IA, we must help them understand why we need it. IA is about selling ideas effectively, designing with accuracy, and working with complex interactivity to guide different personas (potential customers) through website experiences.

The following talking points may help your clients understand the value of IA.

IA incorporates requirements, goals, and user paths

Explaining the purpose of IA to the client should be easy once you discover a project’s purpose. Is it to increase awareness of a product or service? Is it to make the purchase path easier? IA incorporates these requirements and marketing goals and outlines traffic patterns so that the website can become a successful extension of a product or service.

I often tell clients that IA establishes the baseline, or foundation, for a solid site structure. It helps create the traffic patterns and navigational routes that get the customer from A to B in language that is helpful and easy to understand. In fact, IA is the first step in meeting customer goals and can therefore increase brand awareness and product or service sales.

IA mitigates scope creep

Since requirement gathering usually takes place at the same time as IA, IA can serve as a guide, keeping the project on track. IA ensures that project requirements are met since it establishes functionality, customer flows, and design.

With a solid IA, the customer’s project gets delivered on time and on budget. Changing requirements means changing IA, and that means the entire downstream process will need to be adjusted.

IA validates the site’s purpose and goals

When working with your client to gather requirements, there are ways to validate whether or not you’re on the right track. Take those moments to step back and explain to the client what you’re doing and/or thinking, and validate current and future work. Once your IA is defined and agreed on, help clients understand that redesigning or adding development time after this point compromises schedule and adds cost.

If the client asks for changes to the IA, cost out the hours, resources and overall effort. Supply a cost analysis or a quote for the additional work so that they understand the consequence of changing direction.

Well-executed IA can be used to defuse any future questions in both design and development. Barring any large changes in scope, the IA will document and protect the project, so long as you educate the client along the way.

Defining IA’s deliverables for the client

All project members should have input into the architecture. That seems pretty simple, but as the project moves from phase to phase, from iteration to iteration, keeping the deliverables tight becomes more difficult. Since this can be applied to any type of website, we’ll keep things generic and worry about the deliverables.

Phase one: discovery and initial approval

Not all deliverables listed here need to be part of your project, but the team should understand the associated expectations as they work through the design process from concept to production.

Phase One DeliverablesDeliverablePhase One ExpectationsAudience NotesDeliverablePhase 1 ExpectationsAudience Notes

Content Survey

A high-level content assessment. These larger, more loosely-defined chunks help the team understand the scope of the entire project. The content survey should be delivered to the team as soon as it’s approved.

Every project member should have interest in this document, but the client project team should have the majority of the input.

Content Map

The content map is a box-and-arrow graphical representation of content by section. It should eventually transition to the site and navigation maps. As pieces are moved between sections or areas of the site or application, the content map helps manage the traffic and controls content edits. The design and development team should receive an early iteration of this to understand which sections intersect.

Client subject matter experts (SMEs) and the designers should be well aware of this direction.

Walk through this document with the user interface (UI) developers once this is set in stone.

Detailed Audit

A detailed audit lists pages of content with unique identifiers. These identifiers are then used on the site maps and user flows where space is tight. These unique identifiers are especially helpful for new content.

The client SMEs, the developers, and the quality assurance (QA) team should have copies of this once it is approved to use as a guide for the project.

Site Map

In the early stages, the site map needs to, at a basic level, reflect the combination of information and functionality to be accessed by the user. The site map is not, in my opinion, a navigation tool. Using unique identifiers from either the detailed audit or established in the site map itself, the flow of the user experience should be detailed as if the user is interacting with it. The site map, of course, is a critical deliverable in the early stages of design and should be signed off by the client before design enters the post-concept stage.

All project team members should use this as a baseline guide.

Navigation Schema

At the onset, a navigation schema will be hard to define without help from the client’s SMEs. Defining taxonomy and the navigation between interactive elements can be one of the longest tasks on a complex project. Not only are you dealing with the constraint of real estate, but you are also dealing with multiple-language factors, marketing preferences and the initial user experience. Get as much as possible set in stone at a high level before you begin design.

The entire team will benefit from this deliverable. The main audience for this is the client’s SMEs and the design and development teams.

Persona Definitions

Early persona definitions should be available from the client product or project team. These personas can be enhanced to meet the demands of the online environment. Persona enhancement depends on how many personas there are and any common elements that may be reused. The usability and design teams should be part of this task. Client SMEs and the marketing groups must provide input.

Once definitions are in place, the design and usability teams will need to use them as they do their tasks.

Use Case / Requirements Document

Typically the responsibility of the business analyst or client SME, the use case or requirements document must define tasks to be performed. Most times, a set of use cases needs to be submitted to help define user flow. For example, Use Case 1: Log in, Use Case 2: Forgot Password, etc. Without detailed requirements, it is incredibly difficult to scope, design, and develop a website. At the very least, a list of use cases should be presented to the team at the same time as the site map. This helps everyone see the correlation between form and function.

The business analysts, project managers, client’s SMEs, and IA team members need this documentation to do their jobs. The project manager or the business analyst should update this during the project.


Another “gold standard,” the wireframe must be complete before post-concept design can begin. In many cases, internationalization and multiple-language points must be addressed, as well as basic layout guidelines for the breadth (or lack) of content. Don’t allow the client to dictate the design unless you’re incorporating the work into an existing website. Always work with the usability specialist and designer before you hand off the wireframe for approval. This is one of the most critical project deliverables. It’s something that everyone on your internal team should see before you seek approval.

This set of deliverables is for all project team members. Along with the site map and requirements, wireframes will guide the team as they complete their tasks.

Phase two: design and development

As the team moves from concept to development, deliverables get updated and are worked into the project flow. Expectations for each deliverable will change and should be communicated to the team as either an edit or an official change, depending on the level of complexity. Here’s how expectations change for deliverables during design and development:

Phase Two Deliverables Deliverable Phase Two Expectations Deliverable Phase 2 Expectations

Content Survey

The content survey should not be updated. It should be placed in the project repository as a completed asset.

Content Map

The content map is a living document. During design and development, the content map helps identify scope creep. New requirements should be added and communicated as quickly as possible.

Detailed Audit

If a detailed audit was completed, the document should note delivered content and content edits. If new content is added and the project can withstand it, update the detailed audit at the same time as the site map.

Site Map

At this point, the site map should be updated with new drive-down flows and any additional supporting information on how pages or functions interact. The site map is a living document and must be updated when content or functionality is either completed or changed.

Navigation Schema

In phase one you defined the basic navigation schema, taxonomy, and user flow. In phase two, changes should come from either usability testing or from direct user feedback. Change decisions must consider layout, design, and functional elements.

Persona Definitions

Persona definitions should not change after phase one. Designers and usability specialists often refer to persona definitions to make sure that the user’s needs are met.

Use Case / Requirements Document

In phase two, use case lists and high-level user flows must be expanded and the true functionality defined. In the “Log In” use case, the expanded definition will include the ways in which users will log in, both technically and in visual design terms.


In phase two, wireframes are added to complete the design process and assist production. If a major change is introduced during phase two, produce a new template and get it approved. All new wireframe tasks must stem from the template. Changing legacy wireframe documents once they’ve hit production can be a fruitless and costly exercise.

Can you spare some change?

The change control process makes or breaks your profit on a project. In some cases, change control can be tricky for you and your client. After all, your client expects you to complete the work they give you, even if it isn’t part of the initial set of requirements. The change control process protects the project, your costs, and the client’s best interests.

The following table outlines the process and some decisions on how to effectively use a standard change control process:

Notes on Sign-Off and Change Control Deliverable Sign-off Notes Deliverable Sign-off Notes

Content Survey

Sign-off occurs when your client has given you all the content to be used on the site or application.

Initially, minor adjustments mean minor influence on the project. Once this is signed-off, any large edits will affect the entire IA process.

Content Map

Complete an initial sign-off as soon as the main requirements are set.

Changes to the content map mean changes to the requirements. Be aware of this and you’ll have the documentation you need to manage project changes.

Detailed Audit

Sign-off the detailed audit as soon as you are ready to start documenting requirements.

Most projects will not have a detailed audit. If one is created and updated, use other deliverables, such as the content map and site map to manage change.

Site Map

The site map requires sign-off any time a change is made (past the initial review). The site map can drive the entire process.

Site map change is huge. It’s critical to keep the site map up to date and call out any major changes. It will directly influence the design and development phases.

Navigation Schema

Sign-off the navigation schema as soon as the team agrees on the site map and taxonomy.

As you move into the navigation and user flows of the project, you’ll need the navigation schema to dictate the influence on other phases. Late-phase edits to this deliverable can be costly because they mean changes in the entire development cycle.

Persona Definitions

The sign-off for these should happen before you begin design. As personas are created, vet them against the navigation schema.

Different folks will take different paths. Be aware of who the audience is and what they need to manage any changes.

Use Case / Requirements Document

The sign-off for this documentation is paramount to your project. Whether you receive completed requirements from the client or are helping to create them, you must get sign-off before you begin the design process.

Any edits to the requirements should be taken into consideration for scope creep. Changes to the requirements influence the entire project.


Complete sign-off for certain pages (home, drill-down, specific functionality) before you start to design.

Before changing the wireframes, make sure the changes are either template level or page level. Page-level changes can be conveyed in the design, but template-level changes should be completed and signed off.

Flexible fuel

Websites are flexible and every deliverable must be able to grow (or shrink) with the site. Changes can come from outside forces as well, including focus group data, usability testing, and even server architecture or hosting changes.

Transparency—educating the client on standard processes and deliverables—is tantamount to the success of a project. By using these standards, IA can more easily help manage both the decision-making process and the overall cost. The team lead must take on the responsibility of training the client for the designers and developers to produce accurate work.

Proper IA, when done with an informed client, becomes the flexible fuel that drives the user experience. 

Keith Laferriere is breaking it down to this: You have to educate your client on information architecture and in this article he describes the best practices for succeeding.


Ryan Singer on Web Application Craftsmanship

via viddler.com

Very interesting talk by Ryan Singer from 37Signals at the FOWD 2007 on WebApplication Interfacedesign & Usability.


Designing with Paper Prototyping | UX Booth

Prototyping is key to any successful design. Paper prototyping is usually the first step, but does it fit into a world where mobile devices are king? Yes, but not using the conventional method. Combine the physicality of the device and the power of paper prototyping and you have a solution that’s fit for the new era of computing.

Paper prototyping is a key component of the user-centered design (UCD) process and is a popular method among designers. The characteristics of paper prototyping lends itself to the iterative approach that is so valuable in the UCD process.

The basic premise of this method is that a paper prototype of a feature’s UI is crafted and then given to a user who will attempt to complete a task or a scenario. Evaluators record and analyze the results from these sessions, which are then used to create another prototype.

Designed for a simpler time

The method is great for designing UIs for desktop computers as the user’s fingers mimic the input of a mouse. Therefore, paper prototyping mobile touchscreen UIs would surely be perfect, right? No! It would make sense, but there are many more factors that need to be considered when designing and evaluating mobile touchscreen UIs.

When interacting with desktop computers, users will usually be in a “controlled” environment, in the comfort of their own homes or offices. Mobile devices can be used in the queue at Starbucks or simply when walking in the street, and therefore lack the luxury of that “controlled” world. These devices can be used in any environment and held in several different ways, and these are two key reasons as to why the standard paper prototyping method doesn’t lend itself to mobile devices. The hardware is as important as the software when it comes to mobile devices, and those that understand its strengths and constraints will create better overall solutions. Therefore, incorporating the physical device into the early prototyping stages is vital.

How to paper prototype

In the July/August 2009 edition of Interactions magazine, three academics from the School of Informatics at Indiana University suggested a technique that incorporated paper prototyping and the physical device—in their case, an iPhone.

Their method had several stages:

  1. Create the paper prototype.
  2. Digitize each screen by photographing or scanning.
  3. After importing, resize each image to fit the device’s screen.
  4. Save the resized images in a file format supported by the mobile device.
  5. Organize all the screen images into the correct order for the scenario.
  6. Upload the images to the mobile device.
  7. Explain to the user how to navigate through the scenario. In their case, swiping through the set of images on the iPhone.

The “Paper in Screen” method was a success for the Indiana University academics as it not only raised “issues on interface labels, content organization, and affordance,” but also facilitated “discussion on the overall utility of the application for realistic mobile scenarios of usage.”

During a recent academic assignment, I decided to implement the ‘Paper in Screen’ method, but chose to add an additional step to increase interactivity as well as return different types of issues.

Using iWeb to create the links

After importing and resizing the images, I opened up Apple’s iWeb application. I set the webpage size to the iPhone’s resolution and then gave each image a separate page. Following this, I placed links on top of the buttons on my paper prototype which when clicked would send the user to another page. I then uploaded this to the Internet, and downloaded one of the many full-screen browsers for the iPhone. This allowed me to hide all the browser’s chrome and show only the prototype images. During this assignment, I was unable to find a solution that would store the HTML files locally and act correctly as a prototype. Due to this issue, this method requires an Internet connection, preferably Wi-Fi, however a decent 3G connection was more than satisfactory.

Final thoughts

A user working through the scenario using the prototype in a full-screen browser.

This method allowed the user to interact with the prototype like they would with any other iPhone app—minus the animation—and me to test the prototype in real world environments. Conventional paper prototypes restrict users, requiring them to follow the specific order of screens set out by the designer. By making the prototype more interactive, you allow the user to deviate and make mistakes without requiring intervention from the designer. No intervention means the user will feel in control and relaxed, hopefully yielding more realistic results.

Merely adding one additional step to this method can change the types of evaluations and results you receive from paper prototyping yet still retain the inherent advantages found with the technique such as no coding involved, fast and cheap to mockup interfaces, as well as encouraging creativity from other designers and more importantly, the users.

Article about paper prototyping featured on UX Booth, written by Thomas Davies.