The Economist/Drupal Project – An introduction

Economist/Drupal – Intro to the Publishing Tools Project from Leisa on Vimeo.

Some of you may know that The Economist is in the process of moving their web content management over to Drupal and I am really excited to be joining the team working on the implementation of these publishing tools over the coming months – my mission is to wrangle the Drupal6 interface such that journalists will be able to spend more time doing what they love to do – chasing and writing stories – and less time doing what currently drives them mad – dealing with content publishing tools.

There are a few reasons that I’m excited about this project:

  1. it’s The Economist! – it’s a company full of clever people writing thoughtful, well researched material
  2. it’s Drupal! – also full of clever, thoughtful people
  3. it’s a really logical progression from all the work that we’ve been doing on d7ux throughout the year which has really been focused on transforming the Drupal admin interface to be more friendly to content producers
  4. it’s a big deal – getting this right is really important to The Economist being able to realise their potential and ambition in the online space
  5. it’s Agile – we’re doing SCRUM in 1 week iterations with an experienced scrum master and even a scrum master master! I am a big fan of well run agile and always looking for opportunities to experience design working well in Agile projects
  6. it’s end user focussed – each one week iteration includes user research/design evaluation (ah, the luxury of known and easily accessible end users)
  7. we’re sharing the process – when The Economist signed on with Drupal the community and open source philosophy was a big part of this decision. We think this is a great opportunity to contribute a case study and some more exposed design methodology back to the community, along the lines of what we’ve done with the D7UX project, so I’m going to be sharing our work on the project here in the coming weeks and months (if you’re interested!)

To kick off the sharing process, I asked Kerrie Lapworth, Production Manager, and Barney Southin, Managing Editor of Economist.com to give you an introduction to the project in the video above, and I look forward to sharing more with you as we move forward!

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

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.

Heathrow Terminal 5 – Another rant about respecting conventions

This seems to be my theme at the moment. Respect conventions.

Respecting conventions doesn’t mean that you have to slavishly follow them, that would be boring and unnecessary, BUT if you *are* going to break with convention then make sure it is very well sign posted, otherwise people will make mistakes.

I give you terminal 5 at Heathrow. 

Firstly a quick question – how long before an international flight do you need to get to the airport? 

The vast majority of people would say that the conservative answer is 2 hours but they don’t usually give it quite that long. 

Another quick question – how long before a flight to a European destination do you need to get to Heathrow? 

Again, most people will give you an answer around the 1 hour mark.

Now… you may already know this, but if you want to fly from London Heathrow Terminal 5 to Istanbul in Turkey (as I did the other day – yes the weather is beautiful, thank you!) they want you to get there not one, not two, but THREE hours before your flight.

We arrived an hour before our flight the other day and were severely reprimanded and had to be given ‘permission’ to proceed from the check in desk to try to get our flight. Fortunately (for us) the entire security software system crashed and massive queues meant that most flights (including ours) were delayed and we made our flight with plenty of time to spare.

So, given that getting to the airport 3 hours before the flight is apparently a big deal for BA, and given that T5 is relatively new, and given that in all my years of international flights, I’ve never been expected to be anywhere any earlier than 2 hours before the flight, you might expect that BA would make a big song and dance about this 3 hour requirement.

You’d be wrong.

They *do* make a big song and dance about the fact that we were leaving from T5 and that T5 is a new terminal. I definitely knew that because they advised me at almost every interaction I had with them regarding this flight (and these days there are quite a few touchpoints between purchasing the ticket and boarding the flight). But what did they tell me about time?

This is an excerpt from the email they sent me one week before the flight, specifically to help me to prepare for my upcoming flight:

IMPORTANT: For flights departing from Terminal 5, you must pass through ticket presentation and security at least 35 minutes before the flight departs. For other important information about passport, visa and UK domestic flight security checks, please visit ba.com/t5information.

So, honestly. Do they *really* expect me to turn up 3 hours early when this is the information they give me.

Perhaps they do, but I can tell you that a good portion of the passengers for the Istanbul flight were stuck in the security queue with us, having arrived much later than 3 hours before. And I doubt that it was because they were being naughty travelers, or that they liked the adrenaline rush of almost missing a flight. They just assumed, as we did, that turning up an hour before a flight from London to somewhere in Europe was the right thing to do, because that’s what we’ve done many times before.

This is what we do as humans. We make assumptions based on past experience and if we think we *know* how something works we don’t bother investigating it in detail, because we could spend our time and energy investigating things we think are new and interesting.

If people are making assumptions about your product, service or interface design and you’re *not* following the conventional approach, make sure whatever you’re doing differently is very clearly signposted. And then signposted again. Otherwise mistakes will happen.

And a customer who is making a mistake is very rarely a happy customer.

(disclaimer – yes, yes. I know that technical Istanbul is both European and Asian, doesn’t really make a difference to the discussion tho’)

Thoughtless design is going to cost me money… (or, why you shouldn’t ignore conventions)

BT Aqua Phone

Here is a new phone we got the other day. It’s our landline phone. Pretty cute huh? It’s called the Aqua by BT. Don’t buy it. I paid about £100 for a set of these phones. They are going to cost me a lot more than that in no time.

Here’s the thing. How do you end a call on a slide phone (which is what these are)? Simple – you close the slide, right? Well – yes, on every other slide phone that I’ve ever encountered, but not on this phone. Closing the slide does nothing… except closing the slide. So, when I went to make a call last night I discovered that, in fact, a call was still in progress. A call to a mobile phone, that had been connected for 8 hours. Ouch. I am *dreading* seeing this months phone bill because this isn’t the first time we’ve made this mistake. Although, this is probably the worst example.

We keep making this mistake because the slide-to-end-call convention is such a strong part of our model of how a slide phone works. We will keep making this mistake – despite the fact that we will be punished, seriously, by our telco.

As cute as these phones are, they’re going to be returned very soon because the experience of using them is so broken.

Moral to the story – if you’re designing something that has existing conventions associated with it – ignore them at your peril. Otherwise you’ll end up designing something that sucks as badly as this phone. And we don’t want that, do we.

End of rant.