Service ownership, feature state, content readiness, and QA progress were difficult to compare.
Back to projects
Case study 03 / Service management
Zero gives teams a shared map of services, features, and release readiness.
A service and feature management system for product managers, content teams, and QA, designed to clarify ownership, dependencies, deployment status, and release confidence.
Overview
A service and feature control layer for product, content, and QA teams.
Product managers, content managers, QA teams, operations, and feature owners.
Product architecture, workflows, dashboard design, interaction patterns, and UI system.
A shared workspace for service visibility, readiness checks, dependencies, and launch decisions.
Challenge
The system had to align different teams without flattening their workflows.
Product, content, and QA teams look at the same feature from different angles. The challenge was creating one system where each team could see its own work while still understanding the broader release picture.
I designed around status clarity, ownership, filtering, and readiness signals so teams could move from scattered updates to a single operational view.
A shared control surface for release readiness.
The main board turns service status into a working model: teams can compare environments, detect blockers, inspect ownership, and move from high-level health to specific deployment evidence.
Flow in motion
Operational flows that connect service status to release evidence.
Deployment evidence
Connect service cards to Jira context.
The flow shows how teams can move from service health into related deployment work without losing the board view.
Process
From fragmented status tracking to a clear product operations model.
01 / Research
Mapped team responsibilities, release blockers, repeated checks, and visibility gaps.
02 / IA
Defined the hierarchy for services, features, ownership, readiness, dependencies, and QA states.
03 / Flows
Designed paths for service setup, feature review, QA approval, and launch tracking.
04 / System
Created reusable cards, status chips, filters, checklists, and operational detail views.
05 / Prototype
Validated scanability, empty states, role-based views, and dense dashboard behavior.
One service model
Created a shared structure for features, owners, content state, QA state, and release readiness.
Role-aware views
Designed views that support different teams while keeping the same underlying service model.
Readiness over reporting
Shifted the UI from passive status reporting toward visible next steps and blockers.
Final experience
Screens that make service health, feature progress, and ownership easy to scan.
01 / Deployment evidence
Keep service health connected to the work behind it.
The Jira deployments drawer lets teams move from a service card into linked tickets, statuses, summaries, and related work without losing the broader board context.
02 / State comparison
Make environment changes explicit before they ship.
A focused state modal compares active and alternate services so release owners can review what will change, select the right services, and confirm with confidence.
03 / Feature inventory
Turn feature rollout into a matrix teams can scan.
The feature table maps feature names, groups, environments, values, and scheduled variants so product and content teams can see rollout differences at a glance.
04 / Configuration model
Expose complexity without making setup feel chaotic.
The feature configuration view organizes type, status, values, dates, expired states, and environment rules into repeatable panels for faster review and updates.
05 / Geographic targeting
Make regional rollout decisions visible and reversible.
The location selector pairs a country list with a world map so teams can understand mixed states, selected regions, and value assignments before updating an environment.
Impact
A release operating model that made service deployment easier to inspect before production.
Replaced a fragile two-environment workflow with a clearer Red, QA, and Green release model, while still allowing additional environments for focused testing.
Gave product, QA, developers, and release owners a shared view of each deployment: connected services, feature work, owners, deadlines, blockers, and related tickets.
Improved release confidence by making bottlenecks, dependencies, and environment readiness visible before work reached production.
The workflow moved from alternating environments into a clearer path for development, validation, and production release.
Teams could open a deployment and understand its linked services, feature work, Jira context, owners, developers, lead, deadline, and blockers.
Status, dependencies, and environment readiness became visible earlier, giving teams more room to test and resolve issues before production.
Next case