Archives For

If you use Sketch and Alfred, this is a great little workflow for quickly finding Sketch files. You can just open Alfred, type ‘sketch’ and then a filename and it’ll find the file for you.




I put together a similar one for Photoshop – just open Alfred, type ‘PSD’ and then start typing the filename and it’ll show your PSD. Hit enter to open the file. 


My presentation from the FWD conference.

Some further reading:

UX Team of One

Lean UX

A short presentation I did at work on understanding how products are used, using Instapaper as a case study.


October 25, 2013 — Leave a comment

Dermot and I are in a book about VJing.


A fairly well-worn truism in UX is ‘you are not your user‘. It’s usually meant as a reminder that you as a designer/developer inevitably have a level of technical expertise that the majority of users will not have. It’s also a reminder that what makes sense to you doesn’t necessarily make sense to anyone else – which is why design practice involves a lot of iteration and user-testing.

But it’s also useful as a check when you feel the need to pontificate on other people’s software products. For example, if you feel like you can dismiss a software product with over 1 billion active monthly users as ‘gullible’ or ‘people who love to talk but have nothing to say’ and declare ‘it can’t be fixed, it’s over’, then you have made the classic error of presuming your needs and desires map to everyone else’s. They don’t.

First Week

June 1, 2013 — 1 Comment

First week at the new job went well. Profero’s a digital agency, so I’ll be doing more comms campaigns, websites, that kind of thing. Looks like I’ll be doing a lot of prototyping, guess it’s time I finally (re)learnt to code.

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