API Tester Tool
Discover to Production (0-100), Product Design, 2023
Background and Challenge
As Workday's web-based cloud platform, Extend, grows along with it's API capabilities and low-code user base, web-based tools become more and more desired. This is how the need for a web-based SOAP API tester tool that would allow users to test the capabilities of their custom SOAP APIs arose. As a designer with very little engineering knowledge or experience, I was nervous to pick up this project but wanted to push myself to complete my most technically challenging project yet.
How might we create a high-tech tool that is digestable and easy to use for the developer persona?
Approach
Kickoff & Info Gathering
Starting with a design-lead kickoff helped me gather ideas from my stakeholders and align expectations.
Attendees:
-
Product Manager
-
Engineering Lead
-
Developer
Lo-Fi Mockups
Wireframing allowed me to explore ideas and ensure the technical feasibility of my designs in a low-risk manner.
​
I spent about a week going back and forth conversing and ideating in this phase with stakeholders.
Hi- Fi Reviews & Feedback Implementation
A review with organization leadership allowed for feedback concerning the future vision of the feature to be received.
​
This phase is also where the fine details were ironed out and more technical decisions made within stakeholder reviews.
Polish and Handoff
I spent about the last 2 weeks of this project in this phase implementing feedback and polishing up designs before handing off to developers.
​
In our first kickoff the developers on this project team were kind enough to provide me with a mockup they had created, as well as some reference material of existing SOAP API tools. I used these ideas to start on more offical designs. I chose not to start with traditional wireframes so as to reduce time spent explaining components and design decisions to stakeholders, as well as to better translate my ideas into reality.
Early high fidelity reviews with stakeholders and organization leadership was incredibly insightful and allowed me to easily view the pitfalls of the original lo-fi designs. Additionally, listening to the feedback of my fellow developer teammates was immensely valuable because the main persona for this product is the developer. I quickly decided that the many inputs for configuration needed to be stored away into a collapsable card to not only simplify the page but to allow the maximum amount of vertical real estate for the request and response containers.
Listening to the feedback of my fellow developer coworkers was immensely valuable because the main persona for this product is the developer.
In a later iteration, I experimented with a white header (rather than blue). I also went on to design what an expanded container may look like if a user needed a closer look at the API XML or Headers.
Final Solution
The final, polished handoff of the SOAP API Tester included resizable and expandable request and response containers. You'll also see a simplified and more clean header and side panel, as well as a collapsable container for configuration inputs. My biggest challenge was undoubtedly combating the feeling of imposter syndom while I attended design reviews with my stakeholders (all whom had engineering backgrounds). However, I combated this challenge by allowing myself to ask many questions, having 1:1s with my developer teammates, and advocating for myself when I needed more time to digest design requirements.
