Further product discovery for 'new project' flow
Problem to solve
What is the 'new project' flow with the least amount of friction? At the moment, users need to visit 10 pages to set up the basics of a project (avatar, description, license, features etc.). We're changing that via gitlab-ce#47996 where we clean up the interface and adapt it to the user journey maps by adding some options (avatar, license) and advanced settings (features) right on that screen. But can we take it even further and build flows that are even simpler but include adding a template after the project is created?
Proposal
Let's do an even wider exploration and see how we can adapt the flow even more. Can users simply click on 'create a new project' and they're presented with all the options needed on the 'blank project overview' page?
What does success look like, and how can we measure that?
We will be successful when users can create projects and set up their basics as easily as possible. This includes populating repositories with templates (default and group level), pushing an existing repository, importing from other platforms/repos etc.
We can measure the success with a simple usability test task: 'create a project and set an avatar, change the description, change visibility, add a license...' and ask the users how easy or hard the task was (from 1 to 5). Comparing the control to the new version should tell us if we were successful.
Notes from gitlab-org/gitlab-ce#47996
I mapped the journey for common use cases:
- create a new project (blank)
- import existing project/repo
- import repo by URL
- create a new project from a template
As it turns out, the majority of new projects are created as blank projects (according to our data from Snowplow):
That's interesting but I want to keep in mind that a redesign of this flow might have an impact on this. The reasons for redesign are also:
- promote the ability to create projects from templates
- promote the ability that projects (repos) can be imported
- as well as simplify the UI and the flow.
All my approaches are trying to achieve the goals outlined in the journey maps above, but with the least amount of screens possible. Loading screens takes time and it also has an impact on the user's cognitive load (switching among tabs also counts here).
Atm, there's substantial screen switching in these journeys. For example, importing a repo and setting up the basics for a project takes 10 screens. So with this exploration, I want to answer the following questions:
- Can we reduce the number of screens needed for these journeys?
- Can we use the findings from earlier explorations and UX research?
- Can we design these experiences so that they better fit what 80% of users want to do, but promote certain features at the same time?
- How can we measure if the new experience is better?
@tszuromi @matejlatin A thought regarding templates. Right now, on GitLab.com, you only get access to our three out-of-box project templates that ship with GitLab (and which are shown in option 3). In future, there will be an option to disable these on an instance-level.
In addition, we have introduced custom project templates on instance-level, and are introducing them on group-level with %11.6. I am quite confident that this will change utilization of templates for mid to large sized self-hosted instances, but also on .com. So we should consider that there will be arbitrary numbers of templates, and they might become more relevant in terms of usage.
Here is an example visual of the "Create from template" tab of the current "New project" UI, based on having project templates available from several groups.
Let's take Google Docs as an example. They've obviously made the decision that creating documents is one of the most important things that a user can do, so they want to make this as frictionless as possible. The magic moment for a user here is creating content, so they want to get the user there ASAP.
When I click "New", I have the option of clicking the arrow to use a template. I don't think I've ever actually done this, since I generally want to start with a new document and start getting my thoughts out.
What happens when I click the "Google Docs" option in the dropdown? One click, boom:
And I'm immediately typing. What happened?
-
Google Drive assumed that I wanted to create a document in whatever directory I happened to be looking at in Drive,
-
It gives me the "Untitled document" title placeholder (and prompts me to change this if I try to share this with others),
-
It defaults to shared privately, with a clear option in the upper right to change this,
-
If I browse away now without modifying anything, it does not create the document. Google COULD have asked for all of this after I clicked "Google Docs" (show a screen or modal asking for document name, path, visibility/sharing, etc). But they don't; they want me creating stuff, then configuring that less interesting stuff later.
In my opinion, this is a great approach and we should consider exploring something similar. Making decisions like project name, slug, etc. are barriers to finding value for the user and getting them what they want. Let's make some assumptions there and allow them to defer these choices until they get their code into the repo and start finding value with the project.
@jeremy's example of Google Docs.
-
Looking at @matejlatin's proposal for collapsing/expanding options in the “New project” screen, I almost want to put everything inside that collapsed “Advanced” area.
-
Technically, what is the minimum amount of info we need to create a project? The path: project's location (the namespace) and the slug. The slug is automatically created from the name, so we can put that in there as well. Only 2–3 fields in reality.
-
The only other field that helps people get started quickly is “Initialize repository”. Other than this, everything else seems much less important to me. We can put all of the other options in that “Advanced” area.
-
For the features, a better approach might be to select feature sets based on typical usage of projects: All features (the default), Issue tracker (just issues), Documentation (wiki and snippets), File repository (just repository). For example, Jira has Business, Software and Service Desk project types.
-
We can be conservative and set the visibility as Private. But make it dead simple to change it after creation (just like Google Docs, the most proeminent button is Share).
-
Technically, what is the minimum amount of info we need to create a project? The path: project's location (the namespace) and the slug. The slug is automatically created from the name, so we can put that in there as well. Only 2–3 fields in reality. I'd still argue that it's currently 1, and COULD be 0.
If I click the "new project" button in the navbar, we can assume that the user wants to create it in whatever path they're looking at (e.g. the group they're looking at). If not, we default to their personal namespace (what we do now in the new project view if I try to create a new project on GitLab.com).
That just leaves the project name. Like the Heroku example, we could use a placeholder here and make it easy to edit the name later by inline editing the project name. Please excuse my rush job of a wireframe here:
This is what I might see after clicking "new project" (path isn't pictured here, it should be somewhere here).
-
If the user made a mistake and browses away from this screen without doing anything, we don't create any project.
-
If the user ignores the name field and immediately jumps to the bottom options and starts adding stuff to the repo, we create the project and use a placeholder name.