barry saunders

I’ve almost finished a prototype for work and have set up a nifty little testing studio with Magitest, Reflector and Invision. With this setup I can put my prototype in the user’s hands and let them play with it, and Magitest will record all their interactions with the prototype, as well as their reactions and comments.

I’ve also spent a fair bit of time running through the testing script, to ensure I get useful feedback. As Nathanael notes, just putting a prototype in front of a test candidate is highly likely to result in artificially positive results.

The problem with sticking a prototype in front of users without any idea of the success criteria is that there is a very good chance the prototype evaluation will be a success. Why? Because you invite people to participate in the activity, probably pay them for their time, put them in front of something that you’ve probably worked on (or they assume you have) and they’re more than likely to say that they like it, that it’s good and yes they would probably use the actual product.

I’ve been doing a lot more prototyping recently. I’m finding it to be much more effective than producing specifications and documents. I’ve been using a tool called Invision to prototype a couple of mobile apps.

What I find useful about Invision is it helps me map out a flow really well. I’ve always been a fan of ‘rubber-ducking‘ or self-narrating as a way of making sense of a piece of work; it’s useful in design as well as writing and editing. But when you’re working on a complex design it’s easy to lose sight of the various pages, transitions and states that you need to account for. That’s where a tool like Invision comes in handy.

When I start a design project, I map out a single user flow on a piece of paper. So for a shopping app, this might be a purchase flow.

1. Open App
2. Browse
3. Select Item
4. Select Payment Type
5. Enter Payment Details
6. Enter Postal Address
7. Confirm Purchase

Now, just walking through this flow in my head I can see that I’ve missed a few key things. I haven’t accounted for multiple purchases (say, two of the same item) or purchase of several items (two different items). I haven’t allowed the user to continue browsing after selecting an item, which would necessitate a shopping cart function.

So already our flow is starting to grow a bit:

1. Open App
2. Browse
3. Select Item
4. Add to Cart
5. Select Item
6. Add to Cart
7. Check Out
8. Select Payment Type
9. Enter Payment Details
10. Enter Postal Address
11. Confirm Purchase

Now I like to do a single flow first, and focus on the alternate flows and user states (logged in, logged out, confirmed, logged in but not confirmed and so on) after the first flow is done.

Once I’ve got this flow down, I can start thinking about what the app will need to be able to do and what elements it needs. From this flow I can see that the app will need a way of browsing items, a way of selecting items, a shopping cart, and a billing flow. So now I can start sketching out these elements on paper to get a sense of how they might look.

Once I’ve sketched up the key elements of the app, I can start building the project on my computer. I work primarily in Omnigraffle at the moment, using the layers functionality to create shared elements such as headers, menus and other modules. This allows me to build out the basic screens fairly quickly, as I can build up a page from the shared elements and just add custom elements as needed.

Once I have set up the shared elements, I create an Omnigraffle canvas for each page that will exist in the app. I used the shared layers for persistent elements, as I can update a shared layer once and it will update across the entire project.

I like to work with my Omnigraffle canvases set to the actual size of the app screens. This allows me to keep track of what’s on screen and what’s below the fold. It also allows me to export canvases directly to PNG for Invision, or other formats for use in Indesign.

Once I’ve laid out the screens, I fill in all the copy. I try to avoid using lorem ipsum except for large content areas. I write actual copy for all titles, calls to action and lists, so I can easily narrate my way through the flow and figure out where things are missing.

Once I’ve done all that, I can simply export all of my canvases to PNG and then drop them into the Invision Sync folder. This automatically uploads my screens to Invision.

From there I can simply go to the project on Invisionapp.com and start creating hotspots to link the screens together. Invision supports hotspot templates, so I can create a set of hotspots that correspond to my shared layers and apply them to all the relevant screens quite quickly. Simply going through this process is usually enough to show me where I’ve missed a few things, so I tend to go through Invision and with Omnigraffle open, making updates and creating new screens as I go. Invision recognises when I’ve uploaded a new version of a screen and retains the hotspot information, so I can update screens as much as necessary without having to update the links all that much.

Once I’ve done this and I’m happy that I’ve covered off all the screens in the flow, I load the prototype on my phone and click through it. If I’ve missed anything, it usually shows up at this point. I get my colleagues and friends to have a click through the prototype as well, to see if it makes sense to them.

Once I’ve taken all their feedback (Invision allows you to add annotations to the prototype directly, which is handy), I update the prototype once again and run through it to make sure it’s all working properly.

Now that I’ve got a solid flow working, I can start working on the alternate flows. For this app, I would need to think about

• Logged in state
• Logged out state
• Sign up
• Sign in
• Sign out
• Using stored billing details
• Adding/Updating billing details
• Purchase history
• Failure states such as expired financial details, connectivity errors

This is somewhat easier, as I already have the basic flow down. I can duplicate my existing shared layers and create versions of them for different states.

So to recreate the basic purchase flow for a logged in user, I can duplicate the menu (logged out) background layer and edit it to create a menu (logged in) background layer. I can now duplicate all of the canvases from the logged out purchase flow, delete the menu (logged out) background layer and add the menu (logged in) background layer.

Once I’ve finished the alternate flows, I export all the canvases and add them to the existing project. I can use the existing hotline templates or create new ones to link everything up.

At this point, I can go through and make sure both flows make sense, and that there are screens that link the two flows (in this case, log-in and log-out screens).

This is the point at which I would show the prototype to the client to get their feedback, to ensure my conceptual model of the app matches theirs. From there, we go through another round of iteration until everyone agrees on the structure of the app. After that, I hand over to the visual designers to work their magic.