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.

I’ve been job hunting for the last couple of weeks, and have had interviews at a number of different places. It’s interesting to hear some of the same themes coming through:

- 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.

Cyberpunk notes

September 2, 2012 — Leave a comment

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

Unsolicited redesigns and design commentary | TechRepublic:

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.

UX Kit

September 1, 2012 — Leave a comment

Need to get a better photo, but this is my basic UX kit.

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


I’m usually fairly wary of calls to apply design thinking to politics and to fields like education – it frequently leads to problematic calls to ‘flip the classroom‘, learn to code and de-politicised yet heavily ideological political movements at best. Design thinkers often try to apply domain-specific knowledge to other areas without addressing the existing knowledge of that domain – political process and pedagogy being two of the areas that frequently get ignored. Designers can be pretty unaware of their class privilege and design thinking can lead to some amazingly offensive solutions to political problems. The technocratic authoritarianism of China is another example of applying design / engineering process to political process. There’s a lot of work to be done in understanding underlying ideologies in the design / engineering process and what happens when they apply to politics, whether they be democracies or technocracies or non-state actors.

However, Ben Hoh’s thoughtful piece about progressive enhancement within web design as a frame for political change is intriguing. I find it particularly interesting as I tend to think of politics in a discursive frame rather than a problem-solving frame, which tends to separate design-as-problem-solving from politics-as-discourse in my head. Of course, there’s more than problem solving to design, and problem solving is a core part of politics.

My particular field – UX design – tends towards more democratic engagement with users, often to the point of argument with creative designers. I’m excited to see projects that advocate a sense of political engagement from designers, that reject technocratic approaches, and seek to empower users.

From degradation to enhancement: redesigning society

So, if our degraded attempts at Utopia remind me of design’s graceful degradation, design should return the favour: what might progressive enhancement suggest in the world of culture and politics? As a designer who hungers for progressive political change, this question intrigues me. At the very least: rather than groping for a Lost Symbol of freedom, which would leave plenty of us with a “graceful”, less-than-ideal experience as a fallback position from a fetishised Utopia, progressive enhancement suggests instead that a well-designed experience of freedom can be built outwards from a core structure of meaning, in multiple ways, and in uneven terrain.

Ben’s only just started thinking about this, so I’m not going to engage too critically with this idea just yet. I think there’s a lot of value in it. It also interests me particularly as Ben has worked in fields outside of design and has written about design, media, politics and science fiction. He also wrote my favourite analysis of the conspiracy theory mindset.

My initial thoughts are:

The move from the frame of ‘degradation from the canonical design’ to ‘designing outwards from the core content of the page’ is certainly feels more emergent. However, progressive enhancement designs are still designed. Even the best computer with the largest display and the latest browser will still only display what has been designed to display there. You may be able to incorporate some generative animation to make use of the extra space and functionality, but that’s still not emergent in any true sense. I feel any frame that’s applied to politics must allow for emergence or it runs the risk of being overdetermined and technocratic.

I imagine user-generated content and iterative co-design practices may fit into this project somewhere, as parallels to the public engagement aspect of politics. That said, UGC and co-design aren’t exclusive to progressive enhancement.

Accessibility is another aspect of web design that has its own explicit political project. Accessibility and web standards in a sense analogise the welfare state, insofar as they provide a base level of access to those with limited resources and ability. This political project will need to be addressed within this frame of progressive enhancement.

The idea of using breakpoints to display content rather than simple mobile / desktop versions might nicely analogise a move away from reductive class analysis to a move granular view of class politics.

And lastly, we need to think about political analogies will work with progressive enhancement. Ben makes the point that the language of degradation parallels the discussion of Stalinism:

Meanwhile, you can find graceful degradation’s ambition — assuming a maximum specification, and then making do in less than ideal circumstances — in the experience of Stalinism, and that really wasn’t so graceful, was it? In the absence of a worldwide socialist revolution in the wake of World War I, Stalin’s defensive pragmatism of “socialism in one country” was clearly the wrong kind of pragmatism. (It’s no accident that orthodox Trotskyists, who utterly opposed Stalinism, still defended the Soviet Union as a “deformed workers’ state”, i.e. a degradation of a canonical design.)

I’m wondering then what progressive enhancement might align with. Design that provides more content to those with greater (browser) capacity might end up paralleling meritocratic capitalism as much as it parallels social democracy. Then again, design that provides more capability to those with greater capacity-for-engagement might nicely parallel a participatory democracy. There’s a lot of think about here, and I’m happy to see design thinking engaging with politics in a nuanced way.