Guy Sangwine [HREF1], User Interface Designer, Information Technology Services [HREF2] , Building 3A, Monash University [HREF3], Victoria, 3800. guy.sangwine@its.monash.edu.au
Paper prototyping is a method for the design, evaluation and improvement of user interfaces. This paper describes my first experiences of using paper prototyping in order to test elements of an user interface for an Online Public Access Catalogue (OPAC). A number of lessons that I learned during this process are recounted, focusing on my experiences of the process and the use of Microsoft Visio to create medium-fidelity interface prototypes.
This paper describes my first experiences of using paper prototyping in order to test a user interface interface. It also covers my use of Microsoft Visio to create a series of paper prototypes for use during usability testing of the endeavor Voyager product. Also, a number of lessons that I learned during this process are given.
I work as a user interface designer within the Web Resources and Development (WRD) team at Monash University. Our team was asked to freshen up the design and test the usability of the Voyager catalogue application
Four rounds of testing were carried out – including two rounds of paper prototyping.
Voyager is an Online Public Access Catalogue (OPAC) system created by the Endeavor Information Systems [HREF4]. It is used to provide, amongst over services, electronic access to a library catalogue at Monash University.
The main issue that arose from redesigning such a vendor product were that we were constrained in what we could change within the user interface. For example although the labelling of many interface items could be changed, their location could not.
A good explanation of paper prototyping is given by Snyder 2003, she states that "Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person ‘playing computer,’ who doesn't’t explain how the interface is intended to work." In our situation we used a facilitator to run the usability testing session and another person to act as the “computer”.
The test participant was given a pen to use as their “mouse” and keyboard – they then were instructed to use this to click on links and buttons or to “type” and enter text into boxes.
We wanted to try out new labels for some user interface elements and make other changes to the system without wasting developer’s time. We also wanted to make sure we could create new interfaces in time to run through several iterations. Paper prototyping has been shown to be the fastest method of testing in this manner (Snyder 2003). This also meant we could directly control the speed of the design iterations as experience has shown us that developers have other demands on their time - for example other projects and application upgrades.
After reviewing the clients concerns with the interface labelling, 7 tasks were created in order to test these concerns. After "walking through " each of the seven tasks, I determined that there were around 50 screens that would be used. This figure increased to around 80 screens after considering related screens that might be accessed during the tasks and would be of interest to study – for example the search history screen.
This is when my experiences with this methodology began in earnest. Initially, I began to create low-fidelity prototypes using pen, paper and ruler. The large number of screens required proved quite daunting - as well as considering potentially drawing up another set of screens after each iteration. I had read a number of articles on using software tools to create medium fidelity prototypes and, possibly due to my inexperience in this technique, I turned to using Microsoft Visio to create pages.
The reasons I chose to use Visio were:
We decided to have a certain level of basic “browser chrome” i.e. a representation of the browser within the prototype; as pointed out by Snyder 2003 this would help reinforce the user’s perception that they are using a web based application on a computer. In addition we modeled a browser “scroll bar” – certain pages were larger than the browser screen and the test participant would use the “mouse” to drag the view to the next screen.
After walking through the tasks it became apparent that the application had semi - consistent navigational elements in the form of buttons and text links; there were six variations of navigation options. I created these basic page variants for all navigation and scroll bar variations and gave them the property “background”. This meant for any page I then created I could then instantly apply a page background with browser chrome and navigational elements in place.
After realising that many of the interface objects would be re-used within the application, I built up a library of common interface objects – using familiar items such as text entry boxes etc. Many of these I was able to source from wire frame creation stencils.
I was also able to create stencil images of common application items – for example I drew up a selection of tables that were used show tabular data in voyager.
The process for creating a screen prototype was then straightforward:
• Select the page background
• Add interface elements
• Add any result data
Interactive interface elements were modeled using sticky tape with bits of paper showing the required interface element. These elements were organised (i.e. stuck stuck onto a sheet of A3 paper) – by page. For example, if the user “clicked” (using the pen) on a drop down box we removed the required drop down from the organiser sheet and stuck it onto the prototype. Users also filled in text boxes using pre-applied sticky tape.
The participants could also use the pen / mouse to use the scroll bars and to select buttons. It was interesting to me that participants, after being shown how the prototypes were used, immediately used the interactive elements as they would do on a computer system.
I soon discovered, with nearly one hundred A3 sheets of paper, that organisation would be crucial for a session's success. For most tasks we had a good idea of what paths a participant would take – so I organised the various screens according to task within a labeled manila folder clipped together. I then organised a series of other system pages under different headings – for example error, search and help pages. This organisation was extremely important for delivering the correct screen to the participant in a reasonable amount of time. Given that users would also be presented with differing elements (for example drop downs) dependant on previous actions, I was also able to organise elements into a matrix that I labeled with all the criteria that would result in the element being shown.
These steps helped in reducing the time taken to present the correct page to the participant. This time taken in presenting the required screen was an issue - the screens had to be presented quickly enough in order that the user could recall the steps in the task.
Lastly, an important lesson I learned is to have as many sets of test screens as there are sessions during a day - you do not want to add to your stress by having to rearrange screens and elements in between sessions.
Overall I was happy with using a computer aided technique in creating the prototypes - once I had created a bank or stencil of reusable screen elements I could create a page from scratch relatively quickly. As the pages were medium fidelity, I believe that participants were more aware of errors in page composition than they would have been with a low-fidelity approach. This means that a quality assurance process or getting someone familiar with the interface screens to look over your output is more important than otherwise might be the case.
My major concern, whilst playing the role of computer during the sessions, was that I would not be able to provide screens fast enough to the test participant. The speed proved to not to be a problem in that participant relaxed as the pressure was not on them but was on the me , the computer. Indeed the moments when I was straining to consider what page to present next lead to a few light hearted moments that eased any tension during the session. The slower speed of delivery also enabled the facilitator to take detailed notes (or so she kindly told me) and this saved time as there was less need to review the video recording of the session.
It should perhaps not have come as a surprise, but it quickly became apparent that users took the prototypes seriously and, as discussed, the higher fidelity meant that any errors in the interface were usually noticed by participants. I found this surprising as I had not realised that the participants would treat the computer system so realistically. For example within a journal record screen I had used an incorrect journal screen named “Applied Mathematics” instead of the correct “Advances in Applied Mathematics”. Participants were aware that the title was incorrect and this broke some of the flow of the session. In another example I incorrectly added the total of library fines within a "my loans" page - I was initially surprised by the number of participants that remarked upon this.
As mentioned, the relatively high fidelity of the prototypes meant that errors in the text used on screens were often picked up by users. It had been my assumption that fake or Greek text could be used with incorrect data– but the use of such text jarred with the participants. The problem was not that Greek text was used but that real text was used with mistakes in it. For many of the results pages we used squiggles instead of text and informed that participant that this represented result data – all participants accepted this without question.
During the sessions we were able to have observers from the stakeholders. There were several noticeable benefits in that they could see user issues and behaviour first hand and could also see the value of paper prototyping. Perhaps the biggest benefit was that we found that those stakeholders had dramatically higher levels of support for the studies final design recommendations than other stakeholders that had not attended. One small point is that we found it useful to get the observer to read a small form explaining that they were to remain a distance behind the participant and to remain silent as to not disturb the participant.
Overall I felt enormously enlightened at the end of the sessions and believe I have a better understanding of the methodology. I believe that using a package such as Visio can provide medium fidelity prototypes reasonably quickly, given a set of reusable interface elements and a moderately experienced application user. I look forward to next playing the role of facilitator so that I can knowingly glance at a nervous "computer" during a "malfunction".
Snyder, C. (2003). Paper prototyping: The fast and easy way to design and refine user interfaces. Morgan Kaufmann Publishers, London.