How to build great collaboration software

Productivity software has changed a lot over the past decade. With the rise of cloud computing, software to handle documents and calendars has shifted from desktop-based, single-user to cloud-based and designed for sharing. At the same time, the Internet has ushered in the rise of social media. As a result, productivity software has converged with communications software to give us the collaboration software we know today.

At best, collaboration tools make it simple and delightful to communicate, plan, and build things in groups. But I still see lots of websites and apps still making basic mistakes that get in the way. So fundamentally, what makes a collaboration tool work well? Here are some rules I follow when building out the user inerface for collaboration tools, starting with the core architecture of a service and continuing with how to get the details right.

Allow multiple accounts to access each workspace

Many collaboration interfaces, especially simple web tools, associate each workspace with a single login and password. I see this a lot with survey tools, scheduling tools, and some social media. This is the wrong way to go about building a new tool–instead, set it up so that a workspace is shared and can be accessed by multiple accounts.

First off, it’s never a good idea from a security perspective to have multiple people use a single login and password. Someone might set up with the account with an easy-to-remember (and less secure) password with others in mind. Or they may resort to emailing the password around, which makes the workspace vulnerable if anyone’s email is compromised.

The alternative, where each user has their own account, is a necessary foundation for building out a high-quality collaboration experience:

  • Instead of requiring users to remember yet another login and password, you can use a single sign-on system such as Facebook Connect, which works only if individual people have their own accounts in your system.
  • Each user can have different personal settings, such as language and time zone.
  • You can show authorship of documents and comments that a user contributes.
  • By distinguishing accounts from workspaces, in addition to allowing multiple accounts per workspace, you can also allow multiple workspaces per account. I could use the tool for my day job, side projects, and volunteer work without having to log out and in again.

Below I discuss a few tips for getting the details of the collaboration experience right, none of which would be possible without the above foundation.

Allow multiple users to administer documents

So now multiple people can access each workspace. But how about who can control each document or unit of sharing, like a spreadsheet or survey or event? Allowing one user to control a document is simpler to build, so what are the benefits of allowing multiple users control?

  • In cloud-based office software, I can give someone else access to read or edit each document. Beyond that, I can give another them administrative privileges, allowing them to invite others to collaborate. In bigger workplaces where I might not personally know every collaborator, this is key to making the tools easy to use.
  • I use Microsoft Exchange at work and my team is in multiple offices. In Exchange, any meeting recipient can forward the invitation to others, but only the meeting owner can change the meeting’s agenda or location. So when I receive an meeting invitation from another office, I can’t book a room for my office and add it to the meeting on everyone else’s calendar, only the sender can. The limitation of only one user administering an event is inconvenient for distributed workplaces.

The above examples show that allowing multiple users to administer documents helps collaboration tools scale to large workplaces.

Give recipients control over communication features, not just senders

As people use a collaboration tool heavily, a polished interface that gets every detail right makes a huge difference in helping them manage their workflow. For features related to communication, consider giving recipients more control:

  • A simple example of this is group messaging. Over text message and email, only the senders of a group message can control who receives messages, based on a limitation of the standards that they’re based on. If a recipient isn’t interested in the conversation, they can’t opt out through the interface, rather they must disrupt the conversation to ask “please remove me” and hope the next sender was paying attention. In group messaging apps such as Facebook Messenger, the recipients of messages have ultimate control, and they can leave conversations at any time.
  • Similarly, on a traditional phone-based conference call, you can only mute yourself. In some online videoconferencing systems such as Google Hangouts, you can mute other people individually. This is useful in situations where one sender has a lot of background noise. Since the recipients are affected by background noise, and the sender may not even be aware of it, it works better when recipients can control it directly, rather than having to ask the sender to mute, disrupting the conversation.
  • In Microsoft Exchange, meeting invitations use a reminder time-window based on the sender’s default preference, not the recipient’s default preference. I use a default of 15 minutes for these time windows while my one of my teammates prefers 5 minutes. That means for a given day with a mix of meetings created by me and him, my meetings have inconsistent reminder time windows, which might cause me to believe a 3pm meeting was canceled if my phone didn’t buzz at 2:45pm. While sender-based time windows may be useful in situations like offsite meetings with travel time involved, it’s confusing for my team’s use case of everyday meetings in our office.

Make it possible to share view states too

Let’s say I create an online spreadsheet with multiple sheets, and add collaborators. I then add a bunch of data to Sheet 1, and then I open Sheet 2. If my collaborators were to open the spreadsheet at this moment, I would want them to see the data I added on Sheet 1, but I would want them to view Sheet 1, not Sheet 2. So as someone building the collaboration tool, how do you build this interaction correctly?

The key is to distinguish between the document’s data and its view state. Besides which sheet you’re viewing, other examples of view state include slides in slideshow tools and filters in data visualization tools. Any changes a user makes to the data should be immediately saved to the server and pushed to other collaborators, while any changes the user makes to the view state should not be shared.

On the other hand, if I open Sheet 2 and then subsequently decide to share my spreadsheet with collaborators, perhaps I do want them to land on Sheet 2. How do you get that right?

  • The key is to capturing a snapshot of the view state at the instant you share a document, including it with the document, and ensuring that other collaborators start off with that view state. Google Sheets does this by using request parameters in the URL. Every time you change sheets, it changes the URL slightly, so that if you share the URL into with others, that URL knows which sheet you’re viewing.
  • Tableau Online does the opposite. By default, it saves all view state changes to the server rather than to the URL. So if I apply a filter and then share a Tableau view with others, they won’t see the filter applied, so the view state isn’t captured at share time by default. Instead, I can explicitly save a custom view state, which does update the URL, and then share that URL with others. This interaction is more powerful than Google Sheets, but it takes some effort to learn. So while it makes sense for an advanced tool like Tableau, it might be confusing for users of a more casual collaboration tool.