Case Study — The Setup Wizard
Postman has millions of users who use it for a wide variety of use cases. These could be as basic as manual testing, or as complex as testing a huge workflow in form of connected serial API calls.
Prior to v5.0, some of the more advanced features in Postman were only available with paid plans. These included API monitoring, publishing documentation, creating and using Mock servers. In one of our major releases, Postman v5.0, we made these features available to free users as well.
The Problem Statement
After the release, we had our fingers crossed, hoping that many free users would start using the newly available power features. However, even a couple of weeks after the release, the usage numbers of these features were hardly affected. Puzzled, we started asking our users about why they were not using these. It turned out that these features were designed for advanced use cases, and folks who just wanted to try these out were intimidated by the amount of pre-requisite knowledge required to use them. Then there was the discovery problem. Since most of these features were built on top of other things, not only were they difficult to use but also hidden away.
We decided that we would rethink the existing flows for using some of these features, Monitors and Mock Servers in particular. This was primarily going to be a design task and I was going to lead it.
When we started questioning the choices behind the complexity of the current design, we were clear on one thing. We could not simply remove the complexity without affecting the current set of power users. The alternative was to provide new users with a simplified journey which would not only let them set up the Monitor or the Mock server for the first time, but also help them learn the details along the way.
We set up a simple challenge for ourselves. If we only had a couple of minutes to help a new user set up monitoring or create documentation, how would we do it? We started maintaining a document for FTUX (First Time User Experience) for each feature. In this, we presented the journey from the perspective of a new user who has a real world job to be done.
The document helped us solidify the idea of what we were trying to improve. We reduced our problem statement to simple tasks:
- Let users know they can create Monitors and Mock servers in Postman
- Let them create these easily, without involving Postman concepts they do not understand yet.
- Help them learn how Postman works so that they can handle complexities later.
Similar to the welcome window that a lot of products use, we’d put all our features on display when the app launches. This was a major shift in the interface from being a testing client to an authoring environment. Some of these features were only aspirational to a majority of our users and not something that they were actively seeking. Developers did not care about monitoring their APIs but they knew that it was a good practice. We reasoned that humans are naturally curious and given an easy way, people would want to further their professional skillset by learning how Monitors or Mock servers work.
For the advanced features, we decided we’d break down the flow into three distinct steps
Step 1. Let the user input the information he wants to give, in whatever terms he is comfortable with.
Step 2. Let the user provide advance configuration but make everything optional and assume sensible defaults.
Step 3. Teach the user a bit about Postman and tell him what to do next
- The usage of Monitors and Mock servers went up by 5X immediately after the release. The increased visibility also benefited the number of collection creations (which is one of Postman’s key business metrics) by a small amount.
- Qualitative results — more users now know that Postman offers such products. There was a significant difference noticed in future customer conversations concerning knowledge about monitoring specially.