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!

I’ve been working with the Drupal community on design projects for coming up to 12 months now – a splash in the ocean compared to many in the Drupal community but long enough to get a feel for how things work.

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)

Just a very quick post to let you that I recently created a Ning community to allow designers and user experience people who are working in (or interested in working in) Open Source and Free Software communities to share their experiences, their projects, their questions and their mental health breakdowns!

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.