We are nearing the end of the Drupal 7 UX Project which has been exciting, challenging and frustrating from time to time.
I would like to reflect on the process so far, and hope to create an open dialog about how we can learn from this project to power future efforts in Drupal.
The journey began at Washington DC….
We had just spent about a week in a stuffy lab observing people use Drupal, learned a great deal about larger conceptual issues and focussed ourselves on getting the most valuable data out to the community – the understanding of our usability issues. After a very funny and insightful talk on Drupalcon about what we had observed that week, we were excited to jump into this project called Drupal 7 UX.
Angie Byron (webchick), the Drupal 7 maintainer, with her crazy schedule found the time to sit down, with me and catch to go over the current state of usability in Drupal. We were quickly joined by many core contributors and Jeff Noyes, the UX designer from Acquia. We fleshed out some of the problems and also discussed opportunities. At the end of this meeting, we came up with a list of challenges and opportunities, that we discussed with Dries Buytaert, Mark Boulton and Leisa Reichelt during the sprint day.
We split the discussion into two main topics, both needed to be adressed in some way.
1. Drupal 7
- Major usability issues
- Drupal Information Architecture
- Workflow of using contrib modules.
- “Wooow” design changes
- Invisible design (good design, that nobody really notices – i.e vertical tabs)
- Designing for the first impression (but what after?)
With the project coming up, there was a huge opportunity in educating the community about design and learning about the open source design process. As expressed by Steven Wittens - we need to create a larger community around design in order for Drupal to progress further in that area.
2. Design process ( the future!)
- Sustainable process (can the D7UX project outlive itself, and become part of our development process?)
- Design education (expose design thinking, how we get to mockups)
- Experience goals (getting people on the same page on what the experience of using Drupal should be like)
Going from a separated process, to a process where both parties complement each other and get to solutions that makes Drupal better for our users.
The Drupal 7 UX Project is a go!...
A 6 week research began for Mark and Leisa and after about two weeks we saw the Audience Matrix and Experience Strategy emerge. Which immediately got a mass of response from the community. This triggered the first message out of the UX-Team: there needs to be one place for feedback. Mark & Leisa quickly responded and created D7UX.org
For contributors who are used to the issue queue process, where almost every single reply gets an in depth response, the transition to a process where not individual comments but overall trends are taken into account, was harsh. This led to quite some abandonment by otherwise very involved people, since they felt their voice wasn’t taken into consideration. I felt the same, and Roy Scholten(yoroy) lured Leisa into IRC. This calmed some of our nerves, but we also realized that the larger community was not taking part in these IRC discussions.
After about a week I saw a large post – announcing the Project Framework. This really scared me, I really need to keep track of 14 discussion places, some of them very intense? Many people weren’t sure where this framework was going. Were we really about to change almost 14 sections of Drupals inner workings in the remaining 4 months?
A meeting was held in London, which wasn’t very publicly covered apart from D7UX brainstorming blogpost by Jeff Noyes. At this meeting it became clear that we were going to pursue the sketches they held up against technical and design arguments.
I spent a lot of time talking to core contributors and members of the UX team, discussing the following bottlenecks we saw in the D7UX process:
- More insights in the design thinking process.
- What is happening with feedback? No clear loopback cycle.
- Only scratching the surface of bad experiences, most problems are found in Drupal’s flexibility beyond content creation such as blocks, modules and CCK.
- Reusable interface patterns.
- Is there usability testing?
Remainder of the D7UX Project
- Structure tool is too big of a concept.
- With code freeze coming up, things should get more concrete and granular.
We shared this feedback with Mark & Leisa and continued to iterate on the mockups. And tremendous effort by Gábor and Cwgordon was started to actually implement the mockups.
Still, there is a lot of work to be done on the implementation of the mockups.
Dries Buyteart pointed out that Mark & Leisa were in the best position to fundamentally rethink certain interactions and propose solutions to big issues. So let's take a look at some of the problems that where solved.
The first one they were able to tackle is a conceptual issue found in most of the usability tests: Users are confused by the administrative interface as it is visually within their actual website. Their mental model of a CMS is of an administrative interface that is different from the site. The new admin theme "Seven" fixes this issue.
The second big bottleneck is the Information Architecture of the Drupal administration pages. During the UX sprint in Utrecht we were able to put our heads together to work on the Information Architecture. It now has a proposal that should make a big step towards solving the problem of finding functionality within Drupal.
Third were the tabs (local tasks). Usability tests showed that people just didn't notice them. Yet they are the main source for actions. The new admin theme gives a different visual prominence to tabs. This is just one of the many smaller but important fixes.
But above all, the biggest win is that now we have an administration theme that offers a larger playground to work on the administration interface of Drupal. For Drupal 8 that means, we have more of a blank canvas which allows us to rethink interactions with less restrictions then before.
I hope that in the next few months, we can put our current solutions through rigorous usability testing.
We have roughly 450+ core contributors, of whom about 10 are working on the core interface. Yet, this core interface is meant to provide a platform for 2500+ contrib interfaces. And now at the end of the D7UX project, the challenge of building this interface, is by no means there yet. But we were able to tackle a few large conceptual issues and created a larger window of opportunity for design to flourish.
This open source design process is a really hard challenge. Not only in avoiding design by committee, but also the realisation that the community needs to carry the idea forth the next couple years. Without understanding the design choices, we simply won’t be able to.
Our current iterative design process is great for a lot of problems, but dramatic for most large design problems as "Garland" and "Seven" now have exemplified - they both required a small group of deciders. Which put somewhat of a strain on these contributors, making themselves the single point of failure in terms of the design knowledge about the constraints and possibilities of the theme. I believe that this is not the right way of doing it and will only increase the "bus factor" of our design.
Involving and motivating developers
We need more developers, especially those with CSS/JS skills to work alongside UX designers on improving the interface of Drupal. With the D7UX Project we where able to attract quite a large number of people, of whom only a couple sadly got into the "issue queue level" - this due to our issue process being pretty scary.
I think its essential to recognize that with how the feedback process was handled during D7UX, we demotivated a crucial group: our core developers, who can do the heavy lifting required for some of the proposed changes. Personally I felt that by sharing more reasoning behind certain design decisions (why certain inferences were being taken into account and others weren't), could have sparked far more involvement.
As a UX-Team member I was participating in both the programming as well as design discussion of D7UX. Having felt the frustration on both sides my main I see assumptions kill collaboration.
Due to Drupal's modular nature, the design challenges are often very hard - and it's near impossible to be fully informed about the complications for the user. Yet in most discussions, developers assume that design proposals are ill-informed - even if the design proposals truly are informed (by user observations and knowledge about Drupal inner workings). I found that better design communication is key in these cases, where the reasoning of getting to your mockup is usually more important then the actual mockup. We are still far from finding a sweet spot for design communication, but we are getting there.
Open Source has caused disruptive change in programming. However, similar changes have yet to reach design. The most disruptive change coming to design is the notion of control. In an open source process, you just can't really control your design. You can merely guide it.
"It's amazing what you can accomplish if you don't care who gets the credit" Harry S. Truman
Embracing this chaotic process is very scary, and the issue queue only makes it worse. But it is a change that must happen. Designers need to be able to look past symptoms of a certain design to treat the underlaying problem, and you can't do this alone.
We have only just started to reform our design. And a lot of obvious problems designers are eager to point out have already been recognized and are being worked on. These issues need design support, not design lectoring.
I would like to thank Mark & Leisa for all the time they put into this project, which was definitely not an easy challenge.
I would love to hear your thoughts and ideas about the last few months!