Tyk is an API Management solution, enabling development teams to build a secure, stable and scalable API-led business. This case study looks into the transformation of the keys and policies journey within the Tyk dashboard.
For this project, I was the only UX resource and responsible for driving the project with the developers. This body of work was built for the Tyk 3.0 release.
I wanted to gain as many insights as possible into developers' issues when creating and managing their policies and keys and why they had to rely on help to complete tasks successfully.
With help from the UX Researcher, we collected insights from Freshdesk tickets, the community forum, Stack Overflow, client feature requests, user interviews and industry standards. Finally, we compiled a list of difficulties the developers faced executing policies and keys programmatically and through the GUI and mapped these to the existing interface.
Using the research, we also documented the fundamental goals of our users. Tyk is both a blessing and a curse as it’s such a flexible product, allowing teams to adapt it to their specific use case. But this also means there is often not a standard journey for everyone. Utilising user goals, we mapped the most generic user journey that we could.
We also used this map to ensure all the user goals were achievable. The majority of them were (bar a few micro-interactions), meaning we could concentrate on improving developer understanding of policies and keys and enhancing the current experience rather than adding entirely new functionality.
The saying goes, “you are not your user”, and that’s never been more true than designing developer experiences at Tyk. I can’t even pretend to know why you would choose to authenticate with Mutual TLS? What is the benefit of enabling throttling? Why would I partition my policy? Etc.
We ran workshops with both clients and the internal Tyk teams to understand the motivations behind the various tasks. By understanding the implementation of multiple fields and knowing the motivations, we could recognise themes that could help developers comprehend the interactions needed to manage policies and keys. We then held an ideation workshop in Miro with the UX team and internal stakeholders using 'How Might We' statements to trigger ideas which resulted in solutions to improve existing functionality and ways to boost developer understanding.
With the policies & keys journeys, we went through 4 major wireframe iterations and numerous minor changes to get it to its position today.
Design thinking is not a linear process. It’s important to explore each solution because often, working on them presents a new insight into a more efficient solution. Here is how the ‘Add Policy’ started and how it evolved.
We led the user to choose access rights first - triggering an overlay to set the limits, quota and path-based permissions to add to the policy. We also added informative tips to guide the user in-product.
After user testing, it was clear introducing the overlays was overcomplicating the flow, and staying within the context of the screen would be better. This layout also didn’t solve the issue of keeping the form short and in a logical order.
Another part of the product, the API Designer, uses tabs to group information, so we tried it with policies and keys - separating the access rights from all the other details. With overlays removed, the form was easier to follow. On the access rights tab, information was grouped by API rather than type, meaning that the user could see all information relating to a specific API in a single place.
While this layout was more successful than the previous, it didn’t demonstrate how the API inherited global values or how policy partitioning would work - it needed to be more straightforward.
We moved the global settings out of each API and positioned them at the top of the API list. This kept the global settings in a singular place, so it was clear that they were affecting all related API when the user made a change. It also solved the problem of where to display policy partitioning.
The changes went live during the 3.0 release. We had immediate feedback from client team leads that comprehension had noticeably increased for their developers. Sales team confidence increased by 55% when giving policy and key management demos. Consulting engineer time dropped by 20% for policy and key support queries.
Since releasing the keys and policies update, we have had excellent feedback from our clients:
"He and his team are very happy with the 3.0 release, specifically with the UI improvements in the Dashboard. In addition to the new look and feel, he commented that the policies and keys user experience changes are making it easier for their team members to understand the process flow when setting these up. They're also helping them see the bigger picture of how these pieces integrate into the larger whole."
The majority of our users operate Tyk programmatically. Because of this, the GUI serves different purposes, such as help with onboarding new people to teams, introducing users to new concepts, aiding smaller companies who don't have full development and infrastructure teams in place and demoing Tyk to prospects.
We're applying the learnings from policies and keys into the rest of the product while also evolving policies and keys further. Concepts scheduled for future work include:
Tyk’s start-up environment means that there are often many tight deadlines. We needed to adapt the traditional Design Thinking process to fit the environment at Tyk so that we didn’t miss any crucial steps. So I created the first iteration of the Tyk UX Playbook - a Miro board with prompting actions for each part of Design Thinking to guide you through the process, including links to additional resources. It also includes a ‘safe to explore’ area as well as a developer hand-off checklist.
I was the only person creating UI in Figma, but as the team grew, I realised we needed a Design System to scale. So I worked on the Design System and UX guidelines as a side project at Tyk to become the single source of truth.
It allows the development team to reuse instead of writing code multiple times for a single component. The UX team can iterate quickly by reusing the UI components to build prototypes, validating ideas faster. The designs can remain consistent throughout the Tyk products.
The Tyk GUI is essentially a collection of forms ranging from simple to extremely long and complex. As a result, it was difficult for me to remember decisions made, let alone communicate these to the broader team. So, as I redesigned flows, I devised a spreadsheet to document the fields - the type of field, placeholder text, default states, dropdowns, tooltips and note copy, error validations, error copy, and overall functionality.
The spreadsheet has been successful as developers can refer to the spreadsheet instead of always coming to me. As a result, I remember what I’ve decided, and the wider team can have access to comment or make suggestions for collaborative working.
