← all work /contact
work/otterize/ciem

CIEM for DevOps Teams

A developer-first Cloud Identity & Entitlement Management platform, making service-to-service access in Kubernetes visible, explorable, and safe to change.

roleSolo Product Designer
teamEmbedded with eng & CTO
timeline2023 — 2025
outcomeAcquired by Cyera
app.otterize.com / access-graph
Otterize Access Graph
01 / context

A deeply technical product, with a deeply human problem.

Otterize is a developer-focused IAM platform for Kubernetes. Its flagship feature, the Access Graph, visualizes service-to-service permissions in real time. Complex infrastructure data, rendered so you don't want to close the tab.

// my realityI was the only designer on the team. No design lead, no handholding. Just me, a whiteboard, and a CTO who trusted that good design could move the needle.
otterize / full-product-demo

The product in motion, including the Access Graph I designed

02 / working_style

I didn't wait for a seat at the table. I built the table.

Every week, Ori (CTO) and I sat down and figured out what actually mattered: what to ship, what to cut, what a customer was waiting on. I wasn't a ticket executor. I was a thinking partner.

[01]

Weekly CTO sync

Align on what's real, not just what's queued.

[02]

Decide what matters

Prioritize against customers & sales reality.

[03]

Design & ship

Sometimes a new feature within days of a call.

↻ repeated weekly: design embedded in the decision, not downstream of it

03 / research

PostHog doesn't lie.

I used session recordings to watch real engineers try to use the product. Not in a lab, in the wild. Those recordings shaped most of my biggest redesigns.

// the signalThe hesitation before a button click tells you more than any survey ever will.
posthog / session-replay
REPLAYengineer · prod
Session replay of the Access Graph

Real engineers: confused, clicking the wrong place, giving up mid-flow

04 / process

Prototype first. Spec never.

I stopped writing specs early on. Instead: prototype, share with eng, adjust.

  • Devs could see the actual flow, not a paragraph describing it
  • They could poke holes and flag what was technically impossible
  • All of it before anyone opened a JIRA ticket
ciem-flow / prototype

Prototyped before a line of code was written

05 / engineering

I showed up to the standups.

Design doesn't end at handoff. I joined implementation reviews and caught the things slipping through the cracks.

// shared vocabularyComponent names, states, edge cases, built together, so "pixel-perfect" actually meant something.
figma / components + feature-pages
Figma design files overview

One source of truth: components, states, and feature pages, ready for dev

06 / the_win

The Access Graph. From cluttered to explorable.

✓ design win
app.otterize.com / access-graph
Access Graph before redesignAccess Graph after redesign

what_i_changed

  • A card-based visual language for scannability
  • Grouped by cluster & namespace, collapsible with contextual filters
  • Structured columns that make directional flow intuitive
  • Standardized spacing, color & icons, built to scale

the_payoff

Faster insightLess time to read the graph
Easier onboardingFor non-dev stakeholders
Scalable patternSupported future features
Less noiseRare toggles moved out of view
08 / takeaways

What I actually learned.

[01]

Clarity is an outcome

The Access Graph taught me clarity is something you design for, never a default you inherit.

[02]

UX debt is quiet

The popup taught me debt isn't born in bad design. It's born in good intentions, accumulated silently.

The best decisions I made at Otterize were the ones where I pushed back, slowed down, and asked: are we solving the right problem?