Having been a vocal critic of the UK UPA in the past (by which I mean the organisation and it’s activities over the past five years not the current or recently past committee), I was really pleased to be invited to facilitate a workshop or two at their March event ‘Crowdsourcing the future of the UK UPA’.

There were a wide range of workshops held that evening, the one I was facilitating was focused on gathering and prioritising concepts that the UK UPA could act on which would make it feel like a professional organisation that we felt more aligned with and wanted more to be a part of. There were two workshops and the participants included UPA stalwarts and newbies, UXers and ergonomists, people from London and beyond.

The workshop used an incredibly rapid fire KJ Technique formed of individually listing items relating to how engaging the UK UPA was/was not for us and why that was so, followed by a quick post up and affinity sort, dot vote for issues we felt most strongly about.

Both workshops were characterised by a mixture of frustration and an energetic desire to be more involved and for the UK UPA to continue to grow and be an influential voice and resource for people who are currently active or interested in usability.

Once we aggregated the issues that most resonated across the two groups, the following priorities emerged:

1. Let us contribute: It was noted that the activity that the UK UPA is able to achieve is limited by the time that the committed yet otherwise busy committee members are able to contribute. There was an almost universal desire for members to be able to contribute meaningfully – whether by contributing content, updating the website, setting up Special Interest Groups that could hold their own events, and many other ways.

This requires the UPA giving up a little control – the current model of ‘tell us you want to help and we’ll delegate something to you’ sucks the enthusiasm and motivation out of even the most committed UPA fan. The net benefit would be a much more active association achieving a lot more for and with it’s membership, and a greater sense of involvement and community amongst the membership.

2. Teaching people who are new to usability: there was a general perception that the UPA could play a big role in educating people about what usability is, what usability work entails and why this might be a rewarding career option for young people and career changers. There was a particular passion for outreach into schools but also for providing tools to help educate colleagues with other specialties.

3. Have an opinion: participants also expressed the desire the the UPA have an authoritative voice on matters relating to usability, particularly high profile and particularly contentious issues. People wanted to be able to turn to the UPA to see what they thought about things.

4. Different event formats: participants also expressed the desire to mix up the event formats a little so there was less ‘lecturing’ and  more participation – debates, design jams, social events were suggested as options. Special Interest Groups were also mentioned in both workshops.

5. Learning more by sharing our experience: The ability to talk to each other, as members of the UPA and attendees at the events was something that participants would value – both online and offline. People wanted to be able to ‘find each other’ online after an event and continue conversations. An emphasis of events and content that showed real practice was also valued.

6. More friendly: Some participants noted that attending the events could be quite scary and intimidating and that more could be done to help alleviate this, also to help facilitate networking between participants. Some participants noted that they had attended several UPA events but not actually made any more connections with usability professionals as a result. (Related to points 4 and 5 above)

7. Who is the UPA? Participants wanted the UPA to more clearly articulate the position it wanted to occupy with our profession and the role it wanted to play and consequently, what our expectations should be. Development of a clear ‘value proposition’ or mission statement for the association.

8. More than just UX As a part of her introduction to the evening Chandra Harrison, current president of the UKUPA went to some lengths to make it clear to us that the UPA is about more than just usability. She may actually have gone so far as to provide the value proposition that people were looking for (ref: point 7 above) when she talked about the UPA being the organisation that brings together people from across all kinds of industries and professions who have an interest in making all kinds of things easier and better to use.

As it happens, participants (particularly in one group) found this a very appealing proposition and wished that they actually saw more content from across these various professions/practices as a part of the events program, more participation from people outside of UX at the events and more content helping us to understand the similarities and differences that are experienced across these audiences.

What’s next?

Another thing that Chandra made very clear in her introduction was that the committee are very time poor and already working very hard on projects for the UPA and that – although they were pleased to be holding this event and inviting ideas – they were not able to commit in any way to moving forward on any of the points that came out of the event. I understand from talking to members of the committee that many of the issues raised above are in the process of being tackled right now and, as it happens, by addressing the first one on this list, this problem actually starts to go away a little (although, no doubt, it also introduces a few more challenges).

Attending another UPA meeting confirmed for me though that actually achieving these objectives is going to require more than just a series of committee led initiatives, it’s going to require significant cultural change.

I’m optimistic that the very fact that events like this can take place under the auspices of the UPA is reason for us to have hope.

Why bother? Why do I care?

You may not identify as a usability professional. I don’t either. But we’re not the only ones who get a say in this. As long as other people look at what you do and call it usability (and you know a lot of people do), then this is our professional association.

Call yourself what you will, the way the UPA conducts it self is a reflection on anyone who rightfully or wrongfully gets lumped under the usability banner.

As long as this is the case, I want an association that I can be proud of. That demonstrates good usability practice in the way it presents itself online, that doesn’t feel completely out of touch with contemporary practice – UX, Ergonomics, whatever else you do that is affiliated with usability. I have enough on my plate trying to fight the good fight with people who don’t know any better, I should be able to count on the UPA to support me in this, not to undermine me.

So, this means that I’ll be critical. Constructively so wherever I can.

But it also means that if you want me to help out – and not just as someone you can delegate some tasks to, but on something that can actually properly make use of my experience, passion and abilities – then the UPA is welcome to call on me. As they did last week.

I hope you care too. And I hope the UPA can do exactly what it apparently wants to do – bring together people from all different professional circumstances who care about usability so we can learn more and do better and make this a better world to live in.

And on that evangelical note… why not go check out some more photos from the crowdsourcing night.

Having been a relatively vocal critic of the UK-UPA and some of their current activities, I would hate for it to be said that all I do is snipe from the sidelines. I do have some suggestions as to how the UPA can address this issue, but it will take significantly more than 140 characters.

I think that focussing on the lack of members voting in these committee elections might be totally missing the point. Here is a classis situation where we’re focussing on tactical problems when, actually the issue is strategic.

What does the UKUPA do? A quick scan of their current website tells you this

‘UKUPA brings together UK professionals from the design, technology and research communities who share a vision of creating compelling technology that meets users’ needs and abilities.’

Blah blah blah – what on earth does that actually mean? According to the predominant content on their current website it seems to mean they do job listings. And very little design.

But wait – the UKUPA are in the process of (very slowly) launching a new website. Perhaps it will give us more information about what they do?

Why, yes it does – it tells us that they have a committee, and they vote.

And, yes they certainly do vote. A lot.

A quick scan of the discussion on twitter involving UKUPA will show you that pretty much all they’ve been talking about for the past few months is voting for committee positions.

Now, clearly *some* people are interested in the committee and who is on it but I think the (surprisingly small) membership may be sending a big message – shut up about your committee already. For every one person that’s on the committee there are dozens who are not. Making such a big deal of your committee is not really a particularly inclusive strategy. It certainly doesn’t make me feel warm and fuzzy about the UPA. It makes me feel like Not A Committee Member.

The very fact that it *has* a committee, to my mind at least, makes the UKUPA seem dated – many of the great things happening on the UX scene at the moment are grass roots initiatives that are so busy getting stuff done that the idea of a committee is ludicrous. Let alone a committee of 8 people!

That, combined with the fact that the name of the organisation centres on the term ‘usability’ I think is indicative of the problem you’re facing – relevance. What are you offering the UX profession that is worth handing over a membership fee? Do you really need a committee? If so, what are they actually doing?

You may well have good answers to all of these questions but these are not being well communicated. Spend time answering these questions and less time dreaming up prizes to coerce people to vote for a committee they probably don’t really want.

As I write this I am conscious of four things:

1. the committee is very much a part of the UPA’s culture
2. The UK UPA is part of a global UPA machine
3. the UK UPA does provide valuable services to the UX community in the UK – in particular, the events they run each month are generally very relevant and well attended and provide a great service to the community.
4. the UK UPA currently has 300+ members.

If we were running the UKUPA, what could we do with this information?

Here’s what I’d be doing.

Firstly, look at your member data, talk to your members. Find out from people:

• how long have they been members? Are lots of new people joining up or are most people long term members?
• why are people joining? are they looking to validate themselves in the profession by showing they are ‘members of the Usability Professionals Association’ or do they want discounts at events?
• why are people not leaving? Can they not be bothered cancelling the standing order or do they feel that they are getting value from their membership? if so, what do they value?
• why are people leaving? what are you not delivering that they want?
• what do the members think the UPA could be doing better? What do they want the UPA to do for them?

Do NOT do this in a survey.

Secondly, look at your value proposition, branding and positioning

• find out what image the UK UPA is projecting and ask whether it’s the right one. Talk to people who aren’t in the UPA, let them be critical (stop being so defensive)
• think seriously about changing your name. ‘Usability’ isn’t helping you now and it’s not going to get any better as time goes on. (Yes, of course I know you’re part of the global UPA – that’s a whole other issue)
• think about what value you’re providing to the UX profession and communicate that clearly. Talk much more about that on your website/twitter etc. and much less about the committee
• re-think the whole committee thing – why do you have so many committee positions? really – why? who is it really serving?
• spend less time organising elections and more time organising mentoring (not that I want to pre-suppose what you might find out when you’re doing your customer research)

Finally, deliver content and communications that match with an updated value proposition and update the website design so that it communicates those values effectively- both in content and quality of design.

As a general rule, the events that the UKUPA runs are excellent examples of content that is desired by the UX profession – that’s why the people vote with their feet and attend these events. I’m sure I’m not the only one who feels the disconnect between the success and relevance of these events and the rest of the UK UPA machine?

As friends and colleagues of mine have put themselves up for committee positions in the UPA I’ve been tempted to become a member and support them with a vote but every time I consider it, I opt out.

From where I’m sitting, there’s no value to me professionally to align myself with an organisation that feels generally out of touch with the UX profession as a whole.

As a fellow event organiser, I know that UXers are crying out for more opportunities to come together and learn from each other – there are UX events every other week and every event seems to go to a waiting list – the need is there and the community is there.

I hope the UPA is willing to firstly admit there’s a problem and then be brave enough to UXify themselves. Then perhaps we ‘ll all become proud and active members. And then, when appropriate, respond to your calls to vote.

Until then, I’m out.

This year, I’ve been doing a bit of mentoring.

• Quite a number of my commercial assignments have had a mentoring ‘skew’ to them – rather than project work, my mission has been to try to impart as much of my knowledge as I can to a person or team.
• I’ve had the pleasure of working with interns on two of my projects this year (which is pretty unique and fortunate for a freelancer).
• I’ve been involved with the Information Architecture Institute’s mentoring scheme (you need to be a member and be able to remember your login)  which has given me the opportunity to compare notes with a number of up and coming UXers in the UK.

I’ve also been fortunate enough to be a ‘mentee’ (is that the opposite of mentor?) on several occasions – mostly when I’ve just straight out asked people if I can have some of their time to talk about a topic that’s on my mind and that I could use some extra perspective or experience on. In addition to this, there are dozens of people who unknowingly act as informal mentors to me as they share their experiences on Twitter, in books and at conferences.

What I’ve found really surprising is that in both the mentoring and mentee situation, I feel like I’ve been the one who has benefited.

Obviously, in the latter situation, I benefited from the kindness, experience and wisdom of those who were willing to do a Skype call with me (that’s the usual format of my mentee-engagements). It was where I was acting as the mentor that I was really surprised.

There’s a saying ‘if you can’t teach it, you don’t know it’. I’m not sure it’s entirely true but there is a special kind of knowing you get from having gone through the process of thinking about how to communicate what you know to someone else.

It does something to the way you know things – firstly, it makes you more aware of what you know, which is gratifying and confidence building. I think it also makes your knowledge feel more accessible and more valuable.

If the majority of the learning you’re doing these days is informal and self directed, you may find that mentoring is almost a way to give yourself a mark out of ten, an end of year exam, a sense that you have actually accomplished some learning and know a bit about what you’re talking about!

So, I want to take a moment to thank my mentors, and to ask you to think about how you might be able to participate as a mentor.

Do you have opportunities where you could invite an intern to work with you and gain invaluable experience? Can you offer some time to be a more formal ‘mentor’ to a UX newbie? In my experience, it can take as much or as little time as you want it to and the benefits to all involved are significant.

And yes, you probably do know enough to be a mentor – the best way to answer that nagging doubt is to give it a try. I bet you’ll be pleasantly surprised.

The ‘paid’ time I have left on the d7ux project is almost run out and I’m left feeling frustrated – not just by the work that I’d like to be able to continue to do on the Drupal 7 User Experience, but also by the great potential for building a critical mass of great designers and UX people in the Drupal community and the different types of activities that could spur this on, and the impact this could have on Drupal adoption and sustainability as an Open Source software project. So much opportunity, so little resource.

Despite the fact that I think there are probably a contingent within the Drupal community who are hoping that Mark & I are just going to go away once we stop getting paid for d7ux, the fact is that this is unlikely to happen any time soon. For various reasons and in various ways, I think we’re both kind of hooked on Drupal, or at least it’s amazing community.

Having said that, I know for myself it will be difficult to carve out any significant amount of time from the paid project work I’ll move onto and the demands joy of a family with a young child – I have long since given up on a social life!

At best, I hope to commit to spending a hour a day (or 5 hours a week) on Drupal post the official d7ux project. This is *far* less than others commit for ‘free’ each week but much more than many are able to consider committing.

(Having said that, have you seen that Matt Webb video I posted just before this post? What are you doing with your 100hrs?)

Here’s the thing… I really want to make those 5hrs a week count. At the moment, the logical place to spend those hours is bickering in the issue queue. Whilst some time does definitely need to be spent there, I think for the Design & UX community to spend too great a proportion of their time battling out grassfire by grassfire is not productive use of our time… but what can we do with just 5hrs?

I think the answer lies in crowdsourcing our time around big projects. Creating and managing projects that lots and lots of people can contribute an hour here and there to, and yet great and coherent value is created. I have some thoughts what kind of projects these might be:

• creating/maintaining/applying an design pattern library
• consulting with developers who are in the early stages of developing a module that has UI elements and providing them with assistance *before* they code a UI
• concentrated work on known difficult interfaces that should be easier. (edited to delete unnecessary snarky remark at a specific module)
• more microprojects!but my absolute favourite pet project is:
• crowdsourced usability testing video library: create a library of video snippets of usability testing conducted by people around the world and tagged so that they can be used as a datasource to support design decision making AND to be pulled out over and over and over again to help maintain awareness of people-who-use-Drupal-who-are-not-us

Each of these projects (and I bet there are dozens more just as good or better!) provide:

• ways for designers and UX people to contribute in a rewarding way to the Drupal community (contributing to the issue queue is v important yes, but can at times be incredibly frustrating and demoralising)
• opportunities for new people to contribute to the community from their first interaction (rather than being smacked on the nose, told that everything has already been thought of and given a list of issues to read before proceeding),

Growing a vibrant design & UX community within the Drupal community in the long term and allowing Drupal to benefit from that (beyond finally starting to see some gorgeous looking sites that are Drupal-powered) is going to require some nuturing and creativity.

It needs someone to create and faciliate these ‘crowdsourced’ efforts and to promote them with in the Drupal community and within the broader Design/UX community.

But there is one big problem – in order to provide the framework for hundreds of people to start contributing their 5hrs a week, you need someone setting up and managing said framework. I think that this role is a Design Community Manager, I think it needs to be a paid role, and I think it should probably be about 2 days/wk.

So the three questions are:

• this is something pretty different for the Drupal community… is this something we’re willing to try?
• who’s going to sponsor this initiative, as in, put up the cash (and no doubt win the love and respect of both the Drupal and Design communities)
• who is the guy/gal for the job (but let’s answer the first two before we get into this. Be assured there are some great candidates)

If this sounds like something you might be interested in, come join us here: http://www.designintheopen.org/

I’ve been known to say in public places that designing with a community is nothing like design by committee. And, certainly that’s been my experience to date. Not to say that designing with a community is painless either! These days I feel as though I have a vast swathe of constantly raw virtual flesh put out for cutting. Checking email is a lot more scary now than ever before!

Recently we’ve been getting some feedback from within the Drupal community that our approach is not open enough. The designer in me finds this devastating – by ‘designer’ standard I think we’re already being profoundly open in terms of both the way that we’re working (our practice) and also what we’re designing (our output). But, by open source standards, I completely understand the feedback. Angie Byron (@webchick) recently left a comment on an earlier post that describes some of the issues that are emerging. I’ll quote a little from that now so you can get the picture:

On something like groups.drupal.org, everyone can be a content creator and make new posts which are equivalent to everyone else’s posts in “primaryness.” While we have tools like “sticky posts” to draw attention to particularly important things, everything else is open to everyone and has a real collaborative (if chaotic) vibe. This is more like “the Drupal community show, with special guests Mark and Leisa.”….

…. But yet, the current model feels to certain members of the community like “shout it out into the darkness and hope someone’s listening” collaboration paradigm, when they’re used to much more direct interaction like pinging webchick on IRC and saying “Hey! I’m upset about something. Let’s talk.”

I can’t help but preface my response by saying that I’m usually available for hours at a time on IRC to Drupalers and more than happy to be pinged with this exact message, although having said that, I’m no @webchick in the Drupal community so completely understand why this hasn’t happened as much as it might.

I do want to share back some of my thoughts on ‘equivalence’ and ‘the Mark & Leisa show’, as the way that this is playing out is not entirely accidental and there is a certain amount of ‘design’ to the way that we are communicating within and outside of the Drupal community (having said that, it is a constantly evolving design and you are probably being party to a big evolution right now!)

Top Down/Bottom Up

Another thing I’ve been known to say in public places is that design projects like D7UX and the Drupal.org redesign project aren’t the kind of projects that can be initiated from within a community, that is organically and ‘bottom up’. I think it’s true. Look at the efforts of the hardworking usability team within the Drupal community – there are some very smart people there and they are working terrifically hard and making a big effort to improve the users experience of Drupal – one issue at a time (using the issue queue infrastructure typical to opensource development). They have certainly taken big steps to improve Drupal’s usability, but (and of course, this is open to dispute) I believe there is a fairly profound change that needs to come about in order for Drupal to achieve what I understand it would like to achieve – that is to make it’s powerful tools more available to people with less or different or, ideally, even no web development skills.

I wouldn’t like to say it was *impossible* for this to come about from within a large community, but I think it is self-evident that it is highly unlikely. It requires a different type of methodology to what is found in open source communities at the moment for this kind of change to be designed, at least, within any kind of useful timeframe.

We need to find a way for a good design methodology to work in an open source environment. That’s one great big hairy challenge.

The Open Design Triangle

Back in my ‘agency’ days, we used to use a diagram of a triangle to try to explain to our clients some of the facts of life around features and cost and time and quality, it is quite like the one I’ve included above except the three corners said ‘Time/Quality/Cost’ and the idea was that the client could choose to move two of the corners but that one had to remain fixed. The triangle couldn’t get any bigger but it could change shape.

I’ve been thinking about this model recently in terms of the way we’re working on the Drupal project, and for open source designing in general, and I think a similar principle applies, except that the corners are now labeled

1. speed/time
2. quality and
3. inclusivity/openness’.

In *this* project time also equates to cost (as we are being paid to work on the D7UX project) but obviously this is not always the case. And as with the commercial model, you can move any two of these corners but not all three.

Time

Time is a massive issue for us in this project. I would estimate that at the moment we are spending at least 65% of our ‘paid’ time just ‘communicating’ on this project and just 35% actually designing. That’s scary for us – there is a lot to design and not a whole lot of time to do it. We would LOVE to be spending more time designing, but as I’ve said before, it’s fruitless and foolish to do so in isolation.

On top of this ‘paid’ time, both Mark and myself spend a lot of our own time on this project and in that time we are almost invariably blogging or in IRC or responding to email communicate we’re receiving on the project. I’d estimate for myself that I’m probably contributing an extra 20-25% of time beyond what I’m being paid to do on this project. That doesn’t make me any great hero, I know, but that’s the current landscape.

Quality/Integrity

I’ve written in the past that I believe that design is no place for democracy. Open design is amazing because you can have so much feedback and insight piped in throughout the process, and as I hope is evident, we are doing everything we can to encourage this engagement in our process from the outset (where it is arguably most important).

However, design decisions at a system level (like the ones we’re working on at the moment) shouldn’t be made issue by issue and by consensus – not if you want a great design, a great user experience. A good design comes from a strong, unified vision that is articulated by experienced designers. The power of this clear design vision is that, going forward when design decisions do move down into issue queues (which, over time, they will), we are all able to discuss design issues and make design decisions more articulately and more effectively because of the foundations that have been laid, through the ground work that we are doing right now.

‘The Mark & Leisa Show with Special Guests’

As I understand it, there are three main reasons why this impression is being created. Let’s look at them one at a time.

1. We’re constantly shouting about our work
   Especially in the early stages of this project we are spending a lot of time effectively saying ‘look at us, look what we’re doing’. Don’t worry, it feels pretty uncomfortable for us to be doing this, but if we want this project to succeed then we have to do it. The greatest risk to this project is that we don’t engage the Drupal community (engaging ‘outsiders’ is also very important but nowhere near the same level of risk), and that we don’t engage them early enough in the process when the big decisions are being made. There is no way that we can just send out one message and know that we’ve reached everyone. We have to shout, as loudly as we can and often. I don’t think we have a choice if we want this project to succeed.
2. We’re using video
   We chose to use video for a few reasons, partly because ‘show and tell’ is often easier for people to consume than text, and also partly because we want to come across as human beings with feelings (in the hope that people will consider this as they’re drafting their responses).
3. We don’t often get ‘conversational’ around the feedback we receive
   We are receiving feedback and insight from lots of different people in lots of different places – we’re doing this so that we can maximise the level of engagement and involvement that we get with the project. Very often we stay a little removed from the feedback that is coming in, for a couple of reasons.

• Firstly, we don’t want to get involved too early – we learned from our work on the Drupal.org project that if we stick our noses in too early we can skew the direction of the discussion, and we don’t want to do that. We love it when conversations evolve amongst the community and we watch very closely how those play out. We need to give a thread time to evolve to see what trends emerge.
• Secondly, time. See above.

Consensus Driven Design?

The way that we are currently engaging with the community is very different to the way the community currently gathers to discuss and resolve issues – which is very much consensus driven.

I cannot say often or loudly enough how much we crave communication with the Drupal community on this project, but in order for us to do our job well, we need to engage in a somewhat different way.

We can’t argue every single point at the moment that it is raised. Our process doesn’t work that way (we don’t know anywhere near all the answers at the moment, we’re still devising the strategy to make the questions that we’ll then set about answering, with the assistance of the community). Also, see ‘time’ above.

Having said that, I think that we are striving to work in a consensus driven way. We’re doing this by creating larger artifacts that we can gain consensus around. Things like our Experience Strategy, our Audience Matrix, our Design Principles for example, are ways that the community can gather around the work we are doing and we can get some kind of concensus about the best way to define our strategy.

In the recent release of our Initial Concepts, we specifically pulled out four artefacts for discussion, with the aim of gaining concensus around them before moving forward (being the header, the overlay approach, the inline editing and the ‘direct manipulation’ tool).

It may not look exactly like the way that concensus driven development works, but the principle still holds… at least, that’s the outcome we’re trying to achieve, within the contraints of time and quality (see above).

Where to now?

There is no right or wrong way to do this, yet. The work we’re doing on this project will, hopefully, be used as reference for future projects and I’m sure they’ll look at some of the things we’ve done and say – great! and others they’ll look at and say – rubbish! We’ll probably do this ourselves before the end is reached!

I’d  love to find a way to more effectively synthesis all the feedback we’re receiving and to share that in a way that everyone can consume more readily. Again, I’m not sure exactly how to go about that yet, but I am fairly sure it’s not to just talk in one place.

We are listening. I think we need better ways to show that we’re listening. I’m not sure what those are yet. I’m going to think on that some more and I hope you do too and let me know what you come up with.

A final note on Fear
I wanted to wrap by sharing another part of WebChick’s comment, which resonated deeply with me.

some feel like they don’t have expertise in this domain and are really intimidated to jump into the fray. They’re scared to say anything bad because they’re convinced that their opinions will get immediately shut down, and that they’ll offend you guys.

So much of this project and this way of working is about fear. I know I feel terrified by this project almost every day I work on it, for so many reasons. And fear doesn’t often create a great environment for communication. I need to think about this some more (and no doubt have a whole other blog post brewing), but I thought it was worth throwing that out for your consideration.

Thanks for taking the time to read all of this. Be brave. I look forward to hearing your thoughts.

Here’s a few ‘social skills’ we learned:

1. you need to take responsibility for the way that your community behaves: it’s not in any way productive to associate the way that a community is responding to you by blaming the community or even the individuals in it. If you respond that way you’ll never be able to improve the situation. As with every relationship, the only person you can change is yourself. If you’re getting a bad vibe back, the first thing you should do is check your tone and content – what are you saying? how are you saying it? can YOU improve the way you’re communicating. The onus is on YOU to get it right.
2. tokenistic involvement is a waste of time: if you don’t really care what the community has to say on a subject, don’t ask them. If you do want their input, take the time to design a way for them to interact with you in a way that gets the best from them. Be creative, put a bit of thought into it. Avoid polls and and use surveys with care – you might feel as though you’re involving the community because you have ‘numbers’, but do you have real involvement. Ask yourself what the community knows that you can benefit from, then consider the best way to help them share that knowledge and experience with you.
3. ask for specific feedback: if you want to get good feedback from your community, tell them what you want feedback on. We *didn’t* do this much during the Drupal.org redesign – instead I was trying to keep it ‘neutral’ and not influence what and how people gave us feedback – we learned that by asking for specific direction we not only got excellent feedback on the issues we highlighted, but others as well. Without direction the discussion tended to be less helpful and was more likely to get personal (not in a good way!) This will also help you to get feedback on more than just the homepage.
4. give examples: if you want a particular kind of response from the community, it is important to provide an example for them to follow and really great instructions to participate. For example, when we were doing the ‘crowdsourced wireframing’ I included a picture of one of my not very elegant wireframes so that people had a sense that their submissions didn’t have to look ‘designed’. If there are instructions to participate, make sure these are as clear as possible. Then make them even clearer.
5. wait… wait… wait… engage! once you post something for feedback, go away and make a snack and do NOT get involved in the conversation immediately. This is probably the most difficult rule to follow and one that Mark and I had to coach each other on (and occasionally police! – step away from the computer!) throughout the project. If you dive in and start responding to the first few comments, what you unintentially do is skew and retard the conversation. Rather than exploring a broad range of issues and allowing key points to gradually evolve, the discussion focusses on whichever points you have responded to, everyone starts to focus on those few issues. The richness of the feedback is lost because you dive into detail too quickly. Rather, wait until at least a half dozen people have posted (or 12hrs has elapsed, whichever is soonest) and see what the trends are in the feedback, then start getting more involved in the conversation.
6. admit errors quickly: the only exception to the rule above is if you’ve stuffed up. In this circumstance you should admit the mistake quickly so that the conversation doesn’t focus on your error. In one iteration of our redesign we accidentally omitted a very important call to action (I know… how could we?!) As you can imagine, that oversight dominated the feedback we received and by the time we responded (way too late!) things were getting a little frenzied. We should have been keeping a closer eye on the situation and stepped in as soon as we realised our mistake.
7. don’t go dark, but don’t respond to everything: there is a balance in the correct volume of response that you need to aim for. It is really important that you don’t disappear (even if you get really busy) – the community needs to know that you are there and that you are listening. On the other hand, don’t feel as though you need to respond to every comment that is posted – unless you are only getting a handful of responses. As a rule, aim to respond to trends and issues not individual comments. Feel free to occasionally respond with a simple ‘I’m here and listening, I don’t have the answer yet’.
8. lead by example: it’s an oldy but a goody - interact with the community in the way that you would like them to interact with you. Be polite and respectful. Others rudeness or bad behaviour is no excuse for you to let loose. It’s up to you to set and maintain the standard of communication you want the community to engage in.
9. assume good faith: it’s a general rule of interacting with others online, but keep it at front of mind especially when you’re putting your own work out there for review and, therefore, more likely to feel a little defensive. Text is a tricky medium for communication – people might sound like they’re being mean or overly critical or agressive when they’re just not great at communicating (or you’re feeling defensive and read everything as an attack!), or being a little lazy with their words, or created unintentional meaning. Always assume that people are trying to be friendly and constructive and helpful if there is any room for doubt at all. In fact, even when it is evident that they *are* being a little mean, it is often useful to deploy this rule – play dumb and be extra nice. Don’t waste time fighting or being a smart ass, or just being mean, or engaging with others who are. Focus on the task at hand – doing good design.
10. be a human: I think this is the absolute most important thing – don’t assume a Voice of God, don’t pretend to be infallible or to know everything. Don’t feel as though you have to use very big words all the time. Swear occasionally (if your community is ok with that). Admit that you are nervous (or outright terrified, if that’s the case). All of this is allowed and encouraged. Communities are made up of people, of human beings and you are but one of them. Use your real voice and speak honestly. Be open.

Ah, democracy. It is a beautiful theory, but only – as with so many things – when applied correctly. Democracy may be great for deciding on a government, it may be great for Pop Idol (hrm..?) there may be other places it is great and noble… but design just isn’t one of those places.

When designing with a community what you should be aiming for is participation not democracy. Make your design process as open as possible, but don’t be fooled into thinking that because people ‘voted’ for a particular design, that is is the best decision, or even a good one. It’s probably not.

There are two key reasons that I believe this to be true:

1. Good user experience is hard to evaluate when not in use – when you give people a screengrab or even a prototype to evaluate, people will tend look at things from a visual design perspective (highly subjective), and often a ‘heuristic’ perspective (usability conventions, best practice, what ‘users’ do and like etc.).These perspectives are valid and interesting, up to a point – but they come nowhere near being as valuable as the observation of a designer, or actually observing someone performing tasks that they would do every day using your design and seeing how it works for them. I’d give that trumps over popular opinion any day.By putting a design out there and asking people for their feedback, you are actually giving them a really difficult task. It’s hard enough for those of us who do it professionally (and there’s plenty of research to show that our opinions can vary wildly) – it’s not really fair to expect your community to be able to make a good decision about whether or not a design will work well based on just taking a look or clicking through a prototype.
2. Your community are domain experts, not design experts – the best thing your community can do for you is tell you what you need to know in order to design well for them. Most of the time, they are not designers. They don’t have design training. Why are we asking them to do design work?If I could find my copy of Bill Buxton’s Sketching User Experience (which I have conveniently misplaced on the day of London UX Bookclub, d’oh!) I’d find the part in it where he talks about how ‘reading’ design, interpreting sketches, is actually as much of a design skill as doing the design in the first place – it’s just one we don’t talk about and don’t place any value on. Part of the reason designers often snort at the feedback given to them by clients (or community members) is because of a lack of design literacy in their feedback. Well, of course. They’re not designers.

Your mission when designing with community is to facilitate the community to make good design decisions by working with the information and insight they provide to give them good design and help them understand the design strategy and how and why it works.

Giving the community a true and meaningful voice in the design process is so much more empowering and respectful of them than letting them vote for which design they like the best. Letting a community choose a design by popular vote is, in my opinion, relinquishing your responsibilities as designer.

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!

(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!