Archive for 'planet drupal'

Designing for the wrong target audience (or why Drupal should be a developer tool and not a consumer product)

As you may know, I spent a few months this year working with Mark Boulton and the Drupal community to try to make Drupal 7 (their upcoming release) a Great User Experience. I’ve spent the past weeks reflecting on that experience and trying to understand what we learned from that project and with any luck this will be the first of several reflective posts.

It is all to easy to make excuses for why designing in an open source community can be tough. Certainly there are lots of communication challenges and we don’t necessarily have the right tools. Some people focus on the relationship between designers (minority) and developers (majority) in these communities – I think to do so is to focus on a symptom  of the problem and not the cause.

We faced many challenges with the D7UX project, but the greatest of all was to convince the community that the changes we were suggesting were actually going to result in an improvement to their project. There are many who steadfastly resisted our approach and who continue to do so.

It would be very easy to take this personally and to argue about the details of the way the design works (and I most definitely include Information Architecture when I say design). This would also be a fairly typical Drupal thing to do. Actually, I think almost all the issues stem from a much more fundamental place – defining the real purpose of Drupal and it’s real primary target audience.

From the very outset our goal with D7UX was to make Drupal more accessible to people outside of the Drupal community and less technical people – people who didn’t even know what PHP was let alone how to code it. Verity and Jeremy who emerged as part of this definition embody the target audience that the design work that Mark and I were doing in this project. This approach is representative of the goal to make Drupal more of a ‘product’ – an out of the box CMS solution that non-technical users can drive. This is key to the goal to increase the reach of Drupal, as Dries outlined in his keynote at the recent Drupalcon.

There is one big problem with this approach, particularly if it touches the very core of Drupal. The changes that are required to the interface to really achieve the goal that we were tasked with – to really make Drupal understandable to Verity & Jeremy has the consequence of making Drupal a less efficient and enjoyable place for Drupal developers to build cool stuff.

Drupal developers (and some designers!) who want to build cool things with Drupal are the core of the Drupal community. They are the people who make Drupal the incredibly vibrant community that it is. Without these people, Drupal becomes a shadow of it’s current self. These people are more than an important audience, they are the most important audience. What this audience wants is not Drupal as a product that Verity & Jeremy can use out of the box, they want a developer toolkit that gives them more and more flexibility and capability to build cool stuff, and to push Drupal way beyond the realms of a simple Content Management System.

And so we have this tension. Drupal as a ‘Consumer Product’ and Drupal as a ‘Developer Framework’. Currently, the official direction is that the project is going to attempt to be both. I think this is a serious problem.

The target audiences for each of these objectives are so far removed from each other in terms of their tasks & goals, their capabilities, their vocabulary, their priorities. An attempt to devise an interface to suit both will result in an outcome that I expect we’ll see in the release of Drupal 7 – that is a compromise to both parties. Verity is still going to need a lot of support to get anything done in Drupal 7. If Drupal 7 had been designed primarily as  developer tool, it would be a much more focussed and efficient tool for developers. As it is now, it is hopefully an improvement on Drupal 6, but certainly not the best that it could be for developers.

For Drupal to really succeed, a decision has to be made, and I think there is only one decision that can be made. Drupal 8 should be designed with developers as the primary target audience and the language, tools, interface should be designed to support them in their goals of building really amazing stuff using Drupal.

That doesn’t mean that there is not still a lot of work for the User Experience people in the Drupal community to do – there is still an enormous learning curve even for those new to Drupal who have great PHP and other technical skills. It’s going to be much easier to address that learning curve with a more finely targeted audience in mind – or more importantly, with the right target audience in mind.

So what of Verity & Jeremy? How will they ever come to know and love Drupal?

There are a number of ways that we can address the experience of non-technical users of Drupal and to ‘productise’ Drupal as a content management system. The most obvious is to design and develop an admin theme that is specifically targeted at these end users that can be applied by developers once the development work is done and the site is being handed over for administration.

I’m not sure where the incentive to design and develop this theme comes from (given that it doesn’t exist today it strikes me that there is a problem here incentive-wise).

There are also opportunities to be explored with installation profiles (see above though re: the fact that they don’t really exist now and no one seems motivated to work on them, where is the incentive?).

And, of course, we have the emergence of tools such as Buzzr from Lullabot and Gardens from Acquia, perhaps also products like Open Atrium from Development Seed can included in this list.

A tough decision but a necessary one

I know that for many people the idea of making a Drupal that Verity can love, making something that can actively compete from a UX perspective with the likes of Wordpress, is a grand aspiration. So it is, but unfortunately I also think it is the wrong aspiration for Drupal core.

The sooner we focus on the core target audience of Drupal core – the developers – and commit to making a user experience that supports them in their use of Drupal, the sooner we’ll really have actually achieved a really Great User Experience for Drupal.

If that is really our goal, then let’s get focussed, let’s re-write the design strategy and principles, and let’s take the work we’ve done already and refocus it more tightly on the community we know and love. Focussing on the strength of Drupal and then looking for new and innovative ways to create and motivate the Drupal community to do a better job of looking after our Verity’s and our Jeremy’s.

D7UX User Research & Usability Testing – Proposed Approach

The best way to a good end user experience is a program of iterative testing and design. There’s been quite a lot of design but not as much iteration as we’d have liked, so now is a good time to really kick off some testing of the D7 interface as it comes into existence so that we can potentially iterate it a little before it is set loose on the unsuspecting public.

In order to take best advantage of the enthusiasm within the community to participate in testing we should ensure that we are taking a generally consistent approach to the test process so that we can better compare our results and make decisions more easily. A way that anyone who wants to can conduct some tests and provide feedback, insight and recommendations, no matter where they are in the world, in a way that we can actually act upon.

Here are some initial thoughts on a framework for testing the D7 interface that can be adopted by anyone within or outside of the community and around the world.

Making use of previous usability test framework:

The Drupal Usability group conducted formal usability testing in Baltimore in 2009 (ref: http://drupal.org/usability-test-university-baltimore-community-solutions) which has informed much of the UX work that has been undertaken over recent months. It makes sense to capitalise on this previous effort as far as possible, not only to reduce workload at this point but also because it will provide a useful benchmark. There are some areas where it is appropriate to make some amendments to the approach taken in the Baltimore testing, these will be discussed below.

Target Audience/Recruitment:

As with the Baltimore approach, our testing should target two specific user groups who are important to achieving increased ‘reach’ for Drupal, and who have been at the heart of the D7UX design effort. Baltimore identified these groups as ‘Beginner’ and ‘Intermediate’. This assumes that every end user is at some point on the same Drupal learning curve, which our research has shown not to be the case – this is demonstrated in the example users identified in ‘Who Is D7UX for’ (http://www.d7ux.org/who-is-d7ux-for/), where the users Verity and Jeremy are described.

Verity would equate most closely to the ‘Beginner’ audience used in the Baltimore testing, however the description of ‘Beginners’ it was specified that these people have some development experience, and the script implies that their role may involved building a website using Drupal. Verity, on the other hand, is the recipient end user of a Drupal site who is then tasks with maintaining the content on that website. This is a very typical end user role for Drupal and one which we hope that Drupal 7 will do a much better job of supporting.

Jeremy, however is quite a good fit for the Intermediate audience group recruited in Baltimore, although again, development skills should not be required in order for him to successfully complete the tasks in his test script.

I propose that went we are recruiting people to participate in our user research we compare them to the Verity & Jeremy sketches and if they are similar, they are good matches for testing. Depending on which they match, we will then use a discussion guide and set of tasks tailored to their role and objectives.

Discussion Guide/Script:

The scenario presented in the Baltimore testing was essentially to build and/or manage content on ‘a website for a conference where users will post information about the conference like the schedule, speaker bios and local bars’. This is a great scenario and is suitable for both our Verity and our Jeremy participants and I suggest that we re-use this scenario, the content materials prepared to support the scenario and used in the test, and as far as possible, the script that was devised for the previous round of testing.

The existing beginner script is, I think, almost entirely suitable for the Verity role, and comprises the following tasks:

  • publish some information about the conference (to existing content types/sections of the site) taking content from a text file provided.
  • create a navigation link (if we leave anything out of this script, I think this might be it… not sure if this is a real Verity task… could be tho’)
  • change the look of your site, remove the logo at the top left
  • creating a new role (speaker) with additional permissions (suggest that perhaps rather than creating a new role, assigning users to a the speaker role might be more appropriate for Verity)
  • create a new page (schedule) and navigation to that page

The existing Intermediate script is also very suitable for Jeremy, and comprises the following tasks:

  • installing drupal
  • publishing some content about the conference to the site
  • creating navigation
  • creating a new role (speaker) with additional permissions
  • using taxonomy to categories ‘workshops’
  • using a block to highlight content on every page of the site
  • customising the URL of a particular page
  • allowing speaker role to use images in their content creation
  • set up site search

There may be some additional tasks that we want to include, however these scripts are already quite lengthy so perhaps it is best to prioritise tasks and we can iterate the script over time as more testing is completed, to increase task coverage.

Test Materials (What to test on)

I think this is the biggest challenge, especially in the case of Verity, and it’s not something for which I have an immediate solution.

Here’s the problem – it is not reasonable to expect Verity to be able to perform the tasks outlined above using a straight Garland Drupal website, and it is not a reasonably approximation to the reality of this end user.

Garland looks far to much like Drupal and far to little like a contemporary and designed website. It introduces a raft of challenges to understanding the interface that Verity would never have to address in using the Seven admin theme over the top of a professionally designed website.

We need a theme for testing, however simple, that looks like a proper, designed website. And, in the case of Verity, we need a little structure and content already in place on the website.

Now, there are dozens and dozens of Drupalcamp websites out there… is there some way we can get one of those approximated in Drupal 7 in a reasonably short timeframe?

Ideally, Jeremy will have a theme other than Garland as his default Drupal 7 theme also. But, for me, this is less problematic compared to Verity.

Help!

Reporting Findings & Making Decisions

Our testing needs to be video recorded (screencast) – I’ll be using Silverback (because it’s cheap and I use a Mac) but there are many other solutions out there. In order for our findings and recommendations to be agreed and accepted it is important that we’re all able to check back to the source.

There is a Drupal UX Group on Vimeo (http://vimeo.com/groups/drupalux) which seems like the logical place to post these videos (to avoid the 10 minute rule on YouTube if nothing else) and it also makes sense to utilise the existing drupalusability.org infrastructure for reporting findings although it will need to be reworked to allow for the ‘crowdsourced’ and iterative nature of this test approach.

Next Steps

Assuming we agree that this is a good way forward, then there are three key tasks that have to be completed:

a) we need to finalise scripts and make them available to people who wish to conduct testing
b) we need to resolve the issue re: a testing theme, and
c) we need to ensure that drupalusability.org is ready to receive feedback from multiple sources

I know that within the UK there are at least two groups who are keen to make a start on doing some testing before the end of September. It would be great to have this framework in place so that we can make the best possible use of their time and expertise, so, time (as ever) is of the essence.

What do you think? Sound good? Can you help?!

Economist/Drupal – Sprint 2 Demo (CRUD-in-place)

Drupal/Economist Project – Sprint 2 Demo from Leisa on Vimeo.

Today is Demo Day at The Economist, where all the various SCRUM teams will show and tell what they’ve achieved in their latest iteration. I thought I might see if I can get into the habit of pre-recording my demo so I can share it with you here and ask for feedback & advice! So, here we go!

In the past two iterations (this project runs on 1 week iterations) we’ve done a combination of research, design and testing the publishing tools that the editorials staff will use to administer what is known as the ‘Channel Index Pages’ – these are pages that you’d land on if you clicked something in the navigation that said, say, Business & Finance, or Science & Technology, and their job is to pull the most interesting current content to the top so that readers can access it more easily.

These pages are made up of a range of elements, most importantly for this demo are News Packages (consisting of a lead story and related stories/media files) and what is known as the Bloggy Chunk (an editable text area that section editors can freely input their own content, it is still very much a work in progress and is variously used as an aggregator for recent interesting stories that The Economist isn’t covering in depth or to highlight interesting reader comments, it may in the future show content from an RSS feed).

Although working within the SCRUM methodology, I am trying to take a systemwide approach to the design as far as possible, so there has been a whole range of questions that I’ve had to consider that aren’t strictly in the ’stories’ for our sprint (logging on, activating editing, for example), and similarly, I’ve tried to devise interaction approaches that will be reusable across the other parts of the system that we have yet to design rather than just customising the design approach to this individual problem set.

The design approach shown in this demo is still quite lo-fidelity and ‘broad brushstroke’, it will become much more precise over time, at the moment my priority is to try to work through and communicate the ideas as quickly as possible – giving me more time to explore a range of approaches, and to iterate approaches which has been very valuable.

So, if you have a moment and are so inclined, I’d really love to get your thoughts on the approach we’re taking so far. We’re also about to embark on starting some development work on this – to make sure we can build it in Drupal without too much difficulty – so if anyone has any guidance on how best to approach this, modules we should take a look at, anything else you think we might need to know, I’d love if you could share it here!

Look forward to hearing from you and thanks in advance!

(apologies to anyone who saw the first version of this blogpost with the screwy audio synching)

Economist/Drupal – Design Principles for CRUD-In-Place

I’m going to stop referring to what we’re doing as ‘edit in place’ because actually what we’re attempting to do is what is charmingly known as ‘CRUD’ in Content Management System (CMS) lingo, being Creating, Reading, Updating and Deleting content.

I’ve spent this morning reviewing a whole host of existing examples of ‘CRUD-in-place’ (thanks to the great examples that you provided in response to my previous post). I have to say, although there are quite a few examples out there, not very many of them are particularly inspiring… at least for my purposes.

I’ve posted up some screenshots and a few comments on Flickr that you’re welcome to add your thoughts to. As a summary I think that for this project we can absolutely draw the most inspiration from Flickr & 37 Signals (eg. BaseCamp) implementation of edit in place – mostly for their simplicity, which is the entire point of this exercise.

Many of the other examples offered huge amounts of flexibility which is, frankly, the complete opposite to what I want to offer here – we want to offer flexibility within a template (or perhaps templates) certainly not the ability to create templates on the fly (we don’t want to make people whose skills are editorial suddenly have to try to make good design/user experience decisions!).

Two other pet peeves that I’ve developed since I’ve been reviewing these interfaces are the overly liberal use of buttons when a simple text link would suffice, and throwing up a great hunk of a form that was obviously intended for a back end interface when a much more elegant ‘in place’ solution could have been achieved.

Now that I am trying to apply my learnings and inspiration to my particular design challenge I’m finding myself coming up with some design principles that I will probably add to over time and hope to use consistently throughout the system design. I’m going to start posting them here so I can keep them together and you can give me some feedback as we go!

Design Principles for CRUD-in-place

  1. Don’t map the interface to the technical architecture, map the interface to the tasks that users will want to perform. The user/interface shouldn’t have to care about the way that content is grouped in the back end. If I want to just edit the headline of a ‘news package’ I should be able to do that without having to see the form for the entire package. (Eg. fixing a typo in the headline, adjusting line length etc.)
  2. Show as few controls as possible and try to show them only when required. Particularly on the ‘index’ type pages I’m working on at the moment there will be lots of ‘bits’ that will be editable. Showing all of them will result in a hideously scrappy looking page. I’m rather tempted to use the BaseCamp approach and show the appropriate controls on hover, however I’m also concerned that we design an accessible experience, so we’ll need to think more about what we need to do to achieve this principle without sacrificing the experience for people with visual/mobility impairment.
  3. Where possible, choose a text link and not a button. See (2) above – text links are a much less intrusive element on the page and will help us to maintain a clean, simple interface. Obviously, there are some times where buttons are necessary, we won’t get silly with this.
  4. Provide Editorial Tools not Design Tools. The purpose of this interface is to allow editorial staff (writers and editors) to do their jobs well – their job is to craft, curate and communicate content to readers. These people are not designers and should not be asked to make design decisions. The flexibility they require is about selecting, grouping and prioritising content. The design work should be done within the page template and within that framework we provide appropriate editorial tools.

More to follow I’m sure, I’m just getting started. Feedback welcome!

Economist/Drupal – Complex Editing In Place

Edit In Place

Following on from our work in Sprint 1, I’ve been conducting some research today to establish whether or not we’re going to continue down essentially a traditional ‘admin’ system path or whether we’re going to pursue the altogether more challenging (read: scary & hard work!) route of trying to do as much of the content creation and editing ‘in place’ (which effectively means in as much of a WYSWIG environment as possible).

The research today involved some simple walk/talk throughs of two very basic prototypes that I had made using Omnigraffle and showed in the ‘Presentation’ view (probably the fastest way I’ve found to build relatively complex application interfaces using a mix of screengrabs and wireframes that you can click through). For those who are interested, those and this blog post are going to form my ‘demo’ materials for this Scrum sprint.

Predictably (although also happily) everyones main priority is for things to be ‘as simple as possible’, however there was a strong leaning towards the ‘in place’ solution which I found somewhat surprising, as previous research had almost indicated the opposite. (Yet another reason to research as iteratively as you design!)

So, for the next few days I’m going be working on more detailed interface designs for this ‘edit in place’ approach, and to that end, I wonder if you can help me… I’d *love* to see some good examples of relatively complex edit-in-place/WYSIWYG interfaces. Obviously Flickr is the poster child for fairly simple in-place interactions, but are there good examples of being able to add and create new content elements, move them around on page, maybe even manage a few versions of the page… relatively complicated stuff.

If you could point me to any examples, I’d be incredibly grateful!

Economist/Drupal Publishing Tools – Sprint One Update!

Sprint Planning

I’m in the midst of our first sprint on the ‘publishing tools’ project at the Economist, wherein we’re defining interface designs for the ongoing migration of economist.com over to Drupal 6. hurrah!

There is no sprint zero in this project and no time to consider the overall environment design, we’re going to be approaching this incrementally throughout the project, so instead we’re ploughing headlong into proper interface design, and the first few sprints are dedicated to designing publishing tools to allow a group of editors to update what are known as the Channel Index Pages (experimental versions can be seen on economist.com now here and here for example). They’re not much to look at just yet but designers in the New York office are hard at work wireframing and designing up much richer and more exciting!

So, Sprint One dives straight into research and interaction design, I work three days a week on the one week sprints and the format we’re using goes a little like this:

Day One: Research

This week I spent the day talking to Channel Index Editors (who update the website pages) and Section Editors (who edit the print version of The Economist). The interviews were a mixture of me getting to know who is who and what they do, understanding the way The Economist as an organisation works, the publishing processes, perceptions and concerns re: web vs print content production and quality, and getting walkthroughs of some of the current software in use for both web and print production.

There’s no time in the schedule for formal research analysis so it ends up as a page of scribbled notes at the end of the day that, as it turns out, is already serving as a really useful reference point. Some of the scribbled bullet points included:

  • the channel index admin interface is working pretty well at the moment no critical usability issues
  • however, one of the key tasks on this page (news package creation, where the editors group together related content) is currently a very ‘human’ task, relying a lot of the memory of the individual editors and a little on Google searches – there is an opportunity to support this task
  • the biggest usability issues are around the content creation tasks which uses the infamous ‘tree’ system and wastes vast quantities of editorial time due to it’s inefficiencies – improving this interface as we port the system to Drupal will free up significant time for journalists and editors to do what they do best and what they really want to do. As one participant so poignantly shared: ‘what I want to be doing is spending my time writing and at the moment I spend half my time writing and the rest of my time fighting the content management system’
  • people are using the print publication software (known as CCI) for much of the web production process to take advantage of its visible workflow/approval infrastructure (which is basically all about getting the right sets of initials on your content) – we need to find a way to support this process in the Drupal system
  • unlike many CMS implementations I’ve worked on, workflow is not really a ‘top down’ imposition but actually considered desirable – writers *want* people further up the editorial food chain to review their work and for this review to be evident. is this significant for the way we design workflow/reviews?

Day Two: Planning, Designing & More Research

My second day on this sprint kicked off with a Scrum Sprint Planning Meeting – much standing up, reviewing backlog, breaking down stories into tasks and guessing hours.

It’s always a kind of tricky process for design work (and probably for other kinds of work too) because the tasks seem to be so mixed up and messy in a lot of cases – what I say I’m going to do (theoretically) and the way they actually happen aren’t necessarily the same – but it seems to work pretty well here, mostly because the team are pretty flexible and very interested in making design work in a Scrum environment.

Then it was onto some design work – lots of sketching, some prototype building, rinse & repeat until I had to head out for another user research interview.

Day Three: Design, and setting up next week’s research


Day three was all about building my ‘demos’ for next week – demos are a requirement for the Scrum methodology and we have to have something to show at the ‘demo’ session each week and, of course, they’re also what I’ll use in my next round of research, which is day one of the next sprint and which I set up with a few of the people I’d met earlier in the week.

At the moment I’m building my prototypes in Omnigraffle – mostly because I’m using a mix of wireframes and screengrabs and it’s the fastest, easiest way I’ve found to do it – and then just throwing it into ‘presentation’ view makes a great format for use in user research sessions.

One of the big issues I’ve been dealing with this week has been the environment for the content management to take place. The project team I’ve come into have a strong preference for ‘in place’ editing, and I’ve been pretty cautious about taking this approach because it can be difficult to manage complex editing tasks in this environment and because there’s been no indication from user research that it is necessary or beneficial.

At the end of day three I’ve got two prototypes ready for Monday – one is a traditional ‘Admin System’ interface with some simple ‘in place’ editing on Preview and the other is almost entirely ‘in place’ editing. We’ll see how they go in testing on Monday and what we see there will guide the decision making going forward.

Unlike the D7UX project, the technical team here are not at all daunted by the prospect of trying to make Drupal do some pretty serious in-place editing (it’s a different story of course when you don’t have to worry about Core!). Time will tell whether they’re just an overly optimistic bunch or not :)

And now, to the weekend! :)

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!

Why Drupal needs a Design Community Manager

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)

Design In the Open Community for Open Source User Experience Design

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/

Openness and Effectiveness in Designing with a Community

Open Design Triangle

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.