Inigo

Creating an MVP and establishing brand identity

Overview

Inigo is a GraphQL management platform that helps developers monitor, optimize, and secure their GraphQL APIs. It provides tools for query performance tracking, schema management, security enforcement (such as rate limiting and access control), and usage analytics. With features like tracing, error monitoring, query insights, and real-time reporting, Inigo ensures the stability and performance of GraphQL APIs.

My Role

Product designer - user research, visual design, interaction design,
accessibility, development of the design library, implementation review

Team

Shahar Binyamin - Owner
Eric Murphy - PM
Michael Skorokhodov - FE

Timeline

May 2022 - Present

Tools

Figma, FigJam

Discover

Designing the right thing
Before jumping into the solution mode I wanted to connect the customer problems with the business goals. I decided to use the Double Diamond Framework to guide us through the design process.

In this step I analyzed:

Various competitors' products
Customer support requests
Stakeholder interviews
Customer interviews

Business goals

Redesign existing flowsTo enhance user experience.

Create an MVP To validate our initial concepts, test hypotheses, and gather insights from real clients at the early stages of development.

Get customers Developing an Intuitive and Secure GraphQL Management Solution to Drive Customer Engagement.

Top insights from customer interviews

How does Inigo compare to other GraphQL management tools you’ve used? “Compared to other tools, Inigo feels more focused on security and analytics, which is a huge plus, however, it would be beneficial to enhance the analytics dashboard by providing more detailed insights.”

Is there any feature you wish Inigo had or something that could be improved? “It would be helpful if the UI for monitoring API health was more intuitive and provided quicker access to detailed logs. Sometimes, it takes too many clicks to get the information we need.”

What is your primary use case for Inigo GraphQL?“I use Inigo primarily for managing GraphQL security and gateway integrations.”

Explored competitors’ product

After analyzing competitors and customer feedback, we chose to focus on Observability, Registry Management, and Security—areas where existing tools fall short and where customers faced significant challenges. This decision aligns with market gaps and customer needs, giving Inigo a strong competitive edge.

Stakeholder interviews

I've comprehended the stakeholders' objectives, expectations, constraints, and preferences related to the project, ensuring they align with both business goals and user needs.

Define

Defining the core design challenges
After the first stage, I started filtering through all the information I'd gotten and elaborating on it to define the main problems and the design challenge.

User personas

Sarah, 32 years

Software Developer

Background: Sarah is a seasoned software developer working at a tech startup. She specializes in backend development and is responsible for building APIs to support the company's web and mobile applications.
‍
Goals: Sarah wants to optimize the performance and flexibility of the APIs she develops. She's interested in using GraphQL to simplify data fetching and manipulation, reduce over-fetching and under-fetching issues, and improve overall developer productivity.
‍Pain points: Sarah finds that traditional RESTful APIs can be rigid and inefficient, especially when it comes to handling complex data requirements. She's looking for a more dynamic and efficient way to query and manipulate data from her applications.

Alex, 41 years

Frontend Developer

Background: Alex is a frontend developer working at a digital agency. He's responsible for building user interfaces for various client projects, ranging from e-commerce platforms to content management systems.
‍
Goals: Alex wants to streamline the process of fetching and managing data in his frontend applications. He's interested in using GraphQL to empower client-side applications to request only the data they need, reducing unnecessary network requests and improving performance.
‍Pain points: Alex often finds himself dealing with over-fetching or under-fetching data from RESTful APIs, leading to inefficient data transfer and slower application performance. He's looking for a more efficient way to fetch and manage data in his frontend applications.

Emily, 28 years

Product Manager

Background: Emily is a product manager at a large technology company. She's responsible for defining product requirements, prioritizing features, and ensuring that the development team delivers high-quality products that meet user needs.
‍Goals: Emily wants to ensure that her team can iterate quickly and efficiently on product features. She's interested in using GraphQL to enable more flexible and iterative development workflows, allowing developers to make changes to the API schema without disrupting frontend implementations.
‍Pain points: She's looking for a more collaborative and agile approach to API development that can support rapid iteration and experimentation.

Primary process flowcharts

I've used flowcharts to visualize, analyze, and improve processes. They help identify inefficiencies and enhance communication among team members.

Design strategy

Aaron Walter's Hierarchy of User Needs

Build functional, reliable, usable UX
‍This step involves creating essential tools for managing GraphQL, such as schema management, query optimization, real-time monitoring, and robust security measures.

Focus on the usable part for Inigo customers
Our goal is to build an intuitive interface with clear navigation, concise instructions, and helpful tooltips to make it accessible for all users.

Delight and make it pleasurable:
‍This step is about making the interaction with Inigo delightful.

Develop

Designing things right By collaborating with developers early in the design process, I ensured that less problems would come up during the implementation as we were able to discover technical limitations of which we couldn't have known before.

What did we have before?

The incomplete prototype failed to deliver the contextual user experience our customers required.

Mid-fidelity exploration

By collaborating with developers and stakeholders, I prepared a mid-fidelity prototype that outlines the main flow for service creation, GraphQL Observability, Schema Management, GraphQL Security, and Explorer.

High-fidelity exploration

After the mid-fidelity, I proceeded to the next step in which I designed a high-fidelity prototype and got team feedback.

Feedback from developers and leadership

We kept the Explorer page simple for now, but we'll add features such as a Query Builder, History, Collections, and Connection Settings in future updates.

To optimize development efforts, we decided to implement the Save filter option in the next iteration.

We opted not to include a Config page due to the lack of necessity and the absence of any customer who would benefit from it.

Deliver

Ensuring the final product works well
Once the product was delivered, we began collecting customer feedback and monitoring key metrics. The response was overwhelmingly positive, leading to the acquisition of new customers.

Performed design review

Following implementation, I conducted a design review to verify that the design met the project goals. I assessed key aspects like usability, functionality, visual appeal, and compliance with project requirements, making adjustments as needed. Additionally, I ensured the design stayed aligned with the approved version I created.

Collecting customer feedback (Slack)

It's difficult to identify the columns that are filterable in a table (Observe page)

Filterable columns are presented as links, lacking a distinct filter icon, similar to columns that trigger the opening of a sidebar.

Idea

In line with the 'Recognition over Recall' usability heuristic, I recommend including a filter icon next to the columns that users can filter.

Customer interviews (Zoom)

Long onboarding process

Customer interviews uncovered that the 10-step onboarding process is overly lengthy and confusing, hindering service setup.

Idea

Segment the steps into those essential for getting started (Create a service) and those that can be configured later (Set up Slack alerts)

User sessions observation (Sessionstack/Fullstory)

Lack of response

The issue arises from the absence of any feedback or visual indication when a filter is added. From a user-centric design perspective, the absence of a notification when adding a filter creates a disconnect in the user experience.

Idea

Following the Visibility of System Status heuristic, include a notification to indicate the successful application of the filter.

Main customer problems

Confusing and hard to use filtering

This lack of clear visual cues can lead to confusion and frustration, as users may not immediately understand how to filter the data presented in the columns.

Lack of response

Without a clear confirmation from the system, users may question whether their filter has been applied, resulting in a breakdown of user trust and a less intuitive user experience.

Long onboarding process

The problem lies in the onboarding process being overly cumbersome, making it difficult for users to progress through the steps smoothly.

What did we have before?

Overly complex and long onboarding (Getting Started) process.
Confusing and difficult-to-use filtering, along with a lack of responsiveness.
The Explorer page does not fully address customer needs.

Enhanced the Explorer page

I improved the Explorer to be more functional and user-friendly, aligning it closely with competitive standards. This enhancement boosts usability and provides a more intuitive experience for users familiar with similar platforms.