We learned during the Drupal 8 process, that our way of building the product side of Drupal has many challenges. We propose to adopt a different way of working that avoids current pitfalls and enables a fresher, faster way to iterate on the core product.
What exactly are those pitfalls you say? Glad you asked!
Our big challenges are...
- Lack of agreement on our target audience makes it near impossible to make design decisions and accept the trade-offs that come with them.
- A lack of reassurance that changes that are worked on will be accepted. This prevents people from even starting to work on changes and burns out the people who do.
- An inefficient, consensus-based process for implementing even largely agreed-upon changes.
Led us to the point where we now have...
- Significant UX debt in primary site building tools that are hard to use, even for highly technical users (views, blocks, modules).
- A design and development process that requires incredible investment to succeed, putting meaningful change beyond the reach of any single individual or even Drupal company.
- A process that can be completely derailed at any time because much of what we are dealing with here (feature prioritisation, workflow optimisation, user inteface design) is considered subjective.
We’ve been making product strategy decisions on a daily basis for 10 years simply by deciding what to commit. We never articulated these decisions on a strategic level. Target audiences, feature roadmaps, and choosing a position in context of industry trends are ways to provide guidance and transparency we currently lack.
So how do we set priorities, get faster and radically improve our ability to improve?
Tackling the most risky hypothesis first
We have become a lot better at identifying the challenges that can be managed and split up in separate issues. We’ve also defined clearer paths for getting new things added to core. But, to some extent this has also made us risk-averse. "Divide and conquer" has not been a good approach for tackling the really hairy problems in our user experience.
We have to find ways to start tackling higher-level, conceptual problems such as:
- Finding key functionality in Drupal; users are unable to quickly find their way to and around key site building tools.
- Disconnect between what people see (the front-end), and what steps we require to change this in the backend.
- The (lack of) separation between modelling content and its representation, in our site building concepts.
Roy Scholten has a longer overview of Drupal's UX challenges.
It is tempting from a process and resource perspective to avoid these challenges as they require seemingly unrealistic amounts of effort. At the same time, Drupal adoption is held back because these key Drupal strengths are hard to understand and use.
For Drupal to stay relevant and grow we need to tackle the hard problems, and many of our hard problems the hard problems are not about new features.
We often equate output (e.g. new feature X, Y, Z) with value creation. We need to shift to outcome and impact.
However for Drupal to stay relevant, we will have to continue the discussion of who we are targeting with Drupal and which core concepts need to be reinvented and aligned with new technology disruptions.
Decrease the up-front investment: experiment in increasing fidelity
In our current process, the amount of planning, research and design necessary for introducing new or redesigned functionality is too high compared to the impact of the actual change. Any significant change often takes months worth of design, discussion, and code.
What’s more, the impact of these changes is only truly measured after release.
Our goal should be to dramatically decrease the up-front investment necessary for finding out if a design or feature is useful, usable and mature enough for Drupal core.
- Adopting modern software development methodologies that speed up the process from idea to final product
- Moving from a consensus based approach to an experiment based approach.
Our first goal and measure of success would be to prove that we’re indeed validating more ideas faster and more easily.
Provide clarity around priorities
"Scratch your own itch" has long been the driving principle for what people decide to work on. However large changes such as Views in core and adding Symfony were large challenges that got commitment early on.
For the larger community our commitments and product strategies are still mostly invisible. This means that on the more tactical level of day to day contributions, people find it hard to know they are working on the right thing.
Usability testing results on Drupal 8 has already shown what needs work. To be frank, the last 5 usability studies have resulted in few new insights - we know our big weaknesses.
We need to make the implicit roadmap of Drupal more explicit and be clear about which changes, when proven effective and mature enough, will make it into core once. This will provide direction and help attract the new contributors needed to tackle the work ahead.
Tackle the big ones, experiment more, clarity on priorities
Our goal is to establish a more predictable process. A process that gets us to measurable results, faster, with solid insight into the validity of an idea. Individuals and companies will then be able to dedicate their resources to a particular initiative because the risk of getting a design change in core is reduced and more transparent.
Here’s a handy summary of what we’ve discussed in this post:
Iterative prototyping and testing
- Validating ideas more early on with prototypes of appropriate fidelity for the hypothesis - actively avoiding, jumping straight into core patches.
- Increasing community involvement in the early stages of a concept, instead of when it reaches “needs review” in the issue queue.
Create room for experimentation in core (experimental package)
- Validating the “market viability” of concepts directly in core, instead of in contrib or in the core queue - providing a more realistic picture of how ready it is.
- Allowing experimental concepts to mature directly in core, will result in a much larger user base to provide feedback and help out.
Clarity around priorities
- Define a UX roadmap with prioritized changes based on user impact
- Focus contribution efforts around these initiatives
How can we make this change? Your feedback!
Where do we start making this change of process? We are not sure, we need your feedback!
We have already made a lot of progress in the past few months that enables a process that provides more feedback, sooner. We’ve introduced an experimental package; which now includes BigPipe, Migrate, Inline form errors.
The next step is to come up with approaches for improving our process for large changes. We’ve outlined what we think are the first things to work on above.
Some potential topics to discuss:
- How can we motivate more contributors from developers, designers, to project managers and writers to contribute to large UX initiatives?
- To what extent can we have a more top-down - process that allows for direction on hard-felt issues, we’ve been unable to rally around (e.g. improving Field UI)?
- How can our process better support the process of exploration to decision making on discussions like the component based front-end?
- How can we loosen our process, to allow for more experimentation.
We are really interested in what you think, please let us know! :)
Authored by Bojhan Somers, Roy Scholten and Angie Byron and crossposted from the Usability group.