Blog Image
Fatima Kanji

Fatima Kanji

Akendi Alumnus

Prototyping for Usability Testing – How detailed should you get?

When testing prototypes, more often than not we find that there is a mismatch between the prototype fidelity and the underlying goals of testing.  Sometimes there is too much detail and sometimes there is not enough.

At Akendi, we’re always usability testing something or the other, be it a live, fully functioning App or a prototype of a product at some stage in the development life cycle.

Many times we have explained to clients that there needn’t be pixel perfect wireframes drawn to spec with fine print and all to test the usability of interactions.  On other occasions, we push clients to include more detail, get rid of the Lorem Ipsum text and put in more realistic information so as not to distract users.  So what is the right level of detail for usability testing?  As always… it depends!

An important question to answer early on is What do I want to test? Below are some tips on what level of detail in your prototype will help you achieve the goals you have outlined for testing.

User Understanding of Labels and Information Architecture

Users generally look to headings, subheadings, titles etc. to guide them as to where to go to find what they are looking for.   If this is what you want to test, then your prototype need not have very much detail.  As long as you have clickable headings and subheadings, you can see where users are naturally inclined to go.  Perhaps you can go a little further and place something within a subsection that indicates the contents of that section to the user, but it’s not absolutely necessary.  The usability testing facilitator can simply ask: “Let’s say you didn’t find what you were looking for here, show me what you would do next?”  As long as you have your headings and subheadings in place, you can easily meet your goals of testing the labelling and information architecture of your system with a very bare bones prototype.

Organization of Information

So now we’re getting into more detail.  Let’s say you want to find out if users will understand the organization of information within a particular section.  Here is where Lorem Ipsum text can be quite distracting.  For example, if you’re showing a playlist in a media player and it is filled with placeholder content that does not look realistic, how will you test if users actually understand what they’re looking at?  Upon seeing gibberish, users will usually comment that they don’t get it.  On many occasions during testing we’ve explained to users that it is simply placeholder text and to imagine it was actual information (all the while thinking to ourselves “of course you won’t understand it, it’s not English!”).  This also happens with those placeholder boxes that have giant X’s through them – users aren’t sure if they’re images, links or just taking up space.  What happens is that users get distracted from the task at hand and it reduces the value that you get out of testing that particular section.  Some users simply cannot conceptualize how the information will be organized and would benefit from seeing representative content.


Are you testing interactions?  Do you want to know if something looks clickable?  Do you want to see if interactions are intuitive for users?  For example, there might be a new tool you are developing to help users pick an outfit from their closet.  Maybe you want to test how they would naturally interact with the tool and interpret some of the interactions you have created (e.g. swipe right for a new top).  In this case, you may not need much language and definitely not fine-print, you just want to see if the user will be able to figure out the interaction.

New Concepts or Terms

When you want to test new concepts, novel interactions or terms that users may have never heard before, chances are you will need some sort of explanation.  Use discretion here – it’s usually best to test these things first without explanation.  In a perfect world, you would be able to pick a term to describe that new concept that every user would instantly understand. But you may find in some cases that no matter how many times you change the term, users still won’t get it at first glance — but it could be easily learned (e.g. before Twitter was launched, how many people would have understood the term “tweet”).  Similarly, how many people, without any kind of explanation or accidental discovery were able to determine that swiping left on your mobile email list would bring up a range of options to perform with that email?  In these cases, it is worthwhile to test how that new term or concept is explained to users.  Where will users go to find out what a term means?  Will it be a tool-tip?  Or will it be explained somewhere in plain language?  If so, will they notice?  If it is a new interaction, how will users figure it out? Whatever the case may be, it is important to include this ‘explanation’ piece in the prototype and see how well users grasp the concept after seeing it.

Understanding of Language

As described above, despite all our efforts to make interactions explanation-free, there are times when language is necessary.  Language is necessary to explain available options or processes, to give feedback when a user performs an action, or to provide warnings or alerts to ensure users understand the consequences of what they are doing (e.g. “pressing this button will charge your credit card”).  A lot of the time, language used in these or other situations is an afterthought. However, it is important to note that many usability issues arise because users do not understand the wording. Some users don’t read anything, others only look for language explanations when they get stuck, and there are also users who carefully read everything before they proceed.  Consequently, you don’t want to distract users with too much language – there is rarely a case when you need all the fine print and legal verbiage in usability testing.  But if the language is critical to the task you are testing, be sure to include it.

Of course, there are other things to consider when determining the level of detail you need to include in your prototype, this is by no means a comprehensive checklist.  The key is not to lose sight of the questions you are trying to answer through usability testing; what are you trying to achieve?  Following from that, does the fidelity of the prototype allow you to answer those questions?  Where do you need more detail and where should you reduce the level of detail so that users focus on the right things?  It’s always a balancing act.

Until next time… Happy prototyping!

Fatima Kanji

Fatima Kanji

Akendi Alumnus


Time limit is exhausted. Please reload CAPTCHA.

Learn how your comment data is used by viewing Akendi's Blog Privacy Policy

Related Articles