How we used teamwork to design our Teams feature

Shortcut has grown over the last few years, and our customers have grown right alongside us. Shortcut was originally designed to allow users to model nearly any approach to organizing their work through our general-purpose Projects concept. That worked well enough for what it was.

One of the strongest pieces of feedback we’ve heard over the years, though, is that Projects were useful but too generalized, and didn’t allow larger organizations to model their departments and squads effectively. As a result, we felt it was important to improve on our data model to make it easier for customers to better represent the way they organize their work and structure their teams inside of Shortcut.

That's why we launched our Teams feature back in March. But how did we come to build the features that we built?

Validating Customer Needs

To ensure we’re building a feature that addressed our customers’ needs, we wanted to validate that a Teams focused feature was the right direction for us to go.

Direct Feedback

We reviewed the past feedback we’d received from customers and found common refrains relating to Team-based work:

“How do I represent my Teams in Shortcut?”

“Where is my Team’s work?”

“We’re struggling with cross-team organization”

“Hacking” A Team Concept

From reviewing existing customer data and feedback in various customer interviews, we discovered that many of our customers were already using existing Shortcut concepts (e.g. Projects, Workflows, Labels, Milestones) to model their own teams. Because none of these existing concepts were built specifically to represent Teams, they were not intuitive and also limited in functionality. This resulted in significant confusion and insufficient coverage for key use cases.

Survey

To help verify our findings, we sent out a survey to better understand customer pain points and use cases. We found that many of their top issues related to being able to organize and find work by team.

Solving User Problems

Armed with this better understanding of our customers’ problems, we set out to create a solution that would help them with several use cases:

• Organizing their work by teams
• Only seeing work that’s relevant to a specific team
• Viewing a team’s current work and what they plan to work on next
• Keeping informed of a team’s progress

Building the Foundation

We know that adding a Team concept to Shortcut would be a huge project that would touch every part of our platform, so we wanted to give this concept a strong foundation. We first needed to build in the ability to associate Shortcut work entities to Teams before we could do anything else.

One big challenge was figuring out the relational data model data modal (read that twice if you need to). We needed to answer:

• Which work entities would we associate teams with?
• Can customers associate 1 or more Teams to a work entity, like a Story or Epic?
• What happens when Stories associated with Team A are added to an Epic that is associated with Team B?
• How are Teams and Workflows associated to each other?

To answer these questions, we researched the key customer jobs and use cases for organizing by work. We then analyzed our different structural options based on their ability to solve those jobs.

Once those questions were answered, we created design mocks and concepts that showed how users can associate different types of Shortcut work entities with a team, and how they can organize their work within Shortcut to show work only for selected teams.

Centralized Team View

With customers now able to associate work with a team, how can they quickly view all of that (or any other) Team’s work in Shortcut?

We started working on a concept of a Team Page that would be the hub from which all of a Team’s work could be located.

What to Put on This Page

One challenge was to decide what would even go on this page. We created a few design concepts and set up customer interviews to validate some of our assumptions.

The results were this: Customers wanted to see all the work entities associated with the Team, such as Stories, Epics, and Iterations.

And we also discovered that customers wanted a quick way to review a Team’s progress and status too.

Snapshot View

This led to the idea of a “Snapshot” view, which is a summary of what the Team is currently working on. We explored a lot of different ideas for this view, from showing the proportion of ongoing work that are Features, Bugs, or Chores, to showing Story distribution among Epics.

We ultimately decided that showing the status of Epics, Iterations, and Stories in progress was the most useful, while also best fitting customers’ workflows.

This design is not in production today, but in our queue for future consideration.

Iterating on the Designs

We iterated on the designs of this page and landed on a concept that balanced showing all of a Team’s work against a high level summary of a Team’s status.

Did we succeed in addressing our user problems?

Organize work by teams

Users can now associate their work by Team, and filter different pages within Shortcut to show work by Team.

Only see work that’s relevant to a specific team

Users can use filters across Shortcut to see only work from their Team. They can also go to any Team Page to see all work associated with that team.

View a team’s current work and what it plans to work on next

The Team Page shows current work and future work for the team.

Stay informed of a team’s progress

The Snapshot provides a quick summary of a Team’s progress.

MVP Launched

We launched an MVP version of the “Teams” feature, including a Story-based Teams page, and are monitoring how our customers are using it.

We’ll use feedback and data to gain a better idea of where we can improve and determine which features are most important to roll out next.

This was a huge team effort beyond just Product Design, and none of it would have been possible without the great work of Joey Shampain, Ben Wittenberg, Eli Naeher, Ivan Willig, and Missy Danielson.