Design/Process/Ticketing

Tips for ticketing with and for Design

The following guide contains general advice to help support a better process for working with designers using bug ticketing systems like Phabricator.

1.  Define the problem in task descriptions rather than detailing solutions

For example, instead of “This part of the UI should be blue” or “Change the color of button X”, which dictates an implementation, the description could be “There is a low tap through rate on the call to action button X. Update the presentation of button X to improve the tap rate.”

Mentioning a possible solution as an example is welcome too, but capturing the problem and what we know about it first provides room for exploring other possibilities, and we are better set up to provide an appropriate final solution. (For e.g., a usability study could uncover that the button is being scrolled off screen by users and the solution is to make it sticky rather than changing the color.)

2. Including links to supporting data and context is always welcome

Especially in cases where a task is asking for a new feature or change based on feedback from users, providing direct links to that supporting data is encouraged. For example, if it is claimed that a lot of users are asking for X, it helps to read the feedback directly in context to understand what may be the issue behind their request for X.

Types of supporting data that may be relevant could be unsolicited feedback via OTRS, app store reviews, social media posts; or through direct feedback channels such as talk page discussions, usability studies and user surveys.

3. Supplement tasks that are ready for review by designers with test steps and screenshots

Ideally ensure steps to reproduce and screenshots/recordings of the intended result are on the ticket. Just as with QA, steps to reproduce (perhaps along with the build it is on) are helpful to ensure the reviewer is able to get to the right place to review.

Including screenshots/animated GIFs/video of an interaction that the developer has tested and considers ready for design review is helpful since it immediately establishes expectations and can more quickly catch minor visual design bugs

Screenshots also can help catch regressions/bugs (eg., developer version shows correct UI, designer's later review shows something different)

Tools

For recording interactivity to iOS devices, it’s a simple as opening QuickTime Player, Selecting File > New Movie Recording, then selecting the attached iOS device as the camera source.

For Android devices (with also some support for iOS devices), a nifty app that allows screen recording (to mp4 and animated gif) is Android Tool: https://github.com/mortenjust/androidtool-mac

Example tickets:

• T97777 - As a user, I would like to search for text within articles
• T148202 - Build description editing "success" activity
• T142760 - Create a Top Read widget

4. Make more use of the 'Design sign-off' column

Any ticket that impacts user experience* would ideally go into the Design sign-off column before QA and Product/PM sign-off. When in doubt, it’s probably better to err on the side of putting it in there first.

It is recommended that a 'Blocked or Waiting' column is placed on the board for when a ticket doesn’t pass design sign-off. This would be a good column to add generally to park tickets waiting for some dependency or needing further attention.

*Sidenote: What does impact user experience mean? -> Any change around product, placement, navigation, user interface or has any perceived/real performance change falls under impacting user experience.  

5.  Identify what are ‘UX-debt’ or ‘Design backlog’ items, and write them up with a user story or stories in mind

UX-debt (also known as ‘Design backlog’) tickets are for design-specific improvements to the app and generally fall under two categories:

1. Progressive enhancements (e.g., improve animation transition from viewing the ‘In the news’ card to reading an article from that card); or
2. Fixes to visual display consistency (e.g., audit the app’s color usage to ensure only colors in the brand palette are used).

Example tickets:

• T141767 - Standardize the UI for article lists appearing on the iOS feed
• T141668 - Add ‘pinch and zoom’ gesture as a shortcut to controlling font size of articles
• T123684 - As a user who has denied location permissions to the app, I want to know what I am missing
• T148725 - As a 3D touch user, I want actions to load immediately without requiring an extra swipe up gesture
• T150471 – Icons on the article toolbar are hard to discern when the article's lead image is a light color

Ideal format of a UX-Debt / Design backlog initial ticket description:

edit

UX-Debt / Design backlog task description

User story/stories

As a [user type], ...
...I want [desired experience]
... so that I can [achieve some goal].

Problem
Short description of what the situation is currently that is blocking the success of the the user story.

Proposed solution(s)
Optional section to include initial ideas on how the problem might be solved

The designer will update the description with mocks and information as necessary afterwards.

6. Creating multiple, smaller tickets may be better for tracking tasks

Breaking up some tickets into more minute pieces on work boards often makes it easier to track design vs front vs back end engineering work. For example, when introducing ‘Announcement cards’ (used for user surveys and promoting donation) on the iOS and Android apps, there was a design component as well as engineering work linking up the services, so it made sense to break up the design work into a child ticket.