Skip to content

Design: Open an Issue

Tristan Camacho edited this page Feb 3, 2025 · 6 revisions

General Guidelines

  • Anyone on the design team can open an issue.
  • New issues—including design issues, development handoff issues, and bugs—must be added to the Staging Deck.
  • Use the "details" element in GitHub when uploading images, such as the one below. The purpose of this is to reduce the amount of vertical space occupied on GitHub issues and thus reduce the time spent scrolling down them. If users want to see an image, they can open the detail element by clicking it.
Click here!

Alt text

Use can use the code below as a template for the "details" element.

<details><summary>Summary of the image</summary>

![Alt text](URL of uploaded image)
</details>

You'll notice that the above image is pretty large. If you want to make your images take up less space, you can replace this image format that GitHub automatically uses...

![Image alt text](URL of uploaded image)

...with this format:

<img src="URL of uploaded image" width=500px>

And replace the "500px" with whatever image width you want. Then you can make the above super-wide image look like this:

Click here!

Labels

  • If possible, include labels for all of the following categories:
    • feature: Which part of the project the issue pertains to. An issue can pertain to multiple features, such as a:
      • page, like Create Project Page 3
      • functionality, like the Reset Project button
      • deliverable, like the Style Guide
    • level: How much skill the issue takes to complete. The higher the level, the more senior the team member should be who is assigned to it.
    • milestone: By what point in the project's timeline the task needs to be completed. This will usually be selected by a member of the production team.
    • priority: How important it the issue is compared to other issues. This will usually be selected by a member of the production team.
    • role: Which team will work on the issue.
    • size: How long the issue will take to complete.
  • If you don't know the correct label for a category, leave it as "missing".
  • If an issue is still being worked on and isn't ready to be prioritized, add the "draft" label.
  • If you need additional information from a specific team or lead, add the appropriate "ready for [team] lead" label. Add a comment tagging that lead and asking for the needed information, then move the issue to the Questions/Clarifications column.
  • If an issue is ready to be prioritized at the all-hands meeting, add the "ready for prioritization" label. Once the production team reviews it at the meeting, the issue will be moved from the New Issue Approval column to Prioritized Backlog, unless it has an active dependency, in which case it will be moved to the Ice Box.

Sections

  • Keep the title as short as possible. Titles should not be more than twelve words long.
  • If one or more issues must be closed before the new issue can be worked on, include a Dependencies section at the top with the required issues listed in an unordered list.
  • In the Overview section, explain what the requested task is in one sentence with the format "Please [create requested solution] so that [user problem can be solved]." For example, "Please design a sort icon so that users will know which column is being sorted."
    • Sometimes a specific solution will not be requested, in which case the format can be expressed as "Please [solve user problem]." For example: "Please design a way for users to know which column is being sorted."
  • In the Details section, provide all available context that the designer can use to better understand the problem and possible solutions. This can include:
    • Who requested the issue
    • What problem caused the issue
    • Screenshots from the development site
    • Mockups from previous designs or similar ongoing issues
    • Constraints the designer's solution must meet
    • Details about the problem
  • In the Action Items section, list any steps the designer must take to complete the task. Most of these will be automatically included in the selected template.
  • In the Resources section, list the steps required to reproduce the design problem being described in the issue. Additionally, list links to resources that would help the designer solve the issue, such as:
    • Other GitHub issues that affect or are affected by the problem
    • TDM Dev site pages
    • Figma pages
    • Helpful research or design information
    • Other applications that have potential solutions

Example Issue

### Dependencies
- #2013
Clone this wiki locally