Archives For ux

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. 


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

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.

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.

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.


UX, at least in my experience, is multidisciplinary practice that entails an indepth, embedded knowledge of one’s culture. It’s a practice that sits at the nexus of creative design, content, and technology. It’s in the middle of hard data, soft data, aesthetics, intuition, communication, and account management. Not many people can hold every single aspect of a web project in their heads, so inevitably we develop heuristics and shortcuts to make things more efficient. We rely on our experience, our implicit knowledge and our intuition to work together.

Research is important. Data driven design is important. UX practice can and does involve very close-focus decisions that are informed by testing and analytics. Testing is everything from guerrilla testing to A/B and multivariate testing. Analytics is everything from bounce rates and page consumption through to user flows, goal funnels, hover patterns and user tracking. This is all important.


Chances are, unless you’re working in a consultancy with an extensive testing contract, or working in a UX team with a testing lab, or working on a high-traffic web site with functionality for rapidly-deployed multivariate testing, you’re not going to be able to do all of this. On some projects, you’re not going to be able to do any of this.

If you work in a design agency, or a creative agency, you’re probably working on multiple client websites. You’ll rarely have access to the history of the project, particularly anything that was done by the agency before you. You’ll probably only be brought on to specify the current project, which may be anything from a whole site refresh / rebuild, to the design of a single page. You won’t know what the previous agency tried to do, and why it didn’t work. Chances are the previous agency was in the same situation you’re in. They were probably using a best practice approach with limited information, and the project may have failed in spite of that. Maybe there was a downturn in the market. Maybe someone stuffed the site with keywords and Google nuked its pagerank for 6 months. Maybe the client had $10k and wanted to compete with CNN. Maybe the client got cold feet halfway through the project.

You will probably never know any of this. But you have been tasked with making a website that keeps the client happy, appeals to their users, is usable and accessible, on-brand, on-message, within budget, on-time, and beautiful, even in IE6. And by the way, the client’s bought into a ten year contract with a kludgy CMS that never, ever generates decent code, your dev team are overloaded and have priority bookings on other clients, you’ve only got 16 hours of billable time for UX/content strategy/analytics framework and your designer is about to go on holiday. What do you do?

This is a little checklist that I try and work from. I don’t always manage to use it, but it’s pretty good place to start. It’s useful for getting on top of a project from the very start.

Step 1: Get a brief.

Do you have a brief? If not, get one. Get a sit-down briefing from the account manager.

Still no luck? Write your own brief. Should take about 15 minutes.

Basic brief structure:
- what is the project?
- what do they want to achieve?
- budget
- timeframe
- constraints
- requirements

Ok, now you’ve got a brief. Give it to the account manager. Account managers are always busy, and they can be a bit hard to deal with if they’re in the middle of something. However, account managers are your friend. This doesn’t get said enough, so let me say it again: account managers are your friend. They deal with all the numbers, the clients, the organisation stuff so you can do your job. You know how much you hate doing your tax? That’s the kind of stuff they do every day so you can be creative. So cut them some slack.

So, with that in mind, ask your account manager to have a quick look at the brief you’ve written up. They’ll very quickly let you know if you’ve missed anything, or you’ve gotten anything wrong. Take notes, fix your brief.

Ok, great! We now have a brief.

Step 2: Coffee shop

Now, take your brief, a stack of paper and some sharpies, and go to the coffee shop.

Purchase a caffeinated beverage of your choice. I like a soy latte. Doppios are good too.

Don’t begin your beverage just yet. Let it sit on your table, gently tickling your nose. Mmmmm.

Ok, so, now read your brief. Read it again. Highlight the things that jump out at you. Highlight the things that you _know_ are going to be a pain in the ass. Highlight the things that you’ve worked on before. Circle the things that need research. Note down any references to previous projects that were similar. If you work in an agency, you’ve worked on at least 3 specifications for every 1 project that actually got built. Some of that stuff is reusable.

Ok. We’re trying to see this project from every angle. That’s why you’re not allowed to drink your coffee yet. I want you to mess with your brain chemistry just a little bit. The perspective of a hungry, impatient, un-caffeinated person is different from that of a well-fed, juiced-up coffee fiend.

Ok, now you can have your coffee.

Step 3: Drink your coffee!

Mmmmm. Good, yeah?

Step 4: Sharpies.

Once you’ve got some coffee inside you, pick up a Sharpie and start taking notes.

Firstly: what is the client trying to do? Not ‘what have they asked for’. What are they trying to do? The answer is rarely ‘build a website’. A website is a means to an end. The end is usually ‘make more money’.

List out all the other things the client could do to achieve the same goal.

For example:

You have a client with a small business selling bath soaps. They want you to build them a brand new website. They have an existing site that has never generated much business, and they feel a new site will bring in more traffic. They have a budget of $5k, and one of the owners can edit a bit of HTML and is familiar with Facebook and Twitter.

What else can we do in this situation?

Well, we could:

- Tidy the existing site
- Run a social media campaign
- Do some SEO and SEM to drive traffic to the existing site
- Create a content strategy

There’s a few things we can do in this situation. Take note of the other possibilities, and take a few notes on what the project might entail. Take note of how much it might cost. Particularly take note of possibilities that are likely to be more effective for the client. Clients are usually willing to be sold on a more effective solution. In this situation, my initial thoughts would be to:

- Tidy up the existing site template
- Work up an SEO / SEM strategy to bring in more site traffic
- Work up a content strategy to ensure the site is being regularly updated, in line with the SEO strategy
- Sketch out some ideas for a social media strategy that the staff can work on together, to launch in a couple of months
- Propose a stage two project with a more in-depth site redesign, contingent on the success of the initial project.

In this situation, we want the client to have some ‘quick wins’. There’s a lot they can do, and a full site redesign is just going to chew up money and time. Some smart campaign work with social and SEO, and a site ‘tidy-up’ is going get them some results now, rather than six months time.

Also, once they start making more money, they can see a) your skills and b) the value of investing in their web properties.

This, hopefully, means you’ll have a larger budget for the stage 2 project.

Step 5: Diagram.

Ok, so, you’re still at the coffee shop, and you’ve thought through all the different options. Take 5 minutes and sketch up a diagram of the different options with some notes about complexity, benefit and cost. You’re going to take this back to the account manager and show it to them, so make it easy to read. They’re busy, remember?

Now pay for coffee, pack up your stuff, and go for a walk around the block.

Step 6: Walkies.

Pull out your mobile and call your favourite developer. (Well, I do this because my developers are in Melbourne. You might be able to just chat to them in the office.) Have a quick chat to them about what you’re proposing, and get a sense of the relative complexity of it. Developers are also usually busy, and they don’t appreciate distractions any more than account managers do. If anything, they’re probably more irritated, because they had the entire structure of their current project in their head when you called. So be nice.

Make sure they know that you want to get their input because a) they know more about actually building the damn thing than you do and b) you don’t want to give them a poorly specified job. Also, you want their input because it’s much more efficient for you and them if you have the chat up front, rather than in a week after the client’s already signed off on the specification.

Ok, now you’ve gone through the initial process. You should have a sense of the project scale, the alternate options, things to look out for, and what other projects you’ve worked on that you can reuse / appropriate. You’ve gone for a bit of a walk to clear your head, see if anything else comes to mind.

Step 7: Accounts

Now, go back to the office, and have a chat with your account manager. Wow them with your attention to detail, your commitment to creating the best solution for the client and the users, your thoughts around how they can position the work into an ongoing project, and your thoughts around potential budget-busters. They’ll appreciate your work, and they’ll take it back to the client and convince them of its value.

Having gone through this process, you’ve given yourself a good start on the project, brought the account manager and client into line with your thinking, and you’ve given the developer a heads-up on what’s going to land on his desk next week.

Step 8: Get to work.

You know this bit. Hop to it.

Breaking out of design patterns | TechRepublic

The urge to copy and paste from old documentation is strong, particularly when you’ve worked similar solutions before and you’re under time pressure. But chances are that if you sit down with a blank piece of paper and a cup of coffee, you’ll come up with a better, more efficient solution.

The value of rough sketching | TechRepublic

Detailed sketching is useful when a solution has been agreed upon. However, rough sketches are even more useful in the early stages of design work. This is not just because sketching allows you to design a solution, it is because it allows you to design many solutions.