Last updated 17 April 2015. Created on 2 August 2011.
Edited by GretchenMcPherson, jpoika, batigolix, jimclegg. Log in to edit this page.

If you create an issue report to address a design or UX problem, you have to be a bit more specific than when you create an issue for a technical problem. Just providing a patch is not enough for the contributors that review UX issues. They are often not developers and not always able to apply patches.

Provide rationale

Provide the rationale for the changes. E.g., "The title is misleading and the contents are a bit all over the place". This gives the developers an idea what to expect, and how to handle it.

Use the correct tags

  • If your patch affects the user interface, tag it with Usability.
  • If your patch requires someone from the UX-Team to look at, tag it with Needs usability review
  • If you are making such a major change, that it requires feedback from users, tag it with Needs usability testing

Provide screenshot or demo site

  • Providing a "before" and "after" image or a demo with the applied changes helps everyone understand the issue and the proposed solution.
  • To provide context, capture the full screen and not just a cropped snapshot of the affected area.
  • Allow the screenshot to display at full size
  • If you are changing something more complex (e.g. a workflow that spans multiple screens), demonstrate it with multiple screenshots.
  • If it gets too hard to explain the idea with screenshots, record a short screencast or setup a demo site. In the last case, make sure that you disable any harmful permissions (link the module for that).

Background: the design process for the Drupal UX

Keep in mind the design process that underpins the the Drupal UX work.

Design is not guesswork
It is important to remember that design is not guesswork, there is a lot of theory and practice in making something usable.

Describe the problem
Clearly describe what the usability problem is, often this is often more important than the actual solution.

Design solutions, not opinions
Everyone has an opinion on which color to paint a bike shed. However, there is a whole body of color theory for finding the best color option(s). It is often the lack of applicable design knowledge that causes unconstructive "bike shedding". For example, a very respected contributor could call out "I do not like that blue". It is up to everyone to avoid criticism based on personal preferences. That includes keeping an eye on your own biases.

Ideas will be judged
The community reviews and decides on the design idea, not the design owner or contributor. See your input as one more step in helping the community find an even better design solution. Your idea may already be an improvement however, it often leads to exploring alternative options that make it even better.

Contradicting use cases
In a system as complex and broad as Drupal, there never is a single perfect solution. Your idea might solve one problem but create another. Be honest about the good and bad effects of your patch.
This allows for an open discussion in weighing the pros and cons. Indecisiveness often makes for bad interfaces. There will be cases where multiple options with different trade-offs are equal candidates. It is then a good thing to decide and specifically choose one direction and consciously make the trade-off.

Expect resistance
When providing design solutions expect resistance.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.