Tag: drupal.org

Drupal.org update – staging site

Leisa Reichelt3 Comments

Over the last few months of last year you have have seen or, hopefully, engaged with the project to redesign the Drupal.org website.

It’s been a while since we’ve posted an update, but I’m really excited to say that despite the quiet here, the Drupal community have been busy working on the new site and it is really starting to come together beautifully.

Want to check it out? You can find it over on the staging server at staging.dosprint.org – the username and password are “demo” (not sure exactly why it’s protected, but, nevermind.

There’s still lots of work to do, but we’re really happy with how it is looking and really impressed that the community has been able to pull together and get so far with the work so quickly – well done all! We look forward to seeing it get closer to going live.

10 Social Skills for Community Designers (things we learned from the drupal.org project)

Leisa Reichelt6 Comments

It was pretty obvious from the outset that we’d need some design and UX skills to get us from one end of the Drupal.org redesign project to the other. It was less obvious how important our ‘social’ skills would be – and unsurprisingly, we learned a lot about good and bad ways to share the design process with a community along the way.

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.

design is no place for democracy (things we learned from the drupal.org project)

Leisa Reichelt9 Comments

Continuing in the series of ‘Things we learned from the Drupal.org project‘, this post actually starts off in the comments of the last post (design by committee vs design by community) where Keith picked me up on the statement that design should never be democratic and asked ‘Could it be? Or at least closer? And how to do that?’

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.