LOADING
INVISION SPACES
Giving users more control over how they organize and access their projects
Year
2022
Company
InVision
Platform
Web
Role
Product Designer
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:
01
Centralizing Teamwork
02
Reducing the time it took to find documents
03
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.
Al
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).
For the Nested Spaces MVP, we couldn’t implement custom permissions for different levels
For our initial MVP, this meant that Subspaces would inherit the permissions of their parent Space. The share modal would be the same in both the Space as well as the Subspace and indicate to users that permissions would be the same at all levels.
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.
                    UXUI
                    Growth
                    marketing
                    Whiteboard Importer
                    InVision
                    UXUI
                    UX RESEARCH
                    Gamification
                    Mobile
                    NYT Cooking techniques
                    concept
                    Other Work
                    Other projects
                    Thanks for reading this case study! Check out some other projects I've been working on.
                      Research, UX/UI Design, Branding, Prototyping
                      Princeton Record Exchange
                      A responsive website for the Princeton Record Exchange
                      Research, UX/UI Design, Prototyping
                      NYT COoking Techniques
                      A seamlessly integrated feature that helps NYT Cooking users learn new cooking techniques