Anynines is a cloud automation company providing Kubernetes and Cloud Foundry infrastructure to regulated enterprises.
MY ROLE
As the sole product designer, I drove end-to-end design across discovery, architecture, prototyping, and design system development.
MY PROCESS
My process began with support ticket analysis, developer interviews, and shadowing debugging sessions to understand real operator workflows.
DESIGN RATIONALE
The core design rationale was to bring the entire diagnostic loop status visibility, log access, and error investigation into one continuous flow, eliminating the need for external tools that doubled resolution time.
Two primary user archetypes were identified through research. Cloud operators need a unified platform to monitor service health and capacity, and developers need to identify and debug problems more quickly. These distinct needs shaped information hierarchy and interaction patterns across the console.
The provisioning flow for a9s PostgreSQL, allowing operators to configure tenant, target, region, replication, plan size, and pricing in a single guided form. This replaced a CLI-driven process where configuration errors were common and costly.
The provisioning flow for a9s PostgreSQL, allowing operators to configure tenant, target, region, replication, plan size, and pricing in a single guided form. This replaced a CLI-driven process where configuration errors were common and costly.
The main monitoring view shows all provisioned services with live status indicators, instance counts, last-modified timestamps, and quick-access resource links. Filterable by status, cluster, and type; designed so operators spot failures without scanning every row.
When a service fails, operators can expand the row to see raw error logs directly in context. This was a core design decision: bringing log access into the service list eliminated the need to switch to external Kubernetes log tools, which previously doubled resolution time.
When a service fails, operators can expand the row to see raw error logs directly in context. This was a core design decision: bringing log access into the service list eliminated the need to switch to external Kubernetes log tools, which previously doubled resolution time.
The deletion confirmation dialog surfaces the service name, current status, impact scope, and recovery information before any irreversible action. Operators in high-stakes environments feared making mistakes; this pattern was designed to slow down destructive actions without blocking experienced users.
The individual service view combines configuration editing, real-time resource monitoring (system, ephemeral, persistent storage), workload trends, and quick actions (restart, stop, delete) in a single screen. This brought the full diagnostic loop, including status, logs, performance, and actions, into one place.
RESULT
In testing, the operators completed the same debugging task 29% faster than with the original interface, with no prior training on the new designs. This also resulted in a significant reduction in support request load.
Read the full case study
HEALTHCARE
Inpatient medication ordering
Approx. 4 min →
under 90 sec
One search replaces three separate lookups
Read more →
INFRASTRUCTURE
Rule creation redesign
25% →
approx 100%
Scope-confirmation success in testing
Read more →
ENERGY
Homeowner installation portal
1 in 3 →
nearly 0
Support contacts caused by silence, not faults
Read more →
