Postman - 2022
This initiative focuses on the implementation of native Git support in Postman, a popular API development tool. The goal was to enhance the collaboration and version control capabilities for developers using Postman, enabling them to track changes, collaborate with team members, and seamlessly integrate with their existing Git workflows.
What is the API Builder?
Postman’s API Builder is a place for you to create an API and manage the entire API lifecycle. By connecting to source code repositories, the API Builder automatically maintains API documentation, tests, and specifications alongside the code. With Git integration, developers can collaborate seamlessly by committing changes directly within Postman.
With Postman v9.0, we introduced first-class support for integrating your APIs with a version control system outside Postman, commonly known as API <> GIt integration. This integration is meant to solve for the initial parts of the Postman API Platform.
With the V9 release, we enabled the users to collaborate over the APIs being developed using a Git integration. While this works fine for many use cases, the UI and functionality were limiting. - the users could just edit schema and documentation, and test in it.
Approach
To better understand the needs of developers and assess their current workflow, I took the following steps
Conducted interviews with developers within our organization to gain insights into their API development process and their usage of the GIT version control system. This allowed us to gather first-hand feedback and understand their pain points.
As a designer who didn't regularly use GIT in my day-to-day workflow, I took online tutorials to familiarize myself with GIT and learned how to set up repositories. This experience helped me appreciate the system and empathize more with developers.
Explored various integrated development environments (IDEs) to observe how they supported GIT commands and actions within their interfaces. This research helped us understand the existing standards and expectations of developers when working with GIT.
Personally used Postman V9 to make commits and push changes to my own schemas and collections. This hands-on experience highlighted the limitations of the feature and allowed me to understand the challenges faced by developers using Postman's GIT integration.
Analyzed metrics and collected qualitative user feedback from multiple sources, including research studies, customer success teams, and developer relations (devrel) teams. By gathering feedback from diverse channels, we gained a comprehensive understanding of how users perceived and experienced the existing GIT integration feature in Postman.
Goals for Postman V10:
Native integration of Postman's API Builder with Git, allowing users to keep collections and schemas alongside their codebase and work using their preferred collaborative version control workflows.
Redesigning the API Builder's user interface to align with the API lifecycle, ensuring a smoother user experience.
Streamlining the publishing process to enable easy transition from development to consumer-facing versions. Once development on a branch is complete and merged into the deployment branch, users can publish the collection and schema as a new version in the API Builder. The published API will then be accessible to consumers.
Explorations
Exploration 1
Use the sidebar to display changes in Postman that need to be committed and pushed to the remote repository.
Enable branch switching in the Workbench header.
Exploration 2
Utilize the Workbench header to show changes that require committing and pushing.
Allow branch switching via the sidebar.
Exploration 3
Display changes that need to be committed and pushed in the Workbench header.
Enable branch switching through the sidebar.
Finalised Approach
After speaking to developers and gathering their feedback, we decided to go with Approach 3 and further refined it. We aimed to keep the experience closer to popular Git clients (Sourcetree, GitHub Desktop) and IDEs (VSCode, Atom) used by developers.
Source Control
Branch Switcher
Demo and Release
The feature was rolled out in phases to multiple teams, allowing for gradual adoption and feedback gathering. By December 2022, Postman achieved more V10 Git integrations (3700) compared to V9 (3600) within a four-month duration.
Some feedback from the community
Collaboration with Product and Development teams:
Throughout the project, close collaboration was maintained between the design, product, and development teams. Regular communication and coordination were facilitated through Agile methodologies, daily stand-ups, and collaboration tools like Jira and Slack. This cross-functional teamwork ensured alignment and efficient progress.
The design process for this project involved a state-driven approach, where careful attention was given to the details. I put significant effort into creating a highly detailed design hand-off, which received praise from the developers involved in the implementation, as well as other designers within the organization. The design hand-off format I used influenced other designers in the organization to adopt a similar approach for their own work.
By providing a comprehensive design hand-off, we were able to reduce the time spent on meetings and foster a more asynchronous workflow. This allowed team members to work more independently and efficiently, leveraging the detailed documentation to understand the design decisions and implementation requirements without the need for extensive synchronous discussions.
Final takeaways
Building native Git support into Postman was a big undertaking for the team. However, it was a feature that would make Postman more useful for developers. The aim of this feature is not to replace IDEs but to aid developers in their complete development workflow. Hence, it was crucial to create an experience that was not too dissimilar from the tools that developers already used in their Git workflows.