A prototype is a way to convey the accumulation of thinking to date when making a new digital product. At Outlandish we typically make the initial prototype in code and iterate every sprint, following the agile methodology.
Recently we have been exploring ways to prototype quickly at an earlier stage in the design process. With the right tools, we can test a prototype even before any code is written, and hopefully save on development time later on.
From ideation to prototype
So I will go through a quick exemplary journey from ideation through a creation of prototype that exists only on paper and a phone screen. Our example uses the app called POP for prototyping.
Finally I will show what kind of outputs and lessons can be drawn from the prototype through a simple methodology of scoring.
From Idea to Test
My impetus for trying out these tools was a workshop I attended in the north-western tech powerhouse, Seattle. Nicole Capuana, director of UX at Leandog, held a session at ConveyUX called From Idea to Test.
Nicola’s workshop pushed participants to see how much they could do in 3 hours: come up with an idea, sketch screens, create interactions and test a mobile prototype app idea – phew! The outputs of the session show in a simple form what early prototyping could look like.
As the workshop was based on teams of two, I got to meet my first local UXer at the user experience conference. The countdown begun with some quick ideas generation for an app. Quite a daunting task when you have little to nothing to go on and you have just met the person you are working with!
I began babbling about something to do with flight check in, since I had just gone through the horrible experience myself.
Thankfully we managed to keep ideas flowing and they eventually started to funnel around something related to time management. We kept coming back to the idea of getting out of bed on the right side.
Next we had to come up with screens for our app. So we got the sharpies out and talked about the kind of journey the user would go through.
We decided to jump straight to the user interacting with the app in the morning, pretending that the user had already populated the app with pre-set tasks. There wasn’t enough time to think about how the user would have set these up, and all the other questions that go with this, such as how far ahead would they plan, whether there would be a standard bank or whether they would customise their tasks on a day to day basis.
Plus, we didn’t have any research to inform us on user behaviour!
How would the user begin interacting with the app? We decided that the user could arrive at the app by a timed notification. These would have been pre-set, much like a get out of bed alarm in the morning. We also thought about the type of action a user was likely to make when sleepy. The interface needed to be simple with action areas as big as possible.
We divided half the screen into an area where a user can choose between tasks, while the other half was dedicated to the task taking place.
We thought that a swipe up would be a good way for the user to select a pre-set task, as it seemed like a positive movement. After the user swipes the task up they are able to start the task, or perhaps it could start automatically. It is possible to pause the task, but once the timer runs out the task would mark itself as complete.
This got us thinking about tasks without specific time parameters. Something like switching a kitchen device on in time to use, or booking an appointment.
We decided that we would have two types of task; one that the user could set up with a timer and one without a timer.
The ones without a timer would need to be manually marked as complete since the passing of time would not affect them. We decided that the user would do this by swiping the task into a finish zone at the top of the screen.
This was already a relatively complicated interface. How could we present it to a user testing the prototype? Welcome POP, a fantastic app that does a lot of the hard work for you when quickly transferring from paper to a sort of digital interface, or what we could call “a fancy sketch”.
It is quick and easy, and well worth doing in this sort of setup. The testing you will do will be closer to the type of experience you are aiming to get to. It is also fine to just move the bits of paper about to demonstrate your idea if you wish to do it this way.
ser testing will check that the design is aligned with user goals. It means that when making the next round of design or interaction alterations you will focus on rethinking the parts thatmost benefit from your attention.
If you have access to a smartphone, download POP and follow the setup instructions. I found them fairly straightforward, especially with the pretty onboarding! Start new project and take photos for each screen.
Once these are all photographed, or even as you are going along, you can decide how the user will navigate. You can choose what they need to press and in what way to get to the next screen.
The interface for setting this up is clever: tap the bit of the screen you wish to be the active area for said interaction (you can re-size this area) and then click the option link to and tap which page you want it to link to – done!
Rapid prototyping #conveyux with Nicole Capuana from @leandog pic.twitter.com/WhE5YFZh67
— Liz Thomas (@Li22i) February 9, 2016
Our first iteration of our app get out of bed was ready to go. We had designed and made a tool users can use to get them selves out of bed on the right side and in time to complete small morning tasks that leave them feeling positive and motivated for the rest of the day. Now we needed to check that people understood what the app was about and how to use it. The next step is planning the actual test with the user. We would recommend doing this by outlining three aspects of the user journey being tested: the objective, the scenario and the tasks that the user needs to complete. In our case these were:
Objective For the user to be able to select, play, pause and complete a morning task.
Scenario You just woke up and you want to see what preset morning tasks you have to complete
Tasks
- How would you open the app?
- How would you select a task?
- How would you play a task?
- How would you pause a task?
- How would you start a new task? Specifically one without a timer.
- How would you set this task as complete?
We ran some brief tests in our workshop. We experimented with another team on our table and a team from a different table. To keep track and assess the outcomes, we applied a simple scoring methodology. For each task we give it a score of 1 if the user was able to complete the task without any problems, a ½ if the user was eventually able to complete the task with trial & error and a 0 if the user was not able to complete the task.
As you can see from our pretty rough score card on our sticky notes. The swipe up for selecting the task and setting the task as complete only got a ½ each, both tests showed that the first action the user went for was a simple tap rather than a swipe. We would need to do the test with a further 3 people before deciding to make a design change based on this insight. Only testing with two people is obviously not enough. As a rule of thumb, you need at least 5 tests on a design before making any significant changes without risking bias. It is also a good idea to do a dummy round first to make sure that you have the right objective, scenario and tasks.
It would be more ideal to have recorded the numerical findings on Nicola’s digital scorecard on Google Sheets. I have since filled this out with the results from our test.
Even though our results are a bit premature, we summed up our findings from our two sessions with:
- Tap not swipe. Although it would be interesting to try the swipe with a higher fidelity
- Design for a timed task and a non time task more obviously different.
Further questions we had not answered included:
- What were the different user types? How would this affect the app?
- How does the user set their tasks up? Would they have different tasks for different days?
- How would the user share their achievements? How could the app give them encouragement?
- Could there be a way to show progression?
When presenting the Get Out of Bed prototype to a colleague it was really easy to communicate the idea with out too much explanation. And because we tested the app, I have a clear idea about what I would do to improve on the design – even though proper results would require a larger testing pool size. Both of these results demonstrate the power of prototyping early. We will be experimenting with how to include apps such as Pop and early prototyping into our development workflow at Outlandish.
