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?
Great to see some of these ideas I know you’ve been thinking about – for almost 2 years now – take some sort of concrete form.
I do think there is one other role of part of this team: A ‘visual’ designer (you know how I love that term, right?). I think this role would be closely aligned to the Designer In Residence role – work alongside the strategy and be across the research outcomes, but would also have one foot firmly in the Drupal brand camp. The Visual Designer would be an integral part of the UX team ensuring the visual design output (which would end up in the pattern library) was both on-brand (meaning, retaining the ‘feel’ of Drupal) and industry-relevant.
It’s also an ‘outsider’ role – being a beacon around which designers in other communities could gather. Drawing much-needed designer talent into the community, and also providing good visual support to the UX maintainers and Pattern Library maintainer. This designer also shares their work with the design community at large and could work on rotation to keep things fresh.
Because otherwise, who does it?
I wonder whether every now and then the designer in residence is a designer who is awesome with the more visual aspects of design (vs IA and less visual ux work)? Or perhaps there is a more permanent role? I don’t have a firm opinion on this.
Yes please! Having additional design leaders, with one foot firmly in the Outsider camp, would be great for Drupal. Ideally, are these people focusing on Drupal the software and drupal.org, or should they keep their focus?
And how can we cultivate ongoing dedication to maintaining both entities?
Looking forward to ongoing discussions at DrupalCon!
I don’t see why they couldn’t focus on both Drupal.or and the software – In fact, I think it’s a godo idea. Both have plenty of work that need doing and opportunities across all the three roles that I’ve described.
But but but… can I be the Devil’s advocate here…
Sentiment is fine, but slippery slope, anyone? Does that mean we need to define a “Lead Software Architect”, preferably a WordPress developer?
I think a much better proposal would be a re-jig of the Drupal Association’s Board of Directors, to give it focus on the issues that will emerge as we start on the path to Drupal 8. Normal, unpaid, annual posts on the board, with the role of guiding the Assembly in their arenas of expertise. That would make sense to me, and not just for UX. The technical disciplines are not represented (directly) either.
The Drupal Association Board has nothing to do with Drupal core development, by design. Drupal Project leadership is very different from Drupal Association leadership. I’m on the board, and having strong software engineering skills means jack all in that role. :-)
I don’t know how feasible funding such a role would be, but otherwise this sounds like a strong idea. I’ve been asking for a more formal UX Guideline / HIG document for years. :-) Splitting the role up into key chunks makes sense, too.
And Greg, the fact that we don’t have a “lead software architect” is one of the reasons our APIs are so horribly, horribly inconsistent. Think about that… Drupal’s DX is quite crappy, too.
Hi Greg,
the Drupal Association is not involved with the technical direction of Drupal (nor core, nor any of the contributed modules like, say, Views).
Setting the direction of Drupal 8 is my role, as is appointing the technical leadership for the next release. I’ve been facilitating a discussion about that at http://buytaert.net/drupal-7-development-process-retrospective.
For the same reason, I’m also interested to see how this discussion evolves. I’m listening. :-)
I’m deliberately not commenting on the community structural needs from a technology/developer perspective – and I really hope that people don’t conflate me saying that design needs this with a statement that developers don’t. This is not necessarily a plea for ‘special treatment’ – I’m just identifying a specific problem and a proposed solution. This may or may not be similarly applicable to the developer side of things. I’m not the right person to say.
It has been my experience that in most projects that have big design challenges, organisation structure and methodology frequently has to change to accommodate that. It’s been true for many of my commercial clients, and it makes sense that similar shifts might also be necessary now.
You might call this a slippery slope, or you might call it the beginning of exciting new changes & opportunities. All depends how you look at it I suppose.
Hi Leisa & Dries,
Leisa: no, you’re not commenting on the structure from a developer perspective, but your comments do imply there should be some structure where there traditionally hasn’t been (specifically on the design side) which will automatically question structure across the board, since such roles do not exist in other parts of the Drupal machine, AFAIK. So while your comments are not necessarily a plea for special treatment (and I’m sure that was not the intention) there is finite resource (certainly from a paid post perspective) and you have inevitably raised questions about how *all* areas of the project are guided. Other things that need our focus too, so my point is “sure, we can do that, but it’s one part of what we need to do”. And not necessarily even the biggest part.
(Btw, I don’t necessarily disagree with you. I haven’t decided yet… this is just a mix of thinking aloud and parroting some things I’ve heard said which are interesting viewpoints. I totally agree design needs attention, I come from a creative agency, design-led development background, so I do understand where you’re coming from.)
Dries: Take your point about the DA and will read your blog post and the comments with interest – I didn’t see it first time around. I think ultimately whatever the leadership solution is for the next release, it needs to be balanced – and I’m sure it will be. =)
I just don’t see paid positions being paid for *by the community*. Several external-to-Drupal organizations choose to pay employees to do core work — with work specifically being broadly defined to include everything from documentation to design.
I agree with your concepts – I’d love to see more re-usable components for tackling issues from a design perspective — but you’re also going to have to propose how to fund those positions, because we have zero models on how to do that today.
I’m not sure what constitutes in and out of the community – is a company that has committed to Drupal ‘in’ the community? I definitely see this being another way that organisations can contribute to Drupal – it’s a particularly good opportunity for design focussed agencies to give something back. I know one or two companies I’d tap on the shoulder in London, and I’m sure there must be loads elsewhere who would value the opportunity to take a leading role in helping improve the experience of Drupal.
Great you outline the personnel needed so early, Leisa. The people are key. New Usabilty Testing needs to be done, goals need to be set, a plan needs to be made. This needs a team.
The d.o. relauch has shown what an enormous difference it makes when you fund key positions.
I also second the idea that at least part of this should be funded positions. Why? Well, we just don’t have enough design and UX people in the community leadership can naturally emerge like in other areas.
Why again? Drupal is still far behind other systems in UX and design. (WordPress is not the only one that is more intuitive, but WordPress alone gets more and more of a serious competitor). With the push for D7 we can just keep up with time, because User Experience is rapidly improving across the web. Just realized that when using Ebay after a long time. Man, the ebay UX is so 1990’s… If they would start today, they would have a hard time just because of that.
How to get the funding rolling? Well, if this gets some kind of consensus, maybe we could set a goal how much money is needed and then go for a plan how to raise that. As Dries correcly notes, the Association is not in the position to take a place in that as they are not allowed to.
I think almost every Drupal Shop would benefit from Drupal improving on its weakest leg. So someone starting with throwing in 10.000 might trigger a solidary pact. Any money invested would pay back ten times. I’d say something around 200.000 – 300.000 Dollars would be a healthy start and not unrealistic to get to. We could do quite some stuff with that. We can also do a lot without it. But only a fraction of what is possible.
Think of _really_ getting the issue queue redesigned and what enormous benefit in getting contributors in that would be. Project Module is a bit of a problem in itself as it is hardly used outside of d.o. So who can afford to work on that in a big fashion without funding?
Oh, and yes, also think http://www.kickstarter.com/. There are models out there.
(Largely replicating my comment from Eaton’s blog…)
This sounds like a strong proposal. As a developer, I’ve been begging for a Drupal HIG for going on two years. :-) Having someone “own” the UX process at a high level can give us the consistency we need, and the direction to build. Once we have a given pattern we know we want, that provides an incentive to developers to make it easier to do. We like the vertical tabs pattern? There’s now a widget for it. The “machine name / human name” pattern? There’s now a widget for it. That creates a positive feedback loop where “doing it the right (or at least consistent) way becomes easy”.
Such an effort can and should encompass contrib, too. Core has its UI models. Then Views has its own design that is internally consistent, but different than anything else. Then Panels has a completely different workflow that is kinda like Views but also very different. Then there’s the Features/Feeds UI model that is unlike anything else and confuses the heck out of me. A solid HIG that we can point to, and evolve as needed, and work on as a dependency for such projects, can help bring unity to such systems so that I only need to learn one UI paradigm instead of 4. (Well, 3.5)
That said, I agree with Boris that the paid part of it would be problematic. Right now, there is no organization that pays anyone to have a position on core. The sole exception was the latter part of the D6 cycle where Acquia was (quietly) paying Gabor to be D6 maintainer. Acquia is not Drupal, however, and there would (justifiably) be riots if it was suggested that Acquia got to choose (officially or unofficially via a full time sponsor) who the Official UX People were.
Paid core leadership positions is a can of worms that I don’t know we can open at this point, logistically as much as culturally. (Who signs the check? There is no one who can do so.) Aside from that, though, I am +1 on this proposal.
I feel like it’s worth mentioning that another spot where
we could use some leadership regarding the design (and theming)
parts of the community is in the Documentation arm of the project.
It’s been challenging finding people who can work on updating the
Theme guide for D7, and the design docs are thin to non-existent.
It would be a great resource to build up, and would help a lot for
designers who are interested in working with Drupal to have some
loose guidelines and suggestions of how to get started, common
issues, etc. (If anyone is interested in this, you can post on the
g.d.o thread about updating the Theme guide
http://groups.drupal.org/node/94444 or post a new thread in the
Docs Team group
http://groups.drupal.org/documentation-team)
The idea of a design pattern repository is great, I think that consistent UX patterns are more important than trend-led, always-changing, open-to-interpretation, and somewhat-subjective UX designs.
Regarding funding, I think funding a design lead team directly while not funding the documentation teams, or the localization teams, or the hundreds of core contributors, etc might seem unfair. Drupal shops contributing back employ designers as well as developers after all.
For the record, I acknowledge that funding these positions opens a big can of worms and that there are similar challenges across the community. Having said that, I don’t think you can just removed the paid-position aspect and accept the rest because, frankly, I doubt you’ll be able to attract and retain a good designer in residence, for example, who is really at the level to tackle and effectively communicate solutions to some of the big problems we have to tackle. Similarly, the Pattern Library task should not be underestimated – to get this to a state where it is actually useful is a Big Job and can’t effectively be approached in a ad hoc manner.
These two roles can have quite specific, project like goals per six months and could be sponsored by an organisation or organisations that wants to be seen to support good UX in Drupal – I agree that the appointment of a person into these roles should be something that is *not* done by the company that is doing the funding -perhaps the DA can step in there?
Funding maintainer roles may be trickier, but if we took a model more like Kickstarter where lots of organisations can contribute to a ‘pot’ and we maintain the same appointment model we currently have, perhaps this would be possible for design and developers? (or perhaps I need to understand the problems better).
Clearly this is a discussion we’d rather not have, but not liking it and avoiding it will not make the problem go away, implementing these roles without incentive will only further illustrate the problem of the currently lack of incentive to do significant work on improving Drupal’s UX for people who are capable of doing so.
So, let’s start talking about more creative funding models that can achieve this without compromising the integrity of the product or the dynamics of the community.
Actually I like the idea so much it made me try to push it a bit further and with personal financial involvement http://rufzeichen-online.de/make-drupal-grow-project-3
Badge your piggy bank!