Refining functionality and elevating developer understanding.

Tyk Policies Dashboard
Tyk Policies Dashboard

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.

UX Design

Figma | Miro
Case Study


Understanding policies and key management presents a hurdle for Tyk’s users (developers), leading them to depend heavily on documentation and consulting engineers. This strain has a ripple effect on the support team and complicates the sales process in highlighting the complete feature set.

Understanding our user’s problems

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.

Platform walkthrough identifying user difficulties.
Platform walkthrough identifying user difficulties.

Understanding our users goals

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.

Sticky notes showing the user goals

Gathering technical information & insights

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.

Sticky notes working through problem solving

Improvements to existing functionality

  • Additional filters for policies and keys tables for faster locating.
  • Error prevention: dynamically change GUI depending on selections to avoid unnecessary errors.
  • Removing ‘-1’ from GUI as a way to disable fields.
  • Align key and policy management so both utilise the same UX patterns.

Ways to boost developer understanding

  • Theming actions so it’s clear what information belongs to which entity, which API inherit global settings and which have their own settings, what path-based permissions are associated with which API etc.
  • Tool tips and direct links to correct developer documentation for additional understanding.
  • Simplifying policy partitioning so it’s clear what aspects of the API the selections are impacting.


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.

Wireframes that show overlays in the dashboard

1/ Overlays

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.

2/ Tabs

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.

Wireframes that show tabs in the dashboard
Wireframes that show the final concept for the dashboard

3/ Separating Concerns

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.


An information architecture and GUI tailored specifically to a developer's workflow and objectives within policy and key management. The redesigned layout eliminates unnecessary complexities and presumed knowledge, empowering developers to troubleshoot seamlessly during their work process, thereby reducing reliance on external support.


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."


UX and Team Learnings

  • Technical consults need to be completed in the early phases of a project to understand product areas better.
  • Further user research is needed to understand real-life use cases so we can cater to them. For example, we knew the general use cases but not for specific components.
  • We found out there is an internal lack of understanding of how components function. You could ask three different engineers about the expected behaviour and get completely different answers. There needs to be a single source of truth.
  • We need to add analytics to gather data on user interactions instead of solely relying on user testing and interviews.
  • The docs provide technical documentation but often don’t explain what something is or why it’s used - could it be that it’s expected in the industry to know that info already? It may be interesting to add use cases to docs so people understand what a configuration can do for them.  For policy partitioning, I wrote additional content for the documentation to make the use cases and functionality clearer.

Furthering the GUI as an educational platform

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:

  • A read-only and edit view so users can scan through complex forms to understand configurations quickly, helping users understand when changes have been successfully saved and reduce errors.
  • Tooltip hover states to keep forms clear and provide users with actionable information that stops them from consulting the documentation for each interaction.
  • Direct links to documentation so users can access the information straight away if they require a deeper understanding.
  • Enhancing the link between the GUI and code files (such as the API definition) so users see the relationship between the GUI and code, allowing users to feel confident when completing the same task programmatically.
  • Improving keyboard accessibility, allowing users to access keyboard shortcuts to quickly find information and complete tasks, similar to how they would in other development software.

Initiatives born from the process

Screenshot of UX Playbook in Miro

UX Playbook

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.

Design System & UX Guidelines

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.

Screenshot showing button UX guidelines in Figma
Screenshot of a spreadsheet demonstrating showing communication with developers

Developer Spreadsheet

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.

Next project