Category: UCD process

Make it measurable: set clear goals & success criteria for your projects

Leisa Reichelt10 Comments

Over the past few weeks I’ve been wrapping up and kicking off a bunch of projects. It is during both of these phases that I am reminded how incredibly valuable it is for me, as a UX practitioner, to proactively encourage my clients to clearly define the goal for their project and to create success criteria – ways that we can tell whether or not the project has been successful.

Be specific

In my experience it is very often left up to me to make sure that the project goals are as clear as they need to be. Many clients come into projects wanting ‘to improve the usability of our website/application/etc’, in my experience that is most often too vague a project goal as to be useful.

The kind of project goals that are really useful go more like this:

We’re getting lots of traffic to the site but not many are joining/buying/contributing/coming back. We want to fix this.

We’re getting lots of calls from people who have visited our website but still don’t know what we do. We want to fix this.

People are coming to our site and doing X but we really want them to start doing Y, we want to find out why this is happening and what we need to do to address it.

As soon as you start defining more specific project goals you can immediately see the way that success criteria start to become immediately apparent.

Measuring success criteria

Some success criteria are immediately apparent and easy to measure, for example return visitors, increased membership, activity or sales. Ideally you want to put some numbers around what you’d consider would define this project as ‘successful’, but even just identifying the metrics that you will use to judge the success of the project is a good start.

Some success criteria are less easy to ‘measure’ but don’t let that discourage you. Often for these kinds of criteria I’ll use a round of research to determine whether or not we’ve been successful – those things that are difficult to quantify are often quite easy to examine using qualitative research. I find myself more and more using a last round of research to ‘check off’ the less quantifiable success criteria for projects.

What’s in it for me?

Failure is a built-in risk of success criteria, but don’t let that put you off. Failing knowledgeably is actually an incredibly useful learning experience for practitioner and client alike (and yes, I speak from experience). I would argue that by defining clear goals and success criteria you are going to do nothing but increase your chances of success in a project.

Clearly defined project goals allow you to make all kinds of good decisions on a project and it can impact everything from design decisions through to who you recruit to participate in design. Just the other day a project I’m working on managed to avoid wasting a number of research sessions on ‘people we felt we had to include’ because we were able to really clearly define why, for the purposes of achieving the goals for this project, they were not our target audience. Without the clear goal we would never have been able to come to this decision.

Clearly defined and measurable success criteria similarly guide you through decision making throughout the project, but they also continue to be useful well after a project has wrapped up. Of course, we use them to judge the success of the project, but we can also use them to communicate this success to others in the organisation and beyond. Clearly defined and measured success criteria give us something tangible to talk about and take much of the ‘touchy feely’ fuzziness out of User Experience and that makes it much easier for more people to understand and appreciate the value of the work we have done.

Would love to hear your thoughts & experiences.

GeeknRolla – You Can’t NOT Afford Good User Experience

Leisa Reichelt3 Comments

I was fortunate to be invited to speak at the recent GeeknRolla conference in London and took the opportunity to share some tips for making your business more user focused with the largely tech start up crowd. I do lots of work with start ups these days so I understand that there are all kinds of ‘resource’ challenges in the early days. That said, there really is no excuse for not making an effort to engage your potential end users in your design and product development effort.

This presentation covers what I consider to be the four main areas of user experience, being:

  1. Choosing an audience. Startups (and small businesses in general) are notorious for wanting to avoid this step, claiming that their product/service is targeted at ‘everyone’ and that they don’t want to ‘restrict themselves’ by choosing a specific primary target market. Big mistake – design for everyone and you design for no one. Design well for the audience you’re most interested in and the rest will follow.Another common problem for starts ups is that they are actually designing for themselves (they are their own target audience) but lose focus by trying to design for ‘users’ without defining who those users are. If you are your own target audience, that’s fine. Admit it and go with it. Don’t lose focus.But probably the most common problem I come across is that while the start up makes efforts to be ‘user focussed’ it fails to admit that it’s *real* target audience, for the moment at least, is the investors who may give them more money if excited enough. What investors want to see and what early users of your service want are two very different things. If you are designing for investors, that is fine – admit it and go with it. You can re-focus on the real users of your service later.
  2. Understanding your audience: there are *lots* of ways to get to know your audience but obversational research (sitting down and watching and asking questions) is far and away the most effective in my experience. Yes, get your metrics in place, do your alpha release, watch your twitter stream, but DO find and observe potential users of your service, and do it regularly. Despite the rumours, it doesn’t have to be an expensive and time consuming exercise – in fact, you can do it yourself and you’ll probably learn more than you’ll know what to do with. There’s no excuse for not knowing exactly how users interact with your product, what works and doesn’t work and – most importantly – why.
  3. Applying your research in design: once you’ve done all the research, how do you make use of it in your design? One simple way is to make some ‘personas’ – basically some pretend users who are based on your research and who can sit around the table with your team and be ‘involved’ in the decision making. This is a MUCH better way of getting good user focussed decisions made than asking ‘what users like/do’ which is a totally nonsense question with no answer. Rather, you can ask ‘would Keith (our persona) like it if we added that service?’, ‘would Lillian (our persona) understand that sentence on the homepage?’, ‘what would Frances (our persona) most like us to do in this next development cycle?’. It might sound a little nuts but it really does work.

    The other thing I really recommend is that you hire the best designer you can get your hands on as early as possible, but don’t ask them to ‘design your website’ or application or whatever. Rather ask them to design a visual styleguide that you can then give to a less ‘resource intensive’ team member to apply now and into the future. This is the best way to get great value from a good designer – you let them do the work they do best and you get a road map for the future that will protect the design integrity of your service. The styleguide will include a few key templates but also a bunch of information about the grids that should be use, how colour and typography should be applied and a whole host of other very useful information.

  4. Think big and small: Last but not least I encourage you to look at user experience from the micro and the macro level. Do wonder if that button is in the right place ask whether moving it might improve revenue, but don’t neglect to ask whether people understand the overall proposition of your service and if they’re even going to get to that button in the first place. User Experience is a layercake and it starts with your proposition – it is all too easy to get too close to your product and not realise how inpenetrable it is for newcomers. So, think big and small.

Where do I start?

Most of what us User Experience people do is not rocket science – it’s just education and a whole lot of experience and a passion for what we do, much of this you can do yourself and there is a lot of material in books and online that will get you off to a flying start. The two books I find myself recommending most often to my start up clients are Don’t Make Me Think and The Paradox of Choice (the first one is more hands on than the second, but the second explains a lot of why the first one works).

Another thing I find myself doing more and more often is teaching my clients to fish – that is, doing quick training sessions that give them the essential skill set they need to successfully do the four things I set out above, all by themselves.

If you’re interested in learning these skills (or having someone in your company know them!) and bringing User Experience into the centre of your company then perhaps you might be interested in a one day Hands On User Experience training course that I’ve designed. I’d be more than delighted to show you how I do what I do, and I guarantee you’ll see the benefits in many more places than just the usability of your website/application!

design by committee vs design by community (things we learned from the Drupal.org project)

Leisa Reichelt16 Comments

Recently I presented a casestudy of things that we learned about designing with a community, the Drupal community, at the Interaction09 Conference in Vancouver. (I’m still trying to get my slides down to a reasonable size to post on Slideshare!) It was a short presentation so I thought I’d take some time to flesh out some of the ‘things we learned’ here for anyone who is interested. It certainly was an interesting, challenging and fairly unique project, and we’ll be doing more like this in the future, perhaps you will be too! This is the first post in a series of our learnings.

Often when I talk to other designers about the Drupal.org redesign project they can’t stop themselves from shuddering at the thought of having so many people involved in their design process.

It’s an understandable reaction – after all, how many of us have suffered design by committee, which is really it’s own special circle of hell, in which a group of somewhere between 3-12 (usually) stakeholders with various levels of authority (actual or effective) provide copious and detailed feedback to your designs – feedback that often conflicts either with itself, or with the objectives of the project, or just with the principles of good design. Usually these people are the people who are responsible for paying your salary or invoice. They can’t be ignored. As Whitney Hess tweeted and then blogged, they have itches that need to be scratched.

So, it seems logical that having thousands of people involved in the design process should be even worse right? Design by committee on steroids? Well, you might think so but, happily, you’d be wrong. It’s really a whole different beast with it’s own challenges and opportunities and – I’m happy to report – there is much more good than bad about design by community and it’s an approach that I’d encourage you to consider. (Unlike design by committee, which should be avoided at all costs.)

The main reason for the different experience is scale. Surprisingly, scale is your friend.

When you’re dealing with feedback from hundreds of people you don’t need to address every single issue raised. You’d be mad if you did and have no time for getting the design work done. Rather, what you’re looking for three things:

  1. emergent trends: what are the issues that multiple people are mentioning or agreeing/disagreeing with. If half a dozen people mention it, it’s probably worth looking at.
  2. unexpected comments: every now and then you’ll see something that takes you by surprise. (This doesn’t include comments like ‘your design sucks’ which you will get no matter how wonderful your design is – you have to learn to not be surprised by these!). When you get that ‘surprise’ feeling (you know the one) – pay attention, even if just one person mentions it.
  3. obvious pickups: – with a few thousand fresh sets of eyes, obvious mistakes, things you’ve just left off or misspelled for example, will get picked up quickly. Acknowledge those as quickly as you can so that they don’t turn into big (and often dramatic) conversations.

The absolute best way to a respond to an issue is in your design, rather than in responding to comments on a blog, messageboard, flickr posting, tweet or wherever you’re gathering your feedback (and I’d encourage you to keep it fairly messy and don’t just do it in one place – more on that in a later post!). You should stay in touch with the conversation and respond when appropriate (again, that’s a whole other post!), but the ratio of your responses to comments should be at least 1:10, if not closer to 1:50

This is quite a departure for most of us who are used to consolidated feedback lists and having to respond to every piece of feedback we receive, to begin with it almost feels a little naughty (at least, it did for me!) – but it is a really necessary approach if you want to maintain your integrity and not reliquish your responsibilities as the designer.

Remember – just because you’re working with a community doesn’t make this a democratic process. Design should never be democratic. We’re not voting on interface elements here, we’re working with a community to let them help us the best way they can – by telling us about their community and their product, in this case the drupal.org website and what they use it for, and drupal itself of course. Communities aren’t designers – they can give you a lot of GREAT information to help you design well for them, but that’s the crux of the issue – you need to find ways to work with them so you can get from them what they do and know best, and so you can do what you do best – design great experiences.

A big part of your role on a project like this is facilitation and communication, but don’t let those roles waylay you from your most important responsibility, which is to do good design.

It’s a terrifying but exhilarating experience, this community design caper. If you have an appropriate project, I’d really encourage you to give it a try. I’ll be sharing more of what we learned soon!

Drupal.org redesign – help usability test Iteration 6 next week!

Leisa Reichelt15 Comments

As you may have read, we’ll be doing some usability testing on the 6th iteration of the Drupal.org prototype in London next week. It seems like a great time to also kick off some crowdsourced usability testing, as we’d talked about earlier, and for any of you who’d like to get involved to do so!

(UPDATED!) Iteration six is now live here. I’d like to encourage you to take part in our Crowdsourced Usability Testing Campaign by doing a few tests yourself, wherever you are in the world, and contributing your findings back to the project.

Here’s what you need to do:

  1. Find some participants to take part – we want a mix of people along the spectrum of Drupal involvement from those who don’t know much to those who know lots and are super involved. Some tips for recruiting can be found here (feel free to add any other tips you have to our wiki!)
  2. Take a look at the prototype and work out how you’re going to approach the interview – some interview tips and a sample script can be found here (again, feel free to add more!)
  3. Work out a way to record your interview – some ideas here. Personally, I’ve found remote testing more hassle than it’s worth and much prefer to do in person interviewing. My technology of choice is a MacBook with Silverback installed for audio and video recording (you can get a 30 day trial for free). 
  4. Do your interviews!
  5. Share your interviews and findings! I’ve been exporting and posting some interviews on Vimeo, which is my preferred video sharing site. You can put yours wherever you like, just link to them from the comments of this post once they’re posted (and/or add them to the wiki where mine are now) – if you have some time to write up what you’ve learned as a result of the testing that would be fantastic! (If not, don’t worry, we’ll take a look through the video ourselves!)

That’s it! Not so hard at all, is it!

If you have any questions at all, post them here (no matter how silly they may sound, chances are others have exactly the same question or it’s something I forgot to cover in this post or on the wiki!) – I or someone else helpful will get back to you ASAP.

This is a great opportunity to help out with the Drupal project and a great chance to get some usability testing experience under your belt – which is a really fantastic skill to have, whatever aspect of design or development you’re most into. I really encourage you to give it a try and look forward to seeing what you come up with! I’ll be sharing my videos as soon as I can export them after usability testing sessions on Monday 3/11

If you’re able to do some testing early next week and post your feedback mid-late next week that would be fantastic. If this schedule doesn’t work for you – don’t fret – more iterations are coming hot on the heels of this one and more testing will be required and welcomed! You can get involved in the next few weeks if that suits you better.

Good luck, thank you and yay!