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.

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.

They have a heavy media and content focus, which really fits with where my career is heading. A couple of people that I interviewed with noted that a media background is uncommon for UX, many people come up through design, HCI or IT. Content and UX definitely seems like a productive area for me, particularly as UX practitioners are owning and redefining the IA function.

They other thing that’s exciting is that they are building stuff directly in the appropriate technology stack, rather than forcing web technologies into spaces where they don’t work.

- Content is important, and simple IA / card sorting approaches aren’t enough. Content strategy, communication strategy and in-context content flows are increasingly important.
- Too many UXers are precious about their wireframes and produce work that encroaches on visual design, confusing clients and user-testers.
- Some UXers treat visual designers as people who colour in wireframes.
- Process is important, but flexibility more so.
- People who only deal in ideas and never get their hands dirty in implementation never learn what actually works and what just sounds good.

The more time I spend doing UX, the more I think the tools and the deliverables aren’t important. What’s important is using whatever process and tools are necessary to create a shared understanding of the project. That might mean sitting with the designers and sketching, that might mean play acting a customer conversation with the copywriter, or simply listening to the developers concerns and taking them seriously. It can mean explaining what the site analytics are saying about the users, or interviewing the users directly.

I developed a bit of a nickname as the ‘office mum’ when I worked at Sputnik. Increasingly I’m thinking that’s actually a good model of what UX should be about. Listening, caring, and helping people understand each other. And sometimes baking a cake.*

*Office parent, sorry.

Just back from a holiday in Fiji. Read a lot of books, went swimming, went hiking, and made some career decisions.

I would argue that the significant interest directed toward the cyberpunk genre in the 1980s reflected not merely the topical appeal of computer adventure for readers, but also an interest its technologically inclined readers felt as writers – individuals already trying to write themselves into the global network, looking for vocabularies and identities to borrow and cut up in this process of self-creation.

Hicks, HJ, ‘… She’s Since Become”: Writing Bodies of Text and Bodies of Women in James Tiptree, Jr.’S” the Girl Who Was Plugged in“ and William Gibson’s” the Winter Market’, Contemporary Literature, 1996

There are valuable design insights to be gleaned from these sources. Seeing a different solution to a problem can spark new insights and new designs. Commentary can also spark useful debates about particular approaches and aesthetics.

That said, visual design is only an aspect of software design, not its entirety. UX designers also have to help make decisions about affordances, functionality, trade-offs, business decisions, and monetisation.

Laptop, Wacom Intuos5 Touch Tablet, iPad, Unlined Moleskine, Nikon D40, Microsoft Mouse, assorted Artliners, JustMobile tablet stylus.