A model for design leadership in the Drupal community

DesignModel

The discussions around the design and user experience objectives for Drupal 8 begin to kick off and will no doubt crank up a gear at the upcoming Drupalcon.  (are you coming? come to my workshop! no ux/design experience necessary)

As much as I want to see us continue the great trajectory for improving the user experience for Drupal that I think the community achieved with Drupal 7, I have some reservations about our capacity to maintain this momentum without addressing some of the structural issues within the community – effectively the environment in which design can happen.

There are bunch of topics that we can explore around this – I’ve pitched a Core Conversation for Drupalcon about redesigning the issue queue, for example. I hope I get to talk a whole lot more that during the coming months. Today I want to talk about a structure of leadership for design in the community and to propose a model.

One of the main reasons that we were able to achieve so much with Drupal 7 was because the D7UX team (which I was privileged to be a part of) were given a mandate, a bit of authority, and a clear brief. If we want to continue to take big steps with Drupal’s user experience (and we still need to take several big steps on this front if we want to be competitive and remain a viable option for a wide audience), we need to find a way to replicate this focus in the longer term.

Currently we have two UX Maintainers – Roy and Bojhan – who are both incredibly dedicated and do great work within the community to promote a better user experience. I have nothing but the greatest admiration for their resilience. There are also, increasingly and largely thanks to Acquia,  more UX and usability resources available within the community.

We have the dual challenge of encouraging existing community members to become more ‘UX-y’ and attracting UX Outsiders into the community in order to grow this team. We also have the dual challenge of making many, many incremental changes that could rapidly improve Drupal’s usability (we call these the ‘low hanging fruit’), as well as considering the bigger, more hairy challenges around defining and understanding target audiences, and finding ways to create good experiences for an incredibly wide set of journeys and requirements.

Eaton recently took a good stab at describing some of the big UX challenges ahead for Drupal 8 and offering a good proposed approach – I recommend reading through this, including the comments, if you haven’t already.

In order to make it possible for such changes to happen, I propose that the Drupal UX Community requires three types of leadership: A UX Maintainer (or two), a Design Pattern Library Maintainer and a Designer in Residence. Let me describe these in reverse order.

The Designer in Residence: This person is tasked with addressing some of the Big Design Problems – the more strategic/structural problems that will impact Drupal’s long term ability to be a compelling choice for organisations in the coming years, that will look at the challenges of multiple platforms from a UX perspective, that will look at target audiences and optimising out of the box experiences/on boarding. This role will benefit from having an ‘outsider’ perspective. This person works with the UX Maintainer(s) to take great strategy and turn them into achievable tasks. This person shares their work with the Drupal community and the UX Community at large, along the lines of what we did with D7UX. They are Drupal’s UX ambassadors to the outside world, they help draw fresh UX talent into the community. They conduct generative research. This is a role that could be rotated every six months or so, getting fresh eyes on the big problems would be fantastic. We could invite people we’d love to work with to take this role from time to time.

Design Pattern Library Maintainer (or librarian, if you prefer): this person leads and coordinates a project to develop an excellent library of design/UX patterns that can be applied consistently throughout core and into contrib. They work with the UX Maintainer(s) to ensure that new patterns are applied/communicated and they take requests from the UX Maintainers to develop patterns that are missing or confused. They might conduct A/B testing to establish optimal patterns. They take work from the Designer in Residence and turn them into patterns as a part of the process of making big design ideas achievable.

UX Maintainer(s): work with the overall community to get the day to day UX work done. Help push things through the queue, coordinate and communicate usability testing, incrementally improve the UX of Drupal by knocking over the ‘low hanging fruit’ improvements, help educate and train up members of the community to be more UX-interested and UX-aware. Works with the Pattern Librarian to see that patterns are implemented well across core and contrib, works with the Designer in Residence to make Big Ideas achievable.

I believe that each of these roles should have clearly identified goals for a defined term (say, six months?) so that they can see and show what success looks like and be able to get useful feedback on the work they’re doing.

I also believe that these roles should be funded positions. I believe that one of the best ways an organisation can support good User Experience in Drupal is to put their hand up to offer sponsorship for a part time role for six months.

If we do this – get the structure in place for good design to happen, and create funded positions to make working on Drupal a viable alternative for good UX people who have so many other competing demands on their time at the moment – I am very excited about the prospects of Drupal’s User Experience in the years ahead.

Something significant needs to happen in the way we do Design and UX in Drupal – along the lines of D7UX but more embedded and integrated and more sustainable. We won’t achieve what we need to by making lists and prioritising them. We’ve still got a lot of big problems to solve and a lot of hard graft to do.

What do you think – might this help make it happen?

Five community challenges for design in Drupal 7 & beyond.

This week sees the release of Drupal 7 – a big event for the Drupal community and also individually for myself and the team at Mark Boulton Design as we worked together with the community on the D7UX project which aimed to significantly evolve and improve the user experience and usability of Drupal.

I’d like to start by congratulating the community on coming together to once again significantly improve Drupal and give it all away for free. Let us never forget what an amazing thing open source software development is.

The last couple of years have been interesting both as a participant and as spectator (because I do feel as though I occupy both of these roles, as incompatible as they may seem… many others who have attempted to participate as a designer in an open source community can probably empathise). It has been exciting to see Drupal embrace the idea of design and user experience as vocally and visibly as it has. I think this visible and actual (financial) commitment has really paid dividends although – as ever, the numbers will ultimately tell that story.

There have also been some fairly significant frustrations. I hope that as we raise a glass to celebrate the release of Drupal 7, we also take some time to resolve to think about how we can make design work even better in this community (and all open source software communities).

To that end, here are some challenges I’d love us to attack:

1. Designing participation for designers

Issues queues and IRC are the traditional communication environment for open source development. If you want to be involved in design for an open source community that’s where you need to be.

During D7UX I was there all the time. Since then – not so much.

I have no idea how people keep track of what’s going on in the issue queue – on it’s own, it doesn’t work (unless I’m doing it all wrong?). You need people to ping issues at you in IRC (or elsewhere) to make sure you know what’s going on.

Being on IRC 24/7 is just not an option for me – much of my work is done away from my computer (sketching, running workshops, doing research) and when I’m at my computer I need to be focussed – IRC is not good for focus.A culture of participation that is designed around IRC and the issue queue is not compatible with getting designers to participate in design problems at the right time (that is, toward the beginning, not at the very last moment).

We need to come up with a way that is more proactive – that goes out an pings designers who might be interested in participating, rather than relying on them coming across something in a timely manner.

Yes, this means changing the way the system works because designers have special needs. Do you want good designers to participate in a meaningful way?
Deal with it. (And yes, we’ll help you design this change. Happily.)

2. Recognising participation for non-developers

At this point I’d like to give the accessibility team, the security team, the documentation team a shout out and congratulate them for their brilliant work on Drupal 7.

I regret that there are probably more people whose lack or recognition I am currently perpetuating, because in Drupal, if you’re not listed in the commit message, your contribution, literally, doesn’t count.The Drupal community subscribes to the saying ‘talk is silver, code is gold’ and there’s been no better demonstration of this then the various thank you pages that have been posted recently using the list of commits to Drupal 7 as an indication of the amount you have contributed to the project.

This means that someone who, in a few hours here and there, submits a handful of minor patches is more recognised than someone who spends hours every week taking all kinds of flak from the community trying to educate them on the importance of accessibility, or explaining a design pattern, or reviewing Drupal.org  and organising the design and content work required in preparation for the product launch. For many of us (and in fact, probably for developers as well) there is a whole lot of thinking and talking and sketching and research that happens before any code is written – actually writing the code is (sometimes) the easy part.

We need to change this culture. We need to make non-code contributions much more visible and recognised. (And this can’t be achieved by simply sitting in IRC 24/7 having a presence and ‘gaining respect’).

Yes, again – people who don’t write code have special needs.
If we want more of these people we need to  change the environment because these needs will not change.

3. Maintaining coherence without ‘owning’ design

Design ideas in the Drupal community need a maintainer, just like core or a module or any important piece of code.

How is it that the Drupal.org homepage can be radically changed within the space of a few hours without any consultation at all with the people who did the research and design work behind it? Or even any adherance to the style guide that accompanies it. (Not to suggest that a style guide is capable of providing specific guidance for every possible outcome).

Of course design needs to evolve as the community and product needs evolve. Of course designers need to respond to the competing requirements of end users, developers, and everything else. This is not about design being precious and permanent.

Just because you *can* change the design, doesn’t mean you should be allowed to – not without a ‘maintainer’ of the design giving approval or at least feedback that you can then act on or against. There is no point investing in good, thoughtful design and then not making any effort to preserve it. Especially when the designers who have done the work are around and more than happy to contribute.

This is not about ‘special needs’ – this is about crediting designers with some ownership over their own work. Not wholesale ownership, just a little. Enough to warrant the opportunity to participate and be consulted.

4. Design leadership in open source communities

Reliance on the current model of participation (issue queues and IRC) means that leaders in the design/ux community currently emerge by virtue of presence – being available on IRC and active in the issue queues. You can’t ‘commit’ design in the same way that you commit code, so you can’t build your reputation in many other ways than being there and participating. (The relatively recent movement toward designed distributions is possibly starting to shift this a little, although still relies on code).

This is good because it means that these people are passionate about design and UX in Drupal and show commitment to the project. It is bad because it naturally privileges people who have more available time and who tend to be less experienced. Designing for Drupal and in the Drupal community is a challenging prospect. UX and product design considerations impact an ever increasing audience who rely on Drupal for ever more critical capabilities.

We need to find a way to allow experienced designers (and in this I include UX/Usability people) to play a proactive, leading role in shaping design in the Drupal community at a strategic, not just tactical level, without requiring them to be on IRC every hour of the day and night and having to respond within minutes.

It is not an acceptable response to say (or think) that there are no designers or usability people out there who are interested in participating or that they just don’t have what it takes to stick it out. There’s no shortage of people who would willingly contribute time and expertise and many who, over the years, have attempted to contribute much more.

I’ve been reading a lot about change management lately and one of the keys to successfully making change is making the environment conducive to the behaviour you want to achieve. That’s our challenge moving forward.

I think this is possibly the most important consideration in my list.

5. Defining our value proposition

I’ve said it before and I’ll no doubt say it again – you can’t meet the needs of the wide range of activities of the incredibly broad Drupal audience in the one interface. Not well. Drupal 7 via D7UX is – hopefully- a better experience for both newcomers, content creators and, in some ways, developers. It is nowhere near an optimal experience for any one of these groups, because they have conflicting needs, behaviours, and characteristics.

Drupal is just like most of the clients I’ve ever worked with who are seeking growth – struggling with their value proposition. I’m not saying we need to abandon any one of our audiences, but we need to address them in different ways, not through one incredible interface. Thankfully I’m now able to stop just talking about this and actually do something through the Project Verity theme work Mark Boulton & I are doing together. (It’s really starting to come together now – stay tuned!) We need to define a UX strategy for our key audiences and then optimise the environment for people to design most effectively for them. We need to do that before we start designing Drupal 8.

It has been a great honour to have worked on the D7UX project and the Drupal.org redesign and, through that, to have had the opportunity to work with some of the passionate and talented people who contribute – in many ways – to Drupal, it’s current and future success.

I look forward to having some kind of continued involvement in the community – exactly what that is will depend on how seriously the community takes some of the issues I’ve outlined above. Regardless of that, I’m here – you want some help, you know how to find me.

Cheers Drupal – Congratulations!
Here’s to the success of Drupal 7 and beyond.

I’m thrilled to be attending Drupalcon Chicago in March – I’m even doing a pre-conference training session called What Users Want that I think will be really fun and which is focussed on teaching people to do what I do (UX research and design), especially those who have never done it before (managers, developers, marketers, I’m looking at you!).

Want to talk about this stuff in person? I’d love to see you at Drupalcon. It’s a great conference and, with Jared Spool, Clay Shirky, Mark Boulton, Jeremy Keith, Russ Unger, Karen McGrane and more coming to share their experience, it’s almost a design conference with added Drupal – hooray!

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