Designing observability for complex engineering teams.
Company
CodeXray
Role
Product Designer
Timeline
2025–Present
Domain
Observability, API Security
Context
CodeXray is an enterprise observability and API security platform. Engineering teams use it to monitor applications, APIs, databases, infrastructure, and distributed traces — all in one place. The product serves Developers, SREs, and Security Engineers at mid-to-large companies.
I joined as the first dedicated product designer, working across the full product surface.
Problem
Observability products carry a heavy information load — metrics, logs, traces, alerts, incidents, topology, and risk signals all compete for attention. For engineering teams, this density is a given. The design challenge is making it scannable, actionable, and fast to navigate under pressure.
On the API security side, the problem is different: most teams don't know what APIs they have, let alone which ones are exposed or risky. The design challenge is surfacing invisible risk in a way that's credible and actionable — not just alarming.
My Role
As the sole product designer, I own the full design process — from early problem framing to shipped UI. This includes user research, information architecture, interaction design, visual design, and working directly with engineering on implementation.
Product Areas
The product spans several distinct surfaces, each with its own user context and information density:
Application Monitoring
Health, logs, alerts, incidents, and scanability across services.
API Security
Discovery, risk scoring, shadow APIs, PII exposure, and compliance posture.
Distributed Tracing
Request flows, latency breakdown, error propagation, and service topology.
Custom Dashboards
Role-based views for Developers, SREs, and Executives.
Database Monitoring
Query performance, connection pools, and slow query analysis.
Infrastructure
Host, container, and Kubernetes visibility.
Design Challenges
Information density vs. scannability
Observability UIs carry enormous data load. The challenge is preserving completeness while making the most important signal findable within seconds.
Multiple user roles, one product surface
A Developer debugging a trace, an SRE watching an incident, and an Executive reading a risk summary all use the same product differently. The design has to serve all three without fragmenting the experience.
Making invisible risk visible
API security risk is abstract. Shadow APIs, PII exposure, and misconfigured endpoints don't announce themselves. The design has to make this concrete and actionable without creating alert fatigue.
Designing without a design system
Joining as the first designer meant building patterns from scratch while shipping features simultaneously.
Key Decisions
Dark-first UI for observability surfaces
Engineers using monitoring tools in production environments — often in high-stress, low-light contexts — benefit from dark interfaces. Reduces eye strain and improves contrast for critical signals.
Severity-driven visual hierarchy
Color and weight are used exclusively to communicate severity — not decoration. Critical > Warning > Info > Normal maps to a consistent visual grammar across all surfaces.
Progressive disclosure on dense tables
API security and trace tables show a summary row by default. Details expand inline. This reduces cognitive load without hiding information behind navigation.
Role-based dashboard templates as starting points
Rather than a blank canvas, users get pre-built role templates. Customization is possible but not required. This reduces time-to-value for new users.
Visuals
Screenshots and recordings will be added here.
Outcome
The product is actively used by engineering teams at enterprise customers. The API security MVP shipped in early 2025 and is in active use. Custom dashboards reduced time-to-insight for SRE teams. The design system I built is now the foundation for all new feature work.
Specific metrics and customer quotes will be added as the product matures.
Reflection
Working on observability as a designer with an engineering background has been the right fit. I can read a distributed trace, understand what a P99 latency spike means, and talk to engineers about implementation constraints without losing the thread.
The biggest lesson: in dense products, clarity is a design decision made at every level — from information architecture to the weight of a single label. There's no shortcut.