Service Desk Work Item Type Design

Purpose

Create a design for a service desk work item type. We mainly refer to it as a ticket but name is TBD

We will use this ticket to receive feedback and gather ideas, including from

  1. grouprespond to ask questions, and generate ideas on how we might break down the work.
  2. Project Planning PMs and Designers - to see how this fits with what they're thinking for work items
  3. IT Ops stakeholders - to see if this matches their hopes and dreams 😆 and to see if there are anything missing
  4. Other Service Desk/Design experts internal to GitLab

Review instructions

The attached design is meant to be directional rather than a set of hard requirements. It is an interpretation of what we want to have many iterations from now. We have not determined an iteration path as of yet.

  1. Start by watching the video overview or reading the comments in the Figma File
  2. Provide feedback via comments directly on the design or leave a comment on the issue.

Notable changes

New concepts

  • Source Icon - shows where the ticket originated. Could be email, created direction, via API (some sort of integration)
  • SLA Widget - the design is really a placeholder. In the future, SLA might be set against priority, organizations, impact, etc.
  • Requester - This is the person who wants the request fulfilled. This person might not be the author/submitter
  • Custom fields - Potentially fulfilled by &235
  • Macros - canned responses plus updates to any updatable fields on the page
  • Next ticket - Moving to the next ticket in the queue
  • Having an external user be author/requester/participant
  • Source email (with HTML formatting) is downloadable
  • Requester information tab
  • Organization information tab

Amended/Changed concepts

  • Different states/status - pending and resolved are important states for tickets. Most service desk offering also make state/status customizable
  • Potentially always show absolute time
  • Comments not being editable
  • Potentially no description
  • Different tab visualization for filtering
    • defaults to conversation view
  • Detail section - a details section should map to the work item type. Tickets might not need milestone, iteration, etc. but might have other things like priority. We need the flexibility to organize our own details.
  • Being able to display HTML
Edited by Kevin Chu