Recently, I have had the pleasure to play a part in the launch of RapidAPI’s latest product, RapidAPI Studio.For the first time I wasn’t just working alongside engineers, but also designing products for them as my users.

Problem

Testing, sharing and monetising APIs can be very difficult. Engineers have to use multiple platforms and applications to make sure they get a quality API in their users hands. This takes a long time and as a result, slows down the speed for which people can build amazing software.

Solution & Results

An easy, fast, and robust tool for everything you can do with an API. With RapidAPI Studio, you can build, test, consume, manage, and monetize your APIs, all through one connected experience. That connected experience extends to everywhere RapidAPI Studio is available, including the web, native app, or directly in your preferred IDE (including VS Code).

My involvement and designing for engineers

I joined Rapid three months prior to the launch of Studio, this meant I unfortunately wasn’t able to shape the core architecture of the product such as information architecture. However, this provided me with a great opportunity to gain core experience in the later stage of product development such as the design of micro interactions and UI. The majority of my time spent working on Studio saw me porting existing functionality from our other products, or optimizing new features that had been proof of concepts pulled together by engineers.

To truly be able to design great experiences for engineers, I first had to understand the technical side of our product. This meant upskilling myself to be able to communicate the many technical intricacies of API design and testing. This was achieved through much technical reading and getting hands on with building and managing my own API.

Once better technical knowledge about our product was achieved, I found myself having to rethink a lot of my knowledge towards traditional user behavior. This insight was achieved through many gorilla testing sessions that were performed to not only find flaws in our existing product, but to also test new features.

Engineerign personas tend to think in a much more logical flow that is optimized for the performance of the output rather than the performance of the flow itself. This means their expectations are much more specific and nuanced due to their preference of technical means over initial function. This can often be seen in many products made for, and often by, engineers.

Once I understood this, I opted to shift my ways of working to be much more technically oriented around collaboration with engineers rather than simply just handing over a proposed solution. This process was often reflected in myself breaking down and optimizing pre-engineered solutions in constant collaboration with an engineer to make sure that technical features were not being neglected purely for streamlined UX. An example of a finalized solution for a feature within Studio can be seen below.

My time spent working on Studio has seen me upskill my own abilities and modify my ways of working with tremendously positive results, all within an incredibly short period of time. The output of this is that the product ultimately encapsulates micro experiences that are tailor made for an engineering person, whilst still having a balanced consideration to great user experience.

Thank you for following me through the story of my time working on Studio. Please do get in touch if you have any questions about this piece of work, or would like to see anything on show here in greater detail.