Improving Ownership & Release Control with Module-based Registry Management
Timeline
12 weeks
Role
UX designer
Team
UX designer, Product owner, Tech Lead
Long story short
I led the vision for a new way to help engineering teams manage shared registries with clarity and control.
I partnered with Tech Architecture and Product to design a solution that reduces ownership confusion, improves traceability, and prevents uncontrolled deployments. Key accomplishments included:
Design
Owned the design for a new “Module Release” feature that separates registries by app/module, enabling teams to release independently—with override support when needed.
Team Collaboration
Collaborated regularly with Product and Tech to shape requirements, align stakeholders, and define sprint goals supporting the product roadmap.
How might we help multiple teams use a shared registry with clear ownership, auditable change tracking, and controlled deployments?
Speaking to user
I conducted contextual inquiries with SiteManager users to understand how teams publish changes and manage releases when multiple teams share one registry. I watched users complete real tasks (ship changes, review updates, resolve conflicts) and asked questions as they worked to uncover handoffs, decision points, and workarounds.
Method: Contextual inquiry (live observation + probing questions)
Format: 45–60 min sessions, In-person
Participants: Developers (module owners), Platform/SRE, Release owners
Interview Questions:
1. Walk me through how you publish a change to the registry in SiteManager.
2. How do you know who owns a module or section of the registry?
3. Where do you look to understand what changed and why?
4. How do you test and release only your changes today?
5. What happens when two teams make updates that conflict?
6. Tell me about a recent incident caused by a shared registry update—how was it triaged and resolved?
7. If you had full control over your module’s release process, what would “ideal” look like?
Opportunities
I guided my team to four main feature areas for the MVP
Based on user research and recurring pain points, we focused the MVP on ownership clarity, traceability, and safe, independent releases.
Module-Based Registry (Segmentation)
Separate the shared registry by app/module so teams have clear boundaries and can work without stepping on each other.
Ownership & Access Controls
Make module owners explicit and enforce permissions (who can publish, approve, override).
Audit Trail & Change Tracking
Provide an auditable history (who/what/when/why), plus easy ways to review changes before they ship.
Release Controls (Module Release)
Let teams release independently, with approval gates, safe overrides, and support for rollback when needed.
User flow
Defining feature concept
I brainstormed three main feature that would bettter solve the proble from research
Module widget in app
Teams can add multiple modules within an app, edit/delete modules, and view a change log to track updates over time.
Create Release
Users can select components for a specific app/module and create a release—so teams can ship updates intentionally instead of bundling changes.
Module Release Page
A dedicated page to manage module releases end-to-end: review changes, confirm ownership, and control when/what gets deployed.
Final flow
I brainstormed three main feature that would bettter solve the proble from research
Impact
Clear ownership: teams know what they own and where to make changes.
Autonomous releases: teams can ship on their cadence instead of bundling changes.
Fewer conflicts + safer deployments: improved change visibility and release control reduces “silent breaks."
Faster troubleshooting: change logs/audit trail shorten time to identify the source and owner of an issue.
Success Metrics (New Design)
Before (Old Registry
After (Module release)
Registry releases per month
Conflict rate in registry releases
Automated rollback in QA/Stage
3 - 4
~7 out of 10
Not available
8 - 10
~1–2 out of 10
100% rollback capability
Qualitative Usability Test Metrics
User satisfaction score: 4/5
Task completion rate: 95%
Positive feedback: 8/10
What I learned
Observing real workflows beats assumptions. Contextual inquiry surfaced hidden handoffs and manual workarounds that wouldn’t show up in a standard interview.
Autonomy needs guardrails. The best solution balanced team independence with governance (permissions, review gates, override path).
Designing for trust matters in platform tools. Clear “who changed what and why” is as important as the UI itself.
Alignment is a feature. Early partnership with Architecture/Product prevented rework and made the MVP feasible within real constraints.