Category: Integrations

• User problem
  • As a developer working with APIs, I want to debug API requests/responses with my colleagues where our communication happens so that I can get support and unblock myself from getting a successful response.
• Business goals
  • Increase the amount of users with the Postman Slack App installed
  • Increase # of users on teams & collaborating in teams in Postman
• Constraints
  • Our system does not store responses to the server, so figuring out how to land users back into the product with the response loaded is a challenge that we have to work with the API Client team on.
• What flows did we need to think about?
  • How would User A grab a link to the response to share in chat?
  • How would the link unfurl look like when User A pastes the response link in my chat tool?
  • How would User B go about opening up the request in Postman with the same context that was shared by User A?
  • Once User B fixes the request settings, how would they go about sending that back to User A?
• Many stakeholders
  • I learned how to navigate in a design problem space that affects several different product owners and find the middle ground design solution that everyone was on board with
  • An integration tool that touches product concepts across more than one squad means that you have to be able to align all parties with the desired solution.
    • Workspaces team was working on a new Share request experience that would allow you to manage who has access to this particular request
    • The API Client team was against adding more “UX bloat” in the response area, as they feel that this has become a dumping ground for many different actions that don’t necessarily relate to the response.
    • Explain how we eventually got alignment on the final solution
• Design solution
  • Show the slack unfurl design
  • Show early iterations of options for in-product copy link placement and include feedback on these options from the teams that hold stakes in this experience.
  • Show the finalized solution for the in-product link share experience
• Pre-requisites
  • Myself and the API Client team soon realized the need to somehow make the response available in Postman to User B who clicks on the unfurl message to help User A debug. This resulted in the team deciding that we should somehow connect request history to the shared instance.
• What information should be shared in the response unfurl?
  • After talking to users, we at first thought that it would be best to share the whole context of the response, including request URL, headers, and body if applicable, along with the response status code, time, size, and json body.
  • However, there were some concerns about complexity in showing everything in a chat-based tool when the user should really be viewing the information in Postman, where it will be much easier to read. We do want to make sure that this drives people back into the product to encourage collaboration in teams, so we decided to only display the request URL as a string and the response body along with response metadata.
• Questions around security when sharing response data
  • There were questions around transmitting sensitive data and displaying it in a chat tool, but we are making the assumption that if you intend to copy a link to a response and share it that you expect the response to share in the chat context and know the risks when sharing sensitive data. We will be following up with our users on this as well.
• Outcomes
  • TBD
• Next steps
  • Gather qualitative research of this experience and ask users about the usefulness and usability
  • Monitor data of how these changes affect primary metrics