MR: Pending `MR: No MR` <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description This is a design exploration to test the feasibility of a standalone Workspace button as proposed in https://gitlab.com/gitlab-org/gitlab/-/issues/426568#note_1858278881. Areas to investigate - Define problem statement and JTBD - Workflow when creating a new workspace and launching an existing workspace - UI layout disruptions caused by checking if users have access to workspaces and loading existing workspace - Tradeoff between discoverability and UI clutter - Where it should live (e.g. MR and project?) - UI copy ## [UX Scorecard](https://gitlab.com/gitlab-org/gitlab-design/-/issues/2531 "FY25-Q1 OKR: Remote Development - UX Scorecard") There's some additional evidence from a recent UX Scorecard that this is worth exploring. - Participants struggled to figure out how to launch a workspaces without looking up docs first - The `Edit` button was not effective. Even when the `Edit` dropdown was open some users didn't see it and launched GitPod instead. - _“If I had just clicked Edit and seen workspaces I would not have been particularly drawn to use it just because I’m entirely unfamiliar with it”_ <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->