disambiguity

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

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

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)

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!

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!

Drupal.org – Prototyping commences!

Progress continues apace on the Drupal.org redesign project – thanks to lots of help from you, we have now moved into the rapid prototyping phase.

In the spirit of this open redesign process, you’re more than welcome to take a look at the prototype as it evolves from its current, very sketchy state to … well, whatever it becomes. Hopefully a great home for the Drupal.org community and their product!

Now, be warned – it’s not pretty and it is far from complete. There are some things we kind of like and plenty we think may be a little dodgy, and some stuff that is just holding a place until we have more time to think on it (or to generate a little feedback in the meanwhile). The visual design (colours, fonts, etc.) of the prototype bears not resemblance to what we imagine the finished Drupal.org website will look like. Some of the content we kind of like, a lot of it is just holding text. It is very much a work in progress!

It’s really all about what’s on the page and what it’s called – lots of information architecture to look at really!

Anyway – enough with the disclaimers – why don’t you go take a look for yourself and, if you’re so inclined, leave any feedback or questions you have in the comments here and it will go into the mix for the next iteration. I’ll let you know when the next version is up for you to take a look, and we’ll continue like that for the next few weeks at least, as we gradually build in all the content and functionality and fine tune the content and interaction.

Drupal.org Prototype Development – Iteration 2

Drupal.org – come wireframe with me!

There is a design game that I like to play when I’m working face to face with my client (and when there aren’t thousands of stakeholders!) which involves everyone on the project sitting down together and individually sketching up some wireframes that then get shared back into the group.

Aside from being good fun, it is also a really great way to uncover good ideas, common themes, and a whole raft of information and assumptions that haven’t yet surfaced in the project but that are important to us getting the design and information architecture right.

I don’t see why we should let our ‘virtual workspace’ stop us from playing this game, so, let’s do it. Let’s do some wireframing together!

Here’s what I want you to do:

1. pick a page on Drupal.org – it could be the homepage, it could be your profile page, it could be a project page, it could be a page that doesn’t exist that you think *should* exist – just pick one that is important to you.
2. have a go at sketching out what you think might go on that page. What are the content and functional elements, and which ones are the most important.
3. post the page somewhere – if you’re using Flickr, you can post it to our Flickr Group, or perhaps you want to post it on your blog and put a link to your post in the comments here, or you can email it to me if you like and I’ll post it – whatever you prefer. You might want to add some notes as to why you’ve approached the page the way that you have or, if you’re like me, to decipher your handwriting.

You can use whatever you like to wireframe – I tend to use pen and paper to start with or sticky notes. Then I’ll use Omnigraffle a little later. You might prefer to sketch in code. Whatever works for you. As you can see from the example I’ve posted above, early wireframes are usually pretty rough (mine disintegrated into a list at the bottom!) and not so pretty. This is fine. It’s not about how they look or even whether they’re right. It’s about getting ideas down on paper – to paraphrase the old saying – a wireframe is worth a thousand words.

Don’t spend too long on it – try to spend no more than a few minutes on a wireframe. If you’re not happy with it (and you probably won’t be at first!) just put it to one side and start fresh. You don’t want to labour over them too much at this stage.

Don’t think you have to be a designer or a UX person to participate in this exercise – this is all hands on deck. Even if you’re not an experienced Drupal user and you were flummoxed by your experience of Drupal.org – what did you *want* to find on the homepage?

I know there have been lots of discussions over the years about various parts of Drupal.org – let’s roll up our sleeves and get stuck in! Yay!

Outsiders and Insiders – Understanding Drupal.org users

OK, there are two important first steps you need to take when contemplating a design (or, in this case, a redesign) – understanding what the business/organisation wants the design to achieve, and understanding who your audience/customers/users/potential users are, and what they want to achieve, what their goals are.

A really common way to capture this information about users is in the form of personas. The personas can then be referred to throughout the design process to test that what you’re designing is actually the right thing for your end users, and to help you to prioritise functionality and content on the site. Basically, to stop you trying to be all things to all people, which as we know, is the fast track to failure.

Now, I’m the last person to suggest that personas are highly scientific (although some people do work very hard to make them statistically sound) – to me, this is not the best way to spend project time. It is imperative that personas are based on research though – going out and actually meeting a bunch of people who form your target audience, because very often, the personas you need (or, at least, the way you ‘break down’ your audience) is what it might first seem.

The Drupal Community put together some personas a while ago, featuring characters like Mary the Manager, Tim the Tool-User, Wendy the Webmaster and more. As you can probably guess, they are based on the ‘role’ that users are playing in relation to Drupal. At first blush, this seems like a logical way to segment the Drupal audience.

It is an important segmentation but – as I’ve discovered over the past few weeks – I don’t think it’s the most important one. Firstly, as we saw in our survey, and this was supported by what I heard when talking to members of the Drupal community, very many Drupal users work across a range of different roles. They do some developing, some designing, some decisionmaking, some sales… all kinds of things. I don’t know this as a fact, but I’d hazard a guess that the ‘pure’ Drupal developer is actually a minority. Just a guess.

At any rate – it doesn’t really make sense to have Danielle the Designer as a persona we’re designing for because Danielle is much more likely to do some code, some design, some content administration, some dealing with clients. The role based persona doesn’t accurately reflect the kind of people we’re meeting out in Drupal-land.

Proposed segmentation – outsiders and insiders

I think our audience segmentation for Drupal.org should actually be a lot simpler than personas – it’s about ‘outsiders’ and ‘insiders’ and the path that people take from their first encounter with Drupal.

Insiders:

Insiders are those of you who are close to the Drupal community – who know and love Drupal and the people who gather around it. You understand ‘Drupal-speak’, you know who’s who in the zoo, you ‘get’ open source. You’re clued in, and you’re also incredibly important to the ongoing success of Drupal – both through the project work that you’re doing (if you’re an ‘insider’ you’ll know what I mean by ‘project work’, if you’re an outsider, you probably won’t – see, Drupal-speak in action, I’m rapidly being indoctrinated!). Also through the community work that you’re doing – Drupal ‘insiders’ are critical to getting people over the ‘brick wall’ I was talking about in our Experience Strategy, they are the people who help ‘grow others up’, or to educate them in the mysterious ways of Drupal. They’re very important people.

They are most likely to be, but not exclusively, developers. Or, at least, to have written code in a past life. This is why Drupal-speak is very much techy-speak.

Outsiders:

Outsiders don’t know much about Drupal, although they have have installed it and gotten a site (albeit ugly) up and running. They may not know what a module is, although they may have posted on the Drupal forums seeking help. They definitely don’t know about the IRC channel where the insiders live. They are facing a fairly steep learning curve (including learning Drupal-speak!). They haven’t ‘hitched their wagon’ to Drupal – yet. They might get a better offer elsewhere.

Along the engagement pathway:

Some of you will identify as Insiders and some as Outsiders, but very many will fall somewhere along one of the ‘engagement’ pathways I’ve scrawled in the picture above. Some of you know a LOT about Drupal, but you’re not a developer so you don’t feel like you’re a ‘proper’ insider. Some of you are well on your way to becoming an insider, having gotten access to the right tools and – more importantly – the right people! Some of you used to be much more of an insider but have other things on your plate at the moment that have drawn you away a little. Some of you have tried to head down the engagement path, but are being thwarted or scared off.

As we move forward with the redesign, this is the model that I’m suggesting we use to evaluate the work we’re doing – to consider this engagement pathways and to plot some key points along it and to see whether what we’re suggesting is going to support users at each of these points on the pathway.

This way, we avoid designing only for those of us who are loudest (and probably most engaged in the community), and we maintain a focus on the range of experiences we need to support on drupal.org – maintaining focus on what matters – the people who use the site, rather than the technology, or the tools or anything else that needs to be wrangled into a good user experience.

What do you think? Does this make sense to you?

Contemplating Open Source UX

There are many reasons why I am tremendously excited about being involved in the redesign project for Drupal.org, not the least of which is that – for a change – I’m actually allowed to talk to you all about the project as we go. Afterall, it’s an open source project – we don’t care so much for confidentiality and Intellectual Property, what we care about here is being open and being part of the community.

Exciting yes? but also somewhat terrifying! What an amazing (and enormous!) community to try to become a part of! As Mark said in our keynote at Drupalcon – it feels like being the new kid at school – will we make friends?!  But one of the things I’m really thinking hard about is how to harness their amazingness in the best way for this project?

Back in the olden days I was a project manager, so I have a great appreciation for an approach that works to limit the amount of feedback that you take into a project – how much, how often etc. Trying to get ‘consolidated’ feedback has traditionally been the goal, so that we can move through the design process as efficiently and calmly as possible.

As a part of our plan we have already factored in ‘community feedback’ to the iterations of the prototype that we’ll be releasing from very early in the design lifecycle – the community *will* be involved in this project, albeit in a somewhat structured way.

But, against all of my project management instincts, I am itching to get as much community involvement in this project as I possibly can! To encourage the entire community to think about things like experience strategies, and information architecture and  user centred design.

I am tempted to set up a Twitter group (@drupalredesign perhaps) where we can all tweet little brainbursts we have about the redesign. To set up a Flickr group where we can all post annotated screenshots of stuff we like, stuff that’s broken. To blog about half finished ideas I’m having about strategies and solutions we’re working on.

This is all ridiculously dangerous from a expectation management perspective – there is no way on earth that we could make any assurances about taking everything into consideration, answering every suggestion or issue raised, solving all of the problems…. (don’t let me start coining a project management buzzword that involves ambiance!)

And yet… it’s also ridiculously exciting.

Already, from blogging about the gaming / karma issue, I’m now talking to someone out in Drupal land who is already working on a module we might be able to use. I wonder whether we would have made that connection otherwise.

Eh. I almost feel as though it is inevitable. We have to open up completely, and just see what happens.

I’m almost certain some expectation management/ community disasters will ensue, but hopefully also some amazingness. I’m sure you’ll hear all about it as we go!

What say you? Am I having a moment of insanity? Or shall we open the floodgates and see what happens?

On documentation (or lack thereof)

I was talking to someone recently about doing some work with them. They said ‘can you send me some examples of documentation you’ve done lately’ – they wanted this to check that I could do what I said I could. Fair enough. Except, aside from the fact that all the documentation I’ve done lately is commercially confidential, so I’d have to hack it around a little to be able to show it to someone else… it made me realise how long it’s been since I’ve actually done the kind of ‘finished’ documentation I used to spend a lot of my time doing.

I just don’t work that way anymore, it seems. Sure, I still do wireframes every now and then, but never a ‘complete set’ and often with no where near the detail I used to include. Why? I think there are three reasons. Firstly, I tend to work on more of a strategic level than a detail ‘exactly where does that button go’ level these days. Secondly, I tend to work on projects where there is no time for that level of detail. And finally – and most interesting I think – I tend to work closer to the production team these days – more often are graphic designers designing and/or developers developing the very same stuff I’m wireframing at the same time. Investing too much in the documentation is a waste of everyones time – much better to do just enough to get them going and then work collaboratively with the team to do the fine tuning.

Personally, I think I should have been working more like this since forever.

Does any of this sound familiar?

Guerrilla Research – Recruitment

It’s been almost a year now that I’ve been doing predominantly ‘guerrilla’ design research. For me, this means testing in the field with a minimum of time, budget and fuss so that this kind of activity and the insight it provides is available to pretty much any client/budget/timeframe.

One of the first challenges for guerrilla design research is recruitment – the particular objective being to avoid using recruitment companies in order to reduce the cost of the project and also avoid the delay (often up to 2 weeks!) that is typically associated with recruitment.

A common approach to guerrilla recruitment is simply to rock up at a venue where your target audience is likely to congregate and to try to recruit on the spot. Typical venues might be a local Starbucks or a conference.

This is not an approach that I tend to use, for a couple of reasons – primarily because I really have to relinquish a lot of control over who I involve in my research… more than I feel comfortable with, given the responsibility that I have to my clients to provide them with useful insight. Also, sometimes the recruit briefs I need to meet are quite complex and require me to be quite selective when identifying participants. This is quite difficult to do on the fly and face to face… it can lead to either some awkward moments or spending time doing research with people who aren’t really quite right.

The approach that I have been using (and many of you are probably very aware of this!) is to use my online social network using tools such as my blog, Twitter, LinkedIn, and FaceBook. I have been pleasantly surprised by how successful this has been – on a number of levels.

Essentially how it works is that I work with my client to define a ‘call for participation’ that will be posted – the objective here is to get people interested in the research, to get more rather than less people to contact us, but hopefully mostly people who are at least close to right for the profile. I have to say, I am quite happy not to have to put together screeners any more (or review screeners received from recruitment companies). In fact… if I never saw another screener again I’d be perfectly happy

I do, up to a point, think about what ‘channels’ to use. As a gross generalisation, somewhere like Facebook is better for a less technical participant, where as Twitter is better for a more technically savvy participant… this is a gross generalisation though because more often than not, the people who I end up meeting are not directly in my network, but friends, family, colleagues of people in my network. This is the real power of ‘guerrilla’ recruiting, and a big reason why the ‘channels’ matter much less than having great people in your networks (Preferably great people with lots of friends, family and colleagues!)

To date, my experience has been that undertaking recruitment in this way has been cheaper (obviously – I don’t charge myself or my client ‘recruitment’ fees per participant), and faster (rather than weeks, recruits are sometimes filled within hours, definitely days of posting a call for participation). The most pleasant discovery has been that the quality of research participants is significantly higher than I had experienced when using recruitment companies.

In the past 12 months I’ve interviewed dozens of people and only had one ‘no show’ – and that was just a mix up with the dates as opposed to someone who just decided not to show. If you’ve done much research you know that it is not uncommon to have a day of six interviews lined up and only to get four participants to show up.

Some of the recruits I’ve had to fill have been fairly simple, but there have also been some incredibly complex briefs that I have no idea how I would have managed to effectively communicate to a recruitment company.

And the people who do turn up are fabulous – I’ve been amazed at how close to the ‘brief’ almost everyone I’ve met has been. They’ve been interested, enthusiastic, articulate and certainly not ‘professional research participants’ – the bane of any researchers existence!

Of course, you can always just take your design and show it to people in the office, take it home to your own family, show your friends – this can be very valuable. If you’re looking to do some research that is slightly more formalised, then perhaps you could consider using your own online social networks for this purpose.

It has certainly made me value even more the networks that I have in place and thankful for the great people who I interact with in these spaces.

(and, while I’m at it – if you’ve helped me with recruiting in the past year or so – thank you, thank you very much!)