Designing a resource governance feature for a Platform Engineering tool, from problem definition to dev handoff, across a product used daily by DevOps teams at enterprise scale.
Cycloid is a Platform Engineering tool that gives IT and DevOps teams a self-service portal to manage infrastructure, pipelines, and cloud resources across multiple teams and environments.
As enterprise adoption grew, a recurring problem surfaced across clients: when several teams share private cloud resources on the same platform, consumption becomes uneven, unpredictable, and hard to govern. Some teams would exhaust shared resources before others could deploy. Others lacked visibility into how much was being used and by whom. For IT leads and CTOs, the absence of limits meant no cost control, no accountability, and no governance.
The ask was clear in broad strokes: give admins a way to control and limit resource consumption. What that actually meant in practice was not yet defined.
I led the design of this feature from problem definition to dev handoff, working alongside the Design Lead and a Technical PM/PO who brought knowledge of the client problem but no defined solution. The final feature scope, architecture, and interaction design came primarily from the design team.
We started with three client interviews to understand concrete use cases and pain points. Three distinct needs emerged: teams competing for shared resources with no fairness mechanism, lack of visibility into consumption over time, and the need to establish governance guardrails to enforce organizational policies and control costs.
In parallel, we ran a benchmarking exercise looking at how platforms like AWS, Humanitec, and others approached resource governance, understanding what patterns existed in the space and where Cycloid could do better for its specific context.
Both inputs, combined with the PM's existing product knowledge, shaped the scope and mental model of the feature.
Rather than designing in isolation, we held a kickoff session with the full team: myself, the Design Lead, the PM, and the two frontend and one backend developer who would build it. Getting engineering in the room early meant technical constraints surfaced before they became late-stage blockers, and the team arrived at handoff with context, not just specs.
The feature we defined has three layers: Resource Pools (groups of physical resources that can be allocated), Custom Resources (the individual infrastructure items that populate those pools), and Quotas (limits assigned per team, scoped to a resource pool). Together they give admins granular control over who can consume what, and how much.
A Quota Increase Request flow (where end-users could request more resources and admins could approve or deny) was designed but excluded from the MVP. The decision was made jointly with the PM after evaluating development complexity against actual user need. It was a clear nice-to-have, not a launch requirement. Shipping without it kept the core feature focused and delivery on track.
The feature spans eight interaction surfaces across the platform: resource pool creation and management, quota creation and editing, quota visibility within the inventory, quota enforcement during project creation, and a feature-level on/off toggle at the organization level.
Particular care went into the information architecture: admins needed to understand the relationship between pools, resources, and quotas without the interface becoming a diagram. The quota list view supports grouping by team or by resource pool, with color-coded usage indicators to surface problems at a glance.
Edge cases were treated as first-class design problems: empty states, error messages, destructive action confirmations, and quota enforcement feedback during project creation all received dedicated attention.
Once the design was complete, we ran a full walkthrough session with the entire technical team (frontend and backend) to present the feature end-to-end, answer questions, and resolve ambiguities before development began. The Figma file served as the living design documentation. The PM handled backend technical specs separately.
The feature shipped, is in use, and fulfills its intended purpose.