Make design happen in ux/design going forward

Historically, when working on a product-specific task, the UX Team have been assigned to an issue in the project belonging to that product. For example, when working on an improvement for Tor Browser, the designer is assigned to the original issue in the applications/tor-browser project. For most issues, the designer would add mockups of their proposed fix to the issue, and then the issue is reassigned to a developer for implementation.

Makes sense, right?

Problem

However there are problems with this approach! Namely:

• It's inconsistent, and doesn't apply equally to all UX issues.
  • Issues relating to design resources like our Figma libraries, for example, that don't require implementation by our developers already live in ux/design.
  • UX Research issues don't follow the same approach, for reasons lost to the sands of time. These have always lived in ux/research instead.
  • Brand design issues fall somewhere in between – some live in ux/design, and others live in the Operations Team's projects.
• Too many issues live outside of the UX Group to make proper use of the UX group issue board.
  • Instead, we have to apply the UX Team label to our issues and use that to filter the TPO group issue board.
  • In turn, this has led to confusion about when to use the "UX" versus "UX Team" labels across the organization (see for #82 (closed) details).
• Tor has grown substantially over the years, introducing some scaling problems with our existing approach.
  • The UX team is larger, the number of developers on the Applications Team is significantly greater, and the number of products we provide design support for has increased too.
  • Many design proposals in applications/tor-browser now get turned into multiple child issues for implementation regardless, each assigned to a different developer.
  • The design process generates a lot of noise for developers in the original issue, and these issues have grown overly-long and unwieldy.
  • The issue has a habit of moving up and down product kanbans as it progresses through design, just to reset back to the backlog for implementation.
  • Folks are generally confused when an issue is a "design issue" versus an "implementation issue", and when the former can be closed.
  • Dev team leads need to constantly check-in with me about the status of "UX Team" issues when triaging their own issue boards.

Proposal

After chatting at length to the Applications Team about how we organize tickets relating to product issues, we have arrived at the following proposal:

• The "UX Team" label will be updated to "Needs design", and used to tag the original issue in the product project (e.g. applications/tor-browser).
• When we have time on our roadmap to work on the issue, we will create a new issue in ux/design for the production of new designs.
• Both the original issue and design issues will be linked in the issue description.
• The original issue will remain open until it is officially "fixed", and will be used to answer questions related to technical scoping.
• The design issue can be closed after the new designs are approved, and the relevant dev team lead has created new issues for implementation in their own project.

Example

For Tor Browser, a relatively complex task following the new process could now involve the creation of the following issues:

1. The original bug report or feature request in applications/tor-browser.
2. The design issue in ux/design.
3. An issue relating to usability testing or another form of end-user feedback collection in ux/research (if applicable).
4. One or multiple implementation issues in applications/tor-browser.

Issue types

In addition to the Tor Browser project, we would ultimately want to adopt the same model for the VPN, web design and brand design issues too. The following labels will be used to differentiate between each issue type in ux/design:

• Browser
• VPN
• Brand
• A future "Web" label.

In future, should the Tails and Tor Gitlab instances be merged, we may consider adopting the same process for Tails issues too, with the blessing of @sajolida and the current Tails Team lead.

Open questions

• Given that all user research issues live in ux/research already, should we update the Research label to "Needs research" instead, following the same model as "Needs design"?
• What would the migration process look like for existing design issues in places like applications/tor-browser and applications/vpn?