InVision Nested Spaces UX Case Study

background

Spaces was created to bring teams' work and workflows into a single source of truth

In 2021, InVision conducted a study on the state of visual collaboration. Our research showed that one the most common pain-points for users was creating alignment between multiple cross-functional stakeholders. Many users struggled to organize and maintain a single source of truth for their projects, which could have workflows and communication divided across 5+ tools.

Spaces was created to solve 3 major challenges with cross-functional collaboration:

Centralizing Teamwork

Reducing the time it took to find documents

Consolidating the context and communication of projects

Before Spaces, our users relied on a conventional folder system called Groups. We launched Spaces as a subfolder of groups because we found that our larger teams needed more than 1 level of organization.

Problem

Users of Spaces proved to be stickier and more likely to invite their teammates, but the growth of Spaces remained slow

While Spaces proved to be a useful tool for our power users, our data showed that feature adoption was low and many users stopped using Spaces after their first week.

We saw Spaces as a valuable tool that could be a major driver for both engagement and growth. We wanted to understand what was preventing Space adoption.

Challenge

How might we improve the Spaces experience to drive growth?

Goals

Adoption

Grow the # of active Spaces users

Retention

Increase how often users return to Spaces

Research

Discovering users' painpoints with our existing Groups and Spaces

Together with JC (UX Research Lead) and Jaji (Product Manager), I created a research plan that included user interview, contextual inquiry, and (once our prototypes were created) usability tests.

Our interviews led us to discover dozens of pain-points with Spaces’ usability and discoverability. While some were small bug fixes and one-off improvements, more than half of the issues we discovered pointed towards issues with the architecture of Spaces and our organization framework.

Group

Groups give users a way to organize their Spaces and documents and share them with their teams

Space

Spaces help users give more context to their projects, bringing all of their work into a single source of truth

Insights

Through research, we discovered that users found value in Spaces but that its usage was hindered by key painpoints

Painpoint

Space creation is difficult and restrictive

All non-Space users and even some regular Space users found creating a Space to be confusing and convoluted. Because of our backend model, to create a Space, a user first had to select or create the Group that would contain it.

For new users, this meant that they had to create 2 folders at the same time. This didn’t fit with our users’ mental models as they typically only created folders as they needed them, and very rarely planned their organizational structure beforehand.

We had inadvertently blocked Spaces from being used by a wide set of users. Users on smaller teams and freelancers often times worked on projects that only had a few documents and no need for multiple levels of organization, thus they never were able to access the value of Spaces.

Painpoint

What is the difference between a Group and a Space?

Users were confused about the difference between Spaces and Groups. Users felt that the nomenclature was too ambiguous and didn't demonstrate an intuitive hierarchy between the 2 folders. While we did have documentation on the topic, it was not easily discoverable and the differences were difficult to explain in context.

Additionally, the inconsistent interfaces meant that users had to choose which organizational system fit their project better. Groups and Spaces ended up creating a more confusing experience for users looking for an easier way to organize and access their projects.

Painpoint

The current levels of permissions are too limiting

In the existing model, users could only set permissions at the Group level, and their Spaces would inherit them.

We heard from many users, especially those who worked in client-facing roles, that 1 level of permissions wasn’t enough. Oftentimes, users would use Groups for a team or client and wanted to restrict who had access to each of the projects in those Groups. Our users were looking for a more personalized permissions experience.

Provisional Personas

Identifying key use cases using personas

From our research, we identified 2 main groups with differing goals and painpoints. These personas helped us design for various use cases with our solution.

Product Manager

Enterprise Company

Goals

Seamlessly work between various projects and documents

Ensure that all cross-functional clients have access to the correct documents

Painpoints

Can’t set separate permissions for Spaces and Groups

Groups and Spaces use different patterns for organization

Priya

Product Designer

Freelance

Goals

Wants to collaborate with her clients on short-term projects

Projects often get bigger than planned so she needs flexibility to organize

Painpoints

Can’t use Spaces for smaller projects because they don’t need multiple levels of organization

Gets confused if she should create a Group or a Space for a project

Information architecture

Recreating the relationship between Spaces and Groups

We knew that our current information architecture was restricting our users from organizing with full freedom. We explored 2 main paths to unlock Spaces for all users and make organization more flexible.

Option 1: Spaces without Group

Allowing users to create Spaces independent of Groups

Minimal change management

Lower scope than changing all Groups to Spaces

Can be used as an interim step to Nested Spaces

Doesn’t fix issues with hierarchy & nomenclature

Users can’t move a Space into a Group

Current users wouldn’t be able to change existing Groups

Option 2: Nested Spaces

Converting Groups & Spaces into Nested Spaces

Solves issues regarding hierarchy & nomenclature

New users can immediately unlock value of Spaces

Reduces user decision making and simplifies patterns

Make permissions more consistent across layers

Requires more engineering effort

High change management for current Groups users

Although it required more effort, Nested Spaces provided a solution that better solved our users’ needs and was more scalable

After conducting a solution review with our cross-functional partners, we decided to move forward to create a Nested Spaces prototype. To validate the new model, we wanted to concept test the prototype with users.

Permissions Constraints

Constraints with implementing permissions at all levels

The transition from Spaces and Groups to Nested Spaces wasn’t straightforward. Our existing information architecture used a container model where Container A (Group) could have permissions and Container B (Space) would inherit them.

Changing our container model was a huge overhaul that would add additional months of work, meaning that the quickest path to a Nested Spaces MVP was changing the experience and UI of Container A to Spaces, meaning that unique permissions still wouldn’t be available in Container B (Subspace).

Our long-term solution was to redesign our container model so that every container could hold it’s own permissions, and nest another container within. This was also necessary for users to then be able to then move their Spaces into and out of other Spaces (eg. if a user creates a Space then wants to move it into another Space).

Reflection

Sidebar Designs

How do we show users that their Spaces contain Subpaces?

One of the key challenges to Nested Spaces was how to visually show Spaces containing Subspaces. With users primarily using the sidebar for navigation, we explored different options to expand on the sidebar.

A. Single Sidebar

Instead of switching from a Home to a Space sidebar when entering a Space, we would use a single sidebar that would expand to show both Spaces and documents.

Users can quickly navigate between documents, Subspaces, and Spaces

Aligns with patterns on other product our users use (eg. Coda, Notion)

Visually cluttered and unfocused if a user just wants to work within 1 Space

Requires Space permissions and customization to be moved to the document display UI

B. Nested Space Section

Create a new section within the Space sidebar where users can create and access Subspaces
‍

Clearly labels what Subspaces are contained in a Space

Keeps the Space focused on its contained Subspaces and documents

Non-dismissible if a user creates a Space and without intending to create Subspaces

C. Space Switcher

Keep the Space focused on documents by moving Subspace selection and creation behind a switcher menu

Keeps Spaces focused on the documents within rather than jumping around

Makes it easy for users to switch between Subspaces

Creating and navigating to Subspaces is less discoverable

Reflection

We decided to move forward with B. Nested Spaces section because it provided the most visibility to users and used patterns they were already familiar with

Reflection

Concept testing

To validate our designs, I built a prototype to test whether or not users would understand how to way-find and create Spaces in the new model

All users successfully created Spaces and Subspaces from Home

All users were able to explain the relationships between Spaces and Subspaces

8/10 users were able to navigate between various levels of hierarchy using breadcrumbs and the sidebar

8/10 users understood that Subspace permissions were inherited from Space permissions

6/10 users found our icon customization to not provide any value

4/10 Users wanted a quicker way to switch between 2 Subspaces

3/10 Users wanted a visual way to identify their documents like they could in Groups

Reflection

Removing icon designs

Users found the current Space customization to be more confusing than helpful

When Spaces was launched, we introduced a way for users to customize their Space with a color and shape. What we learned from our users was that limiting the ways users could customize their Spaces actually made it more confusing for them.

We explored the idea of custom icons, but struggled to balance users adding in icons to Spaces with InVision’s own suite of icons used for documents. Explorations where we allowed users to use both custom icons and InVision’s icons became too noisy and cluttered.

We decided instead in the MVP to fully remove the customized icon to create a simpler experience. In the final version, we wanted to bring in a custom cover photo to help users identify their Spaces on the homepage and to offer personalization to the overview page.

Reflection

Adding back Groups Features

Users felt that the new Nested Spaces experience was missing some of the benefits of Groups

Although users felt the new Nested experience was easier to use, there were some features from Groups that they missed, including being able to switch between 2 Spaces and a quicker way to identify their documents from their thumbnails.

Switching between Subspaces

Users wanted a quicker way to switch between 2 Subspaces so we tested various ways for users to navigate within a Space

Visually identify documents

Users wanted a visual way to identify their documents like they could in Groups so we used our existing thumbnail technology to provide document previews

Final Designs

After applying all of the changes, I put together key flows focused on creating and way-finding in Nested Spaces.

As a user, I can create a public Space

As a user, I can create a private SubSpace

As a user, I can switch between subspaces

Next Steps

Phase 2: Allow users to move Spaces

One of the key ways to make Spaces more flexible and to require less planning from users was to allow users to move Spaces into and out of other Spaces. This required us first to recreate our container model on the backend so both Spaces and Subspaces possessed the same properties.

Phase 3: Add custom permissions for Subspaces

Once we had a new container model, we could assign unique permissions to both Spaces and Subspaces. I worked with another senior designer and product team to design a vision for what permissions would look like in this model. Some of the user flows we designed for were:

User has access to Space, no access to Subspace

User has no access to Space, access to Subspace

User has access to a private Space that turns public

User has access to a public Space that turns private

Handoff & Results

My team and I broke down the Nested Spaces experience into tickets, stretching ~2 quarters worth of sprints. Although we were able to build the majority of the experience on the backend, my team was unable to see through the final implementation of this feature due our company restructuring.

Our final round of usability testing on Nested Spaces prototype showed a significant improvement over our existing model. We saw our NPS score rise from -43 for our current experience up to 60 for Nested Spaces, and we saw a significant increase in our task completion rate from 66% to 93%.

Although Nested Spaces was paused, my team was able to ship dozens of improvements to Spaces usability and discoverability that still resulted in a 350% increase in the number of Spaces users and a 20% increase in user stickiness.