Learn from your mistakes: what you learned in the process of creating a buffer

Buffer is an application that helps you publish content more efficiently on platforms such as Twitter, Facebook and so on, so far we have more than 500,000 users. When we first started building this product two years ago, we were fully prepared to face challenges, including the obstacles and possible mistakes in the design and development process.

We have always felt that it is inevitable to make mistakes in the project, and as long as we can learn something from them, these mistakes will lead us in the right direction. To some extent, it may be the mistakes of the way that push our products a little to success.

Important principles of design

Before we begin to discuss the experiences we have learned from our mistakes, I would like to talk about one of our important design principles:

First verify, then develop.

What's going on here, then?

We created the buffer by creating a "smart" way for users to be more efficient at synchronizing content in social networking platforms such as Twitter. The idea just popped up, and our founder, Joel Gascoigne, immediately began writing code, rather than validating the idea first. After writing for a few minutes, he realized that it might not be the right way.

Next, Joel creates an introductory page for the currently nonexistent product and spreads the links on Twitter. Potential users who are really interested in the idea will come to the introduction page via a link, and after they click on the "Service options and Prices" button, the next page will tell them that the product is not finished yet, please leave the mailbox to be notified at the first time after the product is online.

From this incident, we gradually summed up in the course of the following three points of the most important design principles and experience:

1. The first edition of the entire product or a new feature should be minimized as much as possible.

2. Prepare psychologically: The project is likely to be long-term and involves multiple transitions.

3. Any new ideas and ideas need to be validated first.

After talking about the overall experience, I'll go through some practical examples to give you a more specific description of what we've learned in the project.

Lesson One: The process should focus on "user retention" rather than revenue

As for the user experience, the important lesson we learned early in the project was to focus the process on "user retention (user-retention)" rather than generating revenue.

How do we know this? Let's take a look at the initial version of the registration process after the buffer line:

1. After clicking on the "service Scheme and price" button, the user will be led to a page describing the specific service type.

2. On this page, users need to make a choice in a free or paid solution.

3. After choosing the service type, the user needs to fill in the user name, the email address and so on to complete the registration.

At that time, there are many users will choose to pay the scheme, it is not a bad thing to go completely. But we soon found that the wastage rate for users who chose to pay for a product before they actually used it was very large. Some of these people rarely use products after paying, and some even unsubscribe from paid services.

So we tried to modify the process, the user is not required to make a choice of options; we say to ourselves: "or first let the user experience the product and judge the value of the buffer, and then encourage them to upgrade to the appropriate payment version after the formal use." ”

The modified process is what you can now see in the buffer site: users can login directly through their third party account and experience all the features of the free program, completely seamless and instantly begin to use the product.

The redesign of the related process resulted in two results:

1. More people are starting to use our products because we have removed the service Options page and associated registration process, reducing unnecessary barriers.

2. There are more people who have been upgraded to paid programs because they can get into the use state very directly and easily, discover the value of it and decide to pass it alongside us.

Later, we made a lot of improvements to the product, including the addition of more free features, and the core features of the product is always free. Only when we are sure that the user has experienced enough value will we recommend a paid upgrade plan to them.

Focus on user retention, which is an important lesson we have learned.

Related reading:

Progressive attraction-Lets potential users understand the product and complete the transformation in practice

Design principles and creative elements of the "coming online" page

Lesson Two: Social login is more effective than traditional email login

In order to improve the conversion rate in the homepage, we have done a lot of attempts, and conducted a series of A/b test, the result is not very ideal. Ultimately, we decided to try the social login approach, which allows users to log in directly via their Twitter, Facebook, or LinkedIn accounts.

After all, this product is designed to make it easier for users to sync content in Twitter, Facebook, and LinkedIn, so it's logical that users can use buffer directly from their related accounts to reduce unnecessary hassle.

For the sake of contrast, let's look at the traditional registration method that buffer uses before using social login:

This change has greatly boosted the user's growth, the conversion rate has increased by nearly 50%, in fact, on the day of the switch to login mode, the daily growth from 500 to 800.

Lesson three: Early validation of every hypothesis

We used to have an idea of redesigning the browser plugin, which ultimately failed miserably.

Browser Plug-ins are an important part of the entire buffer product, it can help users directly to the content of the Web page to add to their "buffer" and share the social platform, the overall experience is great.

So naturally, we're going to focus on the browser plugin, hoping to improve it as much as possible to achieve some cooler ideas. But in the process of improvement, we seem to have picked up some bad habits of the past and made some mistakes that should have been avoided. The steps at the time were this:

1. We identify some of the problems in the Buffer browser plugin, brainstorm where to improve.

2. Next, we spent a lot of time and resources to redesign and develop a fully functional new version of Plug-ins.

3. After the completion of the test, we found that the new version of the plugin to the user caused great confusion.

4. Eventually we decided to give up this version of the plugin.

What you see in the image below is this failed work that never goes online:

It can be said that it is this defeat let us "early verification of every hypothesis" principle is deeply imprinted in the mind, become a habit in the future.

Now, when we are going to improve our products or implement some new features, we will do this by using the following steps:

1. Identify existing problems and identify the points that need to be improved or added.

2. Communicate with existing users to see if they have encountered these problems in the course of their use.

3. After the initial verification of the idea, the rapid production of wireframe draft or low-fidelity can interact with the prototype.

4. Communicate with the user again, show them the prototype, observe their interaction behavior.

5. Repeat this process until the final design is finalized.

6. Keep track of various indicators, maintain communication with users and verify the performance of new products.

Lesson four: Clear and understandable UI Copywriting

I've been thinking about this for a long time: for UI elements such as headlines, buttons, hints, and so on, when the conditions allow, use clear text as much as possible, rather than other forms that appear to be smart but that give the user a cognitive burden.

The Intercom des Traynor defines the problem in an article:

You create great functionality for the user's actual needs, but find that they are not using it at all. Most of the time, this is because the user does not see the feature, or even notice it, but do not understand what it does.

This is a problem that we often encounter in a project. A very representative example: in the buffer, you can integrate your own accounts in a number of social platforms and focus on publishing content. For example, you may need to add Facebook and LinkedIn accounts to your Twitter account, as shown in the following illustration:

We used to think that using a plus sign to guide users to add accounts is a very smart thing to do.

But that's not the case, we keep getting emails from users asking how they can add their other accounts to the buffer.

So we made some improvements, such as using a larger plus sign icon, and some minor tweaks like that. But the last and most effective solution is very simple: Use the "Connect more account" copy instead of the plus button to make the message clearer and more effective.

In this case, we realize that even if we need to make sacrifices in appearance, we have to choose a solution that is clearer to the user than looks cool.

Related reading: How to effectively enhance the user experience through UI-assisted instruction text

Summary

We believe that our company and the buffer product are still in the early stages, so even now many design processes and methods may still be experimental and need to be validated.

For us, the greatest inspiration from the previous process is that we are not dependent on an idea, but rather that each new feature new design is considered to be an assumption that needs to be validated.

We have plans to implement more ideas and more interesting features, but we are also prepared to throw most of them away. We believe that from a long-term perspective, such a way of thinking can help us create products that users really need.