UX Scorecard Recommendations - Create:IDE FY24-Q2 - Implement improvements to my application
- UX Scorecard Part 1: gitlab-design#2531
- Slide deck:
Summary
Positive:
- Users see the value in workspaces.
- Once a user launched the workspace they were able to complete the task fairly smoothly.
- We're on the right path. There's a lot of small tweaks that can net a good return on improving the workspaces and Web IDE UX.
Opportunities
- New users aren't finding the info they need in the documentation. They often end up misinterpreting documentation meant for admins.
- Users have trouble figuring out how to start/launch workspaces from a project. Many users expect to find a workspace section in the project side nav.
- Users don't understand how workspaces relate to the Web IDE. For example, it's often assumed they're connected because workspaces launch in the Web IDE via a preview link. It also confuses users when the Web IDE looks and behaves differently when launched from a workspace.
- The ability to use a workspace on the local machine isn't obvious to a new user.
- The Web IDE is a potentially powerful entry point because the purpose of the IDE is well understand. Launching a workspace from the Web IDE provides context to the purpose of a workspace (ie. add a runtime environment).
- The workspace Web IDE would benefit from quality of life productivity improvements around git and MR workflows.
# |
Insight Theme | Recommendation | Comments |
---|---|---|---|
1 | Documentation for end users | #457300 | Every user relied on documentation to complete the task. Several participants interpreted documentation incorrectly and thought they had to set up a k8s cluster in order to launch a workspace after reading the docs. |
2 | Web IDE terminal | #457308 | Users who aren't familiar with VS Code struggle to find the terminal. |
3 | Consistent Web IDE appearance/behavior | #457309, #418833 | Users expect the Web IDE to look and behave the same when it's launched from a workspace. |
4 | Web IDE git workflow | #457993, &11142 | Experienced developers often prefer to use the terminal for their git workflow, esp since VS Code's source control tab sometimes behaves unexpectedly and throws errors. |
5 | Launching workspace from Web IDE | #457814 | Provide a clear entry point to launch a workspace from the Web IDE. Likely best done by improving the terminal empty state so users can immediately launch a workspace to add a runtime environment. Would also help users understand relationship between Web IDE and a workspace. |
6 | `Your work > Workspace` list | #441503 | Preview label in workspace list doesn't align with user expectations of launching a workspace. _“It was strange to me to hit Preview to find this”_ |
7 | `Your work > Workspace` list | #442494 | Revisit naming of terminated workspaces. Several participants misinterpreted stop/terminated. "Delete" could be a clearer term. |
8 | `Your work > Workspace` list | #442494, #409309 (closed) | Revisit how we expose configuration details of a workspace. How a devfile relates to a workspace isn't always clear and some participants would like to see logs in the UI to better understand/trust the workspace. |
9 | `Your work > Workspaces > Create Workspace` | #442494 | The `Project` label could be more descriptive to help users understand the scope of the projects that appear in the list. For example: All projects in their instance, all projects they have access to, or all projects that are configured with the workspace feature. |
10 | Workspaces at the project level | #457335 | The side nav was one of the first places scorecard participants looked for workspaces. It can also be confusing that creating a workspace from `Project > Edit button > Create Workspace button` results in the user being direct to `Your work > Workspaces > Create workspace`, esp. for new GitLab users. |
11 | Launch workspace from a project | #456493, #426568 (comment 1858278881), #450667 | Users struggled to figure out how to launch a workspace from the project homepage. Some even missed it after clicking `Edit` and launched GitPod instead. Consider placing under `Code` or making it a separate button. |
12 | Viewing workspaces in a project | #457335, #432674 | Needs additional validation but it could be useful to allow users to view/access workspaces from other members within a project. |
13 | Using workspaces locally | #457812 | A couple participants wanted to get set up locally then figure out how to use workspaces. Making it easier to understand how to setup workspaces with VS Code locally would be useful for certain users. It's not obvious how to do this right now. |
14 | Support more IDEs | &11437, &9836, #408381 | Several participants didn't use VS Code. Another expressed interest in moving away from VS Code. Supporting more IDEs is a desired feature. |
15 | Launching development server | #457985 | Previewing changes on a development server is an important part of a Code Author's workflow. Could we improve how we expose this so a user can discover this functionality? |
16 | Authorizing workspaces with GitLab account | Some users hesitated when presented with our authorization screen. It's jargon filled and uses a bright red button. Consider making this less intimidating (e.g. why do we need to use a red button). |
Experience Recommendations Checklist
Learn more about UX Scorecards
-
Add this issue to the stage group epic for the corresponding quarter's UX scorecards. -
Brainstorm opportunities to fix or improve areas of the experience. - Use the findings from the Emotional Grading scale to determine areas of immediate focus. For example, if parts of the experience received a “Negative” Emotional Grade, consider addressing those first.
-
Create an issue for each recommendation using one of the Actionable Insight templates in the GitLab project, depending on if it relates to a product change or needs more exploration. Alternatively, you can create a separate epic to hold all your recommendations. Add a UX scorecard-rec
label to every issue or epic for traceability. To help with prioritization, add a severity label to communicate appropriate urgency and impact to the experience. Link to the epic or issues here.- Recommendations do not need to be documented in your Dovetail project.
-
Think iteratively, and create dependencies where appropriate, remembering that sometimes the order of what we release is just as important as what we release. - If you need to break recommendations into phases or over multiple milestones, create multiple epics and use the Category Maturity Definitions in the title of each epic: Minimal, Viable, Complete, or Lovable.
Edited by Taylor Vanderhelm