Workspaces (Postman 6.0)
Postman has a very active GitHub community which keeps us on our toes by reporting bugs and asking for features. One of my duties as a designer is to keep watching for patterns in how people use the product and the kind of problems they run into. At some point in Postman’s life, we started receiving a lot of questions and feature requests which seemed unrelated at first. They were all related to different workflows and were asking for different solutions.
Example 1. One user wanted the ability to link a collection to an environment because his teammates were confused about which environment to use with what collection.
Example 2. Some people complained that one of their collection was unintentionally changed by someone in their team and asked how they could prevent that.
Initially, we provided simple advice to these people about how they could name their resources in a certain way or how they can leverage permissions to prevent mistakes. However, as we kept going through similar questions, we realised that the problem was deeper than it looked.
As Postman grew, so did the users. Teams on Postman started hitting the 100 members mark. As collaboration grew, the amount of data in a team increased exponentially. We provided each user a space to work (Builder) and a space to share resources with all his team (Team Library). But when the shared resources grew beyond a limit, people started making mistakes. Then they started creating their own policies and solutions to prevent these, which sometimes made matters worse for their teams.
We knew all of this because our own team uses Postman for almost everything. From the complex problems that come with API development to simple tasks like checking if a new chapter of a manga was out yet.
We decided to tackle this problem head on instead of thinking of workarounds. As this was a large project affecting almost all user flows, requiring a refactor of our entire interface, we decided that the whole design team (3 of us) will work on it together.
The more we thought about, the more we came to the same conclusion. We’d have to provide better ways of organisation. If we could let users manage context about what they were working on, there would be fewer mistakes.
Workspaces let you organise and group your resources as well as team members in whatever way you see fit. You could have different workspaces for different teams or for different micro-services. If you wanted, you could even have personal workspaces for different projects that you’re working on individually or team workspaces for multiple people working together on something.
One of the other decisions we took was that Workspaces would only be a view layer abstraction. This would mean that resources would not be stored inside workspaces, only viewed inside them. This would make collaboration easy across team because a single resource can exist in multiple workspaces.
Workspaces was one of those features that impacted all existing flows of the products, from signing up to doing complex dev tasks. In such cases, it becomes difficult for designers to account for every possibility. Therefore, we involved our whole engineering team to help us with figuring this out. They did a simple exercise and went through the product and started flagging all the places where changes that will need to be made.
Postman app had always worked offline, and Workspaces was also one of the first features that was online first. What this means is that it was designed to be used online but had offline fallback states. This added another layer of states that we had to maintain.
Before Workspaces, teams had a “Team Library” which let them share resources and a “Builder” which let them work on anything, including personal resources. We replaced these with Team Workspaces and Personal Workspaces. A Team Workspace was created for each team and everything in their Team Library was moved there. Everything in a user’s Builder was moved to his Personal Workspace. We introduced a Browse view for each workspace which was similar to the old Team library so that older teams could figure out intuitively how to adjust to the new interface.
Workspaces saw immediate adoption by all teams. This validated our assumptions that larger teams felt the need for organisation. At the time of writing this (2019), teams with 25 or more members have an average of 6.5 team workspaces (and more personal workspaces). Even smaller teams and individual users started using workspace for maintaining contexts like being able to differentiate between production and staging environments.
This project was special because the whole design team was working on it together. It helped us improve communication and documentation within the team. The team had always been pretty close-knit but we still felt an increase in trust and respect between ourselves.
What could be done better?
To ease the process of migration for existing teams we created a separate UI, called it the “Browse” view of the workspace which can be used to manage contents within the workspace. We put a toggle in the status bar for switching between the main view and the browse view. Although we deliberately made it a little inconspicuous (since this was a minor feature), we didn’t realise that the status bar is the last place where users expected it to be. This resulted in some friction for existing teams while adopting Workspaces.
However, as with all other features, Workspaces evolves as a work in progress becoming more and more integral to how teams collaborate in Postman.