The Sweet Spot
Semi Permanent Sydney - recap
Diving into the digital deep end
A mobile paper prototype investigation
Scotts sign off
Getting into AngularJS
The stealing sh*t design workflow
Experiment - a new way of validating forms
New phones make my thumb feel inadequate
A front end playground
Growing your business from within
Gen-i to Spark Digital
Kelly's sign off
It’s kind of a big deal
Near miss for Frontend's Mascot
Responsive web - a light post
Great Scott Marty What Year Is It?
iPhone application design and the righteous retina
A mobile paper prototype investigation
Anna E. Saunders
Thursday 9 April 2015
Essentially, prototyping is a rough representation of an idea or function which is tested before creating a commercial and refined product.
Frontend always recommend a user testing session within a project. These are typically done with high fidelity wireframes or mock UI designs which include limited functionality of the interface. Low fidelity prototyping may be a solution to test ideas earlier in the project to validate thinking without investing a lot of time on development or design.
In this blog post I look at the process of creating and using a paper-based prototype and examine the benefits and drawbacks of this methodology.
Crafting the prototype
Before hitting into the crafting I needed to define the testing objectives. I have a personal project on the side and thought this would be the perfect opportunity to use this methodology to test the UI. I sketched out a few screen variations and simple workflow. With these sketches as the basis for the test I proceeded to craft the elements.
As with any prototype, the main goal is to validate a core idea or function; making things visually pleasing is not necessary.
Step one was to print out the phone template. That way I knew the width and height of the viewport I was going to be working with. Everything had to fit within that space and be relatively proportionate.
I created individual elements as separate pieces as it would allow me to shuffle things around providing me the ability to test a few layout variations.
Frontend has created rough paper prototypes in the past, but none to the level which I was working toward in this experiment. With it being such new territory, I decided it was important to run a small trial on the test itself. This was to see if the test instructions were clear, the labelling was logical and the elements were all working as intended.
By holding this pilot session I was able to learn what was working well and what aspects caused issues. During the dry run through it had been pointed out that there was no ‘back’ button within the navigation. I was quickly able to craft a back button then and there and add it to the prototype.
Just being able to create a new element so quickly and add it to the prototype was invaluable.
One of the main concerns was when the user moved the phone template over the layout to replicate the action of swiping. During this action a lot of the elements shifted out of place which made it hard to continue.
The main issues raised:
- • A flimsy phone template
- • Elements not stuck on anything and flew away easily
- • No way to simulate real ‘scrolling’
- • The entire page layout could be seen (no fold)
The final set up
Taking a small scale test early was valuable as I could amend these errors building a better, stronger and more intelligent prototype.
With a bit of cut and paste, the upgrades had been applied:
- • Phone frame elevated from table
- • All elements stuck on designated ‘background’
- • Handles attached background to allow user to scroll within the frame
- • Only phone screen cut out allowing content to be hidden
Ready, set, test
With the finely engineered prototype ready it was time to begin the user testing session.
On the table were additional paper, Blu-tack and scissors in case something had to be modified on the fly. One of the benefits of the paper prototyping is the ability to modify things quickly and easily.
The first task of the day was for the user to scroll through the homepage whilst I recorded their initial thoughts and reactions.
The user was prompted to select the map pin icon. In doing so, I removed the current screen and placed the map screen in the viewport. The map screen had been originally set up so it was just a matter of a quick swap around.
When it came to showing the second layout variation of the homepage it was a different story. I needed to reshuffle all the elements around whilst the user sat waiting. It was relatively easy to shuffle the elements as they were adhered by Blu-tack, though the process was slightly stressful as I felt I had to perform the task quickly whilst being observed.
What was learned
Recording During a digital prototype session Frontend employs the use of recording software to capture the face of the user during the testing session and the screen itself. The benefit of this is we can revisit the test and make further notes based on the user’s reactions when they perform tasks. This is not possible for the paper based prototype. Instead, we used a GoPro and head mount to record the physical interaction of the user’s point of view with the prototype. Whilst this approach accounts for the action of them performing the tasks we miss out on seeing their face during the test.
Faux scrolling When you interact with your phone it’s usually with one hand and your thumb does all the work. The paper prototype I created does not replicate this; instead the mobile phone layout is stuck onto a table. When the user interacts with it, it is more like a tablet whereby using their forefinger to make contact with the ‘screen’ area. With some placement of elements being critical to decision-making the less than accurate representation of a phone experiences does not allow for a true test.
Test, adapt, repeat A profound benefit is the ability to add, remove, change and adapt the UI on the fly. During one point in the user testing session I had to quickly create a new element and add it to the test. This could not have been achieved at lightning speed during the test in a digital scenario. One drawback of this approach is that it may create inconsistent experiences for different users.
Layout changes Where the paper-based prototype suffers is the time taken to change the layouts. Typically in a digital based-prototyping session you’d have the different variations already built up, and it’s a matter of switching between them.
During the testing session I had to change the layouts around a few times as the user sat by idly. To alleviate this I could have prepared each single screen rather than shuffling the elements around. This of course would have taken more prep time, so it’s a trade-off between spending more time crafting or shuffling elements during the test.
It also becomes an issue if a comparison needs to be made between multiple layouts.
Creating the ideal One of the greatest aspects of the paper prototype was the ability to get the user to fully interact by getting them to create their ideal layout. This task does not require any specialised skillsets as paper and pencils are universal tools. However the idea of shuffling things around and crafting new elements if the user saw fit may seem like a daunting task for some. Then again, some may relish at the opportunity, so I guess it’s dependent on who you get on the day.
User testing base The user that completed this test was comfortable about viewing a digital concept on a paper prototype. It would be interesting to see how other users handle the concept, as it has been known in the past that some users get hung up on aesthetics even though they have been told they are purely testing the function of a site. Is the paper-based prototype too abstract that users will have trouble to see the prototype for what it’s representing? Further tests will need to be conducted to draw a conclusion to this.
Low fidelity prototyping has its merits. This experiment proved that the paper prototype allowed quick construction of an idea which doesn’t require hours of design or build time. In terms of time saving and quick validation this solution can be employed to convey a concept at a rapid speed.
The drawback is the mock ups are very abstract, and we lose the actual interaction a user will have with the perceived device. For instance, where testing placement of an element is critical I’d likely steer towards a digital prototype delivered on the appropriate device.
Where I see the paper prototyping being of great use is to test ideas and workflows quickly. It will be exciting to see where the low fidelity prototype leads us on our next project.