Brief

This project challenges how 'variables' (containers for reusable and dynamic values) are defined and interacted with within API consumption practices and programming at large.

The solution addresses developers' problems with using variables during API execution. The new interface simplifies and speeds things up by reimagining the variable experience from scratch.

The new variables experience allowing users to view all moving parts of an API request at a glance and pass/update values on the go.

My role

Project owner, Designer.

Project span

6 months, including engineering.

Existing experience of variables in Postman

The former variables' experience in Postman was modeled precisely per the construct of variables in popular programming languages like JavaScript. Users had to define the variables and their values in a scope such as Collection, Environment and Globals to use them in an API request. The scopes represented the context in which a variable can be used, similar to the global and local definition of variables in JavaScript.

To edit the value of a variable, users must visit the associated scopes and return to the API request to execute it with the new value.

A resolved variable– An orange text color means a variable belonging to a scope (environment, collection or globals), irrespective of whether the variable carries a value. So, even if a variable is resolved, it can still cause the request to fail if it doesn’t contain a value.

An unresolved variable- Represented with a red highlight, it means a variable that doesn’t belong to a scope yet, similar to ‘undefined’ variables in popular programming languages like JavaScript.

Scope- A scope is like a container for variables. Variables need to be defined in a scope to be used. If users want to change the value of a variable, they have to do so by opening the scope and editing it there.

User Feedback

I browsed through Postman’s support dashboard for user posts tagged with the label variables and sorted 13 issues that asked for a simpler experience. Those tags were assigned to the posts by the customer success team at Postman. Intersecting them indicated four broad themes of friction:

• Using a variable is synonymous with having it in a scope. This is counterintuitive for iterative testing, where the API is tested against multiple different values before a value is finalized.
• Variable values are transient even when scoped. Opening the scope to update a value is a long journey that is not optimized for frequency.
• An API request can require multiple values to be present before being sent, but there’s no easy way to cross-check the variables used in a request and the values and update them if need be.
• An API request can contain values that cannot be predetermined and must be passed by the API consumers before sending. Until now, there has been no way to define such values through variables and indicate consumers for passing them.