Every day, Tyk supports enterprises in highly regulated industries to balance seamless compliance with the efficiency, automation and innovation that fuel growth. Achieving a workable governance framework that supports this isn’t (just) a technical process – it’s about engaging teams in a way that enables everyone to work better together. This is what inspired the creation of the Tyk Governance Hub.
We designed the Governance Hub to help people make smarter calls and improve their security. We wanted teams to stop second-guessing themselves and move ahead with confidence. There were plenty of learnings along the way, which we thought it would be useful to share…
1.Governance is about people and behavior – not just technology
It didn’t take long before we realized that this project wasn’t just about solving a compliance or technical requirement. It was about designing something people would integrate in their workflows and use daily. Our biggest epiphany was that governance is as much an organizational and workflow solution as it is a compliance issue. Putting humans first ended up shaping the backbones of the entire Tyk Governance Hub.
Our initial conversations with Tyk staff and customers revealed that governance definitions differ hugely. Some people linked governance to API standardization. Others focused on compliance measurement frameworks, such as SOC 2 and PCI DSS and HIPAA. Still others viewed governance as policy enforcement or risk visibility.
Clearly, one priority was to address this lack of cohesion and understanding as part of a proactive approach to governance.
Learning: Start by understanding the realities of day-to-day governance. Talk to teams to understand how to make governance transparent, collaborative, and actionable.
2.Collaboration begins with a shared language
One early roadblock was the naming conventions we used for different components. Words such as “policy,” “dashboard,” and “conformance” mean different things to different roles.
Learning: Language shapes understanding and experience. Choosing the right terminology matters.
Through a collaborative workshop and internal reviews, we spent time defining terminology. This guided decisions such as using “compliance” instead of “conformance,” as the former is more widely recognized.
Such choices help individuals and teams align faster, reducing cognitive friction and mental load during onboarding.
3.Design should drive architecture
We wanted to keep a user-centered approach and let design shape the architecture, to ensure technical decisions were grounded in real user needs and flows. From these user flows, roles and early concepting, we defined the core data model, including the API repository, rulesets and rules, reports, connections to API providers, and API categorization.
Today, many products solve similar technical problems, so experience quality, integration fluidity, and trust signals are key to creating something that can become a competitive differentiator.
Learning: Focus on more than how good software is – ask how well it fits into people’s lives and workflows.
4.Flows can define both onboarding and system foundations
Designing the quick start flow for a greenfield project like this was a valuable exercise. It helped us conceptualize and understand the full scope of the project, defining both onboarding and the system’s foundation. It forced us to:
- Define core components (e.g. reports, rulesets, API repository, API categorization)
- Build the mental model of what the core flow of the governance hub needs to be
- Set architectural guardrails for the future
Learning: Onboarding should be tackled as a system-wide design approach that touches multiple parts of the product and organization, not just a single flow.
We occasionally had to step away from the quick start flow to map out the overall architecture, as we kept encountering blockers we hadn’t yet concepted for. This shift helped us think more holistically about the product rather than treating flows in isolation.
5.Choose a narrow, high-value first use-case
Governance is a broad domain: performance, reliability, cost, maturity… We anchored our minimum viable product (MVP) on security risk, because it’s concrete and urgent, fits naturally into a ruleset-based system, and delivers value to clients straight away.
Security gave us a focused way to test the model, with potential to branch out into compliance, maturity, and other use cases down the road.
Learning: Define MVP scope around a real, validated user need.
6.Focus on designing for workflows, not just interfaces
We mapped personas (governance leads, platform teams, API developers, and others) and their workflows, then validated this through external client interviews and an internal workshop and reviews. We asked who owns issues, who fixes them, and who reports them.
This helped us align around the right opportunity statement that we could further ideate on. We focused on how we might provide pre-packaged rules or quick start policies to enable rapid acceleration and value delivery to governance leads and platform teams. Resulting ideas included prepacked/industry standard rulesets for faster adoption, reports that could easily be shared with stakeholders and smart remediation flows (such as applying a fix or opening a Jira ticket).
Learning: Governance isn’t just about checks – it’s about enabling better collaboration and decision-making.
7.Assess emotional responses in addition to usability
In internal and external user reviews and testing, we looked for reactions: confusion, delight, confidence. We didn’t just ask “Does it work?” but “Does this feel empowering?” Doing so helped ensure what we were delivering solved meaningful problems, as highlighted by these feedback examples:
- “This is exactly what I need.” – Client on the governance report
- “This moves us toward building a real API platform rather than just API management.” – Internal stakeholder
- “The fact that I can look at an issue and just simply see the owner, e.g. who to contact, gives such a big value.” – Internal stakeholder
- “If I can see non-compliant APIs at a glance, this is a game-changer.” – Platform lead
Lesson: Pay attention to how users feel about governance.
8.Visibility is the gateway to action
You can’t govern what you can’t see, so a reliable, centralized inventory is essential. The API repository became the backbone of the product and was the first core feature we released with the proof of concept and was refined in multiple ways through usability testing. The API repository covers/will cover:
- A federated view across environments and providers
- Risk visibility and resolution per API (coming soon)
- Bulk actions (coming soon)
- Smart filtering
- API categorization
Learning: Even “basic” tables need thoughtful design when they become central to user workflows.
9.Look further ahead
During the design phase we concepted beyond the V1, producing solid ideas to revisit later. Exploring ideas beyond the immediate scope helped us shape a clear, long-term vision for the product. The non-MVP concepts informed the architecture, helped us test client interest, and provided stakeholders with a good idea of the roadmap beyond V1. The broader thinking shaped the direction without us having to try to build everything at once.
Learning: It’s valuable to sketch and concept beyond the MVP.
10.Governance is a continuous practice
Perhaps one of the most important realizations was that governance is not a one-time action. It’s a daily, ongoing workflow between teams, spanning visibility, assessment, collaboration, action, and resolution.
Lesson: A governance hub shouldn’t just enforce rules, it should serve as a tool to support the practice of good governance.
Embedding robust governance
Our vision for the Tyk Governance Hub wasn’t a boring checkbox compliance tool. We wanted to empower clients to understand what’s going on, what’s at stake, what could go sideways, and what they can do about it.
Forget that whole “big brother is watching you” vibe. Real governance works when people have the power to create and innovate within guardrails that mean they’re not going to break things and don’t need to be watched over constantly. That’s how the Tyk Governance Hub was born.
