Validate the need for a first-class import experience

What's this issue all about?

Currently, GitLab's user experience for importing existing work into GitLab when setting up a new environment consists of multiple external tools which are used to first export the data from the source system and then import the data into an instance of GitLab. This experience requires a very technical person, and involves reading complex documentation. The process is error prone and not user friendly.

I would like to validate the need for a first-class import experience with intuitive UI.

What are the overarching goals for the research?

Gather research on the pain points involved with:

Creating a
- new project
- new group
Importing a project
- from an 3rd party service
- from .com
- from self managed instance
Importing a group
- from an 3rd party service
- from .com
- from self managed instance
Importing 3rd party services:
- JIRA
- ... etc?

What hypotheses and/or assumptions do you have?

Users are experiencing complexity with the current project/group creation and import. As the first point of utilization, the project/group creation section can influence a user's perspective of GitLab and impact the feeling of a "delightful" and usable experience.
First-class import experience removes friction from customers when onboarding.
First-class import experience creates a positive first impression about GitLab.
First-class import experience builds confidence with customers.
Most users will use the UI.
Most users will be familiar with the structure of GitLab (ie groups/projects).
Most users will import a whole group with projects, instead of single projects.

What questions are you trying to answer?

What is the largest size our importer can handle?
What is the largest import size possible?
How many imports are successes and failures?
What is the most common import type? (metrics needed from engineering)
What are the complaints of the current import process?
What features are currently lacking in the import process?
- JIRA?
- etc?
Do users want progressive/updating imports which would prevent duplication?
How can we provide error reporting / audit logs / pass-fail?
Do users want to wait for the task to finish or would they rather be notified of completion?
Do we need a notification system for large projects?
- email of success/errors
- system notification
Do users use import for other purposes (i.e. backup and later restore)?

Core questions

Who is doing imports?
How often?

Additional questions

TBD

What persona, persona segment, or customer type experiences the problem most acutely?

Depending on company size, one of these personas would be responsible for importing the existing work into Gitlab:

Primary persona:
- Delaney (Development Team Lead), typically the most knowledgable person about the tools that their team uses
Secondary personas:
Devon (DevOps Engineer), in cases where CI is the primary reason for adopting Gitlab
Sidney (Systems Administrator), in larger enterprises, where the developers don't directly setup their tools

What business decisions will be made based on this information?

This information will be used to decide whether to proceed with the implementation of the new import user experience.

What timescales do you have in mind for the research?

2-3 months

Who will be leading the research?

@hdelalic

What is the link to your opportunity canvas? (Optional)

Related issue: gitlab#33489 (closed)

Current User Journey map

WIP

TBD: Opportunity Canvas

Discussion guide: https://docs.google.com/document/d/1bTLN4wfALa3wkBlJs4vo_1lEOkuBNkk-wz4_uptvsAM/edit

Questions and Assumptions Design Thinking Activity

Mural Board

Import Questions and Assumptions Mural

Participants

2 UX Design
1 Product Manager
2 Backend Engineers
1 Frontend Engineer

Process

We ran this exercise to determine the questions we need to answer and the assumptions we need to validate. Initially, we individually typed out all questions and assumptions we had about Import and our personas and posted them within the Mural.

We then arranged the sticky notes within a grid which represented how risky and how unsure or sure we are about the question or assumption. How certain are you in knowing the correct answer to the question, and how risky is it if you're wrong? Or, how convinced are you with your assumption?

After we identify which questions and assumptions we are most unsure of and find the riskiest, we discussed means to resolve or what it will take in order to answer the question or validate a hypothesis.

Outcome

The exercise helps us to understand where to focus our efforts during the research and information gathering phase. Below assumptions and questions are the most at risk and have the highest uncertainty.

Assumptions & Questions	Means to resolve	Owner
If we solve for the extreme will we solve for all? (volume and project size)	Solution validation	@hdelalic @amandakhughes
Importing a project is easy	Solution validation	@hdelalic @amandakhughes
Most users will use API/Most users will use the UI	Logs	@jhyson
How many imports are success vs failure?	What do we have? What do we need to add? How many times were the imports restarted?	@hdelalic to create issue
Most users will be familiar with the structure of GitLab (ie groups/projects)	User interviews, Other UX/PM group? Professional services??	@hdelalic @amandakhughes
Most uses will import a whole group with projects, instead of single projects	User research/interviews	@hdelalic @amandakhughes
We should focus on Github import and make it awesome	Usability testing on Github. Look at Bitbucket?	@amandakhughes
Do users use import for other purposes (i.e. backup and later restore)?	Time difference between exp and import. Infrastructure team	-
What is the largest size our importer can handle? What is the largest import size possible?	Dependent on the provider, Gitlab to Gitlab, Continuous improvement happening	-

Useful links

Dovetail project

Progress Checklist

Edited Dec 07, 2020 by Haris Delalić