Case study

Designing a new calendar experience for Buffer

Taking a big long term project and breaking it out into small iterations.

The Calendar Feature was built as an MVP around 3 and a half years ago, while I didn't work on the original version I know the idea was to give users a more visual way to plan their content. Back then our customers focused much more on text based content mainly for Twitter.

As successful social media strategies changed to be more focused around high quality media rich content our calendar became less and less relevant and we knew we needed to bring it up to date for our customers, particularly as planning become a more important job.


However in the past we had been stung by working on big lengthy projects that took more than a year to complete, one of which was dropped altogether. So we were weary about taking on such a big project again.

Understanding the value of the calendar

In order to take as much risk as possible away from the project turning into a big lengthly one we set out to understand the core value that people got out of the calendar.


We looked at a whole range of data points include:

  • Usage data

  • Support requests relating to the calendar

  • Customer calls

  • Other solutions both from our competition and what users actually started using once they stopped using our calendar (people love spreadsheets!)

The key things we learnt from our customers where:

They often came to the calendar to answer a question.

  • How much content do I have going out and do I need to create more or can I work on something else.

  • Do I have a good spread of content? I want to make sure I don't have too many of the same post types going out one after another.

We also dug into why people stopped using the calendar, here's what we found.

  • I can't see the post, I'm worried about what it will look like when it goes out and I have to click on each post individually and it's too time consuming to check my content.

  • The drag and drop interaction is buggy and results in me dropping a post into the wrong slot.

  • There's such much wasted space, it's hard for me to get a snapshot of all my posts I have going out.

  • I have to look at each network individually which takes too much time.

Breaking the problems down

From the research we identified 3 clear problems we can tackle:

  • I want to see how much content I have going out to help me priorities what to work on.

  • I want to know how my posts relate to each other so I can ensure I have a good spread of content going out.

  • I want to see how each post will look in a single view so I can make any edits and check for spelling and grammar mistakes.

The solution: What is a calendar anyway?

The first thing we did when creating a new solutions was get rid of the concept of a classic calendar. Most other social media management tools have a calendar but it just didn't make sense in the context of what our users were telling us.


We then focused on creating small relatively quick iterations for each problem:

Help people get a quick overview of what content they had going out

For this problem we create the "mini calendar". This feature was designed to sit alongside their queue and pop up when they wanted to check how many posts they had going out of the coming week. We wanted to go as simple as possible to enable real life usage validate the idea and if it was a success, we'd use feedback to guide future iterations.

Show people how their posts relate to each other

In order to show how posts related to each other we wanted to use a common pattern that we could build out really quick so we went with very simple post labelling. Like the mini calendar we stripped this solution back to its bare bones, only allowing users to select 1 of 5 colours for their labels and we didn't allow the user to add any text. We had two main reasons for taking this approach.

Keeping the feature as lean as possible so we could ship and test it faster.

We didn't want to make assumptions around what the user valued. We didn't know if been able to add text to a label was better than just having a colour but we could use feedback to learn.

Re-think the current calendar to be a more planning focused solution

The first two solutions were small projects that we'd expect to ship in a week or two and get validate relatively fast. But we still needed to solve the problem of having a more robust planning experience. Given the fact that we'd heard that users didn't actually care about the exact time of a post going out and the majority of them were already familiar with their posting times, we didn't see the need for a classic calendar format.


Instead we focused on creating a more media rich experience and in turn reducing anxiety of what the post would look like by mirroring how the post would look on the network. We also wanted to show the user multiple social accounts in one view to save time having to check each profile individually. The first iteration of the planner was designed to be an overview, and in order to reduce scope we had the intention of not making the area editable. In order to make changes to their schedule the user would need to go back to their queue. This was another opportunity to validate an idea before investing a lot of time and resource into a complex drag and drop structure.

Helping with plan differentiation

Originally we had the calendar as a Pro Plan feature, but as we broke down the problem we saw that the main customers who would get value out of the planner would be on our Business Plans and the customers on the Pro Plan would likely get enough value from the Mini Calendar and Tagging features. This was one of the first opportunities to break down our plan differentiation by features as oppose to account limits and team members like we had relied upon in the past.