Software AG/IBM· Design case study
API Control
Plane.
Our API gateway and Developer portal address traffic management and discovery, but they leave a
critical gap: unified visibility into API and runtime state. Teams can't easily see which APIs are
healthy, degraded, or failing—or understand the state of the runtimes they depend on. Without
this operational view, teams miss performance issues, can't assess deployment impact, and lack
visibility into infrastructure health across environments. No existing product solves this
comprehensively.
ROLE · Senior Product Designer
TIMELINE · Oct 2021 -> Beta May 2023 -> GA Dec 2023
TEAM · PM + Eng Pod
DOMAIN · API Management
0->1
From concept to GA release
1st
Delite 2.0 Product (Software AG Design System)
~80%
Placeholder triage speed gain
100+
Enterprise Customers
00 / 60-
second
summary
Problem, intervention, and outcome at a glance.
Added for senior reviewers who scan first and dive deep second.
Problem
Operators had data across tools but no shared, action-oriented operational truth.
Intervention
Built a relationship-first control model with role-aware paths and in-context actions.
Outcome
0->1 launch, estate-wide visibility, faster triage workflow, stronger cross-role alignment.
00 / Ownership matrix
What I personally owned vs what I partnered on.
Removes ambiguity in contribution depth for lead/staff-level review.
Problem
Discovery
IA + flow
Interaction + UI
Content
I owned
Research framing, synthesis
Information model and navigation hierarchy
Core Features, prioritization behavior, state handling
Initial Content and Terminology Capture
I partnered
PM, Design Manager, Engineering Leads
PM, Engineering Lead
Design system partners, Junior Designer
Content Designers
01 / What is API Control Plane context
I started by understanding the real operating environment.
While the product roadmap called for an API asset management solution, cross-functional teams were misaligned on scope and
direction. Siloed discussions had yielded no concrete conclusions.
Research Methodology
To align stakeholders and establish a shared understanding,
I led my design team through a structured workshop series to
uncover user needs and define deliverables. We designed and
facilitated three workshops: Kickstart (problem alignment), User
Type (persona development), and User Journey (task mapping
and decision-making) to establish a single source of truth for what
we needed to build
This insight became the blueprint for designing solutions that actually solved the problem.
01 / Kickstart workshop findings
What we learned before solutioning
A 13-question workshop aligned cross-functional teams on problem framing, surfaced key unknowns, and established a research-first direction for API Control Plane strategy. To view the orginal workshop whiteboard Click here
13
Discovery questions
7
Assumptions to validate
10+
Knowledge gaps identified
Understandings from the kickstart workshop
CRITICAL
Customers are building fragile workarounds — and paying the cost
Manual tracking in Word/Excel, custom scripts, homegrown CI/CD pipelines, and REST API wrappers. The overhead is "painstaking, time consuming, and error prone."
HIGH
Three user roles identified — but persona gaps were explicitly acknowledged
API Infrastructure Owner, API Provider/Developer, API Product Manager, and API Governer.
HIGH
Critical assumptions surfaced
CP will simplify management, fit seamlessly into existing products, be the cockpit for most API tools, have easy adoption, integrate with any vendor, support heterogeneous environments, and be the "best way of achieving the goal." All marked for validation.
CRITICAL
Not solving this is existential — customers will leave and analysts will downgrade
Dual-track risk: customer impact (complexity, cost, time waste) and business impact (brand erosion, analyst ranking decline, loss to competitors and cloud vendors). "A well deserved pending item."
""Let customers have a single place to discover, visualize, manage, and monitor the assets
(APIs) that are deployed across heterogeneous and distributed environments.""
Six capability pillars emerged from the problem definition
Discovery
Find APIs across heterogeneous environments and track their lifecycle
Visualization
Landscape view of all Data planes, Runtimes, and APIs
Manage Assets
Deploy assets to multiple runtimes from one place
Monitor Assets
API performance, usage, and operational health across data planes, Runtimes
Governance
Global policy enforcement and compliance across all gateways
Lifecycle
Publish, unpublish, promote, and version APIs across environments
I reframed the design challenge around operational clarity—aiming to improve flow reliability, ownership visibility, and decision velocity.
02 / User types & personas
Who the platform must serve.
Persona research identified three user groups with a shared need for a single operational surface, but with different success metrics and task contexts. To view the orginal workshop whiteboard Click here
3
Personas profiled
18
User stories captured
In this workshop we explored deeper into the users General background, Behavious, Likes, Dislikes
Infrastructure Owner
Goal: runtime reliability and platform health.
Pain: fragmented operational tooling.
API Product Manager
Goal: API performance, usage, lifecycle outcomes.
Pain: inefficiency in monitoring and action flow.
API Governor
Goal: policy consistency and compliance control.
Pain: distributed enforcement and correction.
Cross-persona pattern
"Single view" means different domains by role.
Role-aware views are required over shared data.
We focused our initial scope on two core personas: Infrastructure Owners and API Product Managers. API Governance capabilities were intentionally deferred to Phase 2.
03 / User journey mapping
Personas share one platform, but experience very different operational friction.
Both users need a single operational surface, yet their success metrics and daily decisions differ: Infrastructure Owner optimizes runtime reliability; API Product Manager optimizes API performance and lifecycle outcomes. To view orginal whiteboard Click here
2
Personas prioritized
8+
Journey stages compared
9
Top cross-persona issues
Persona focus: Where each user struggles most.
Infrastructure Owner (Primary)
Tracks runtime health, SLA, memory, and gateway state across environments.
Faces onboarding forks between SaaS and non-SaaS setups.
Handles incidents across fragmented channels without unified triage.
API Product Manager (Secondary)
Tracks API performance, usage trends, versions, and deployment history.
Needs API-level context, not infra-level telemetry.
Lacks clear governance and lifecycle controls
"Single view" was common language across both personas, but meant different domains:
infrastructure state versus API product performance.
I reframed the design challenge around operational clarity—aiming to improve flow reliability, ownership visibility, and decision velocity.
01 /
Design direction summary
From research findings to actionable design pillars.
Consolidated design directions derived from Kickstart Workshop, User Types, and User Journey research, grouped into clear product-design pillars. These directions combine strategic framing and implementation guidance, so teams can prioritize what to design now, next, and at scale.
6
Design direction pillars
18+
Actionable guidance points
1
Unified narrative: Research -> Design -> Validation
Final combined design directions.
ROLE BASED EXPERIENCE
Design for persona context, not one-size-fits-all views
Create role-based views over a shared operational model. Keep one platform truth while tailoring entry points for Infrastructure Owner, API Product Manager, and API Governor.
OPERATIONAL FLOW AND ACTIONABILITY
Reduce decision latency from signal to intervention
Unify detection, dependency context, and intervention in one flow. Link monitoring anomalies directly to allowed managing actions in the same pane.
GOVERNANCE AND LIFE CYCLE
Make governance first-class in product workflows
Strengthen lifecycle and governance actions for API PM journeys. Clarify governance versus management boundaries in information architecture.
SCALABILITY, SETUP & INTEGRATION
Support complex environments without operational drag
Simplify non-SaaS setup through guided and reusable configuration patterns. Prefer federated integration when existing telemetry already exists.
ADOPTION AND CHANGE ENABLEMENT
Support complex environments without operational drag
Support onboarding with guided workflows and contextual hints.
Reduce learning curve for cross-role users through progressive disclosure. Build consistent interaction patterns to improve long-term adoption.
LOCATION AWARE MONITORING
Improve regional and runtime decision confidence
Add location-aware monitoring slices (region, gateway, runtime) with fast compare mode. Surface blast-radius implications and regional anomalies earlier.
Design quality for API Control Plane is defined by how quickly users can move from
uncertainty to coordinated action.
I reframed the design challenge around operational clarity—aiming to improve flow reliability, ownership visibility, and decision velocity.
02 / Research findings
Understanding the API Landscape
API – Runtime – Data plane
The landscape represents a comprehensive visualization of all available runtimes and associated APIs across the organisation's global operations. Data planes are nothing but a logical grouping of Runtimes
The above shows how APIs(grey), Runtimes(Green) and Data Planes(Purple) are actually connected. its not a linear relationship but multifaceted
The next steps before final design
Define data
requirements
Identify which metrics matter most to users
Select visualization
strategy
Match data types to effective visual forms
Structure information
architecture
Design layout that highlights key insights
Establish interaction
patterns
Create consistent, learnable user flows
"We know orders are stuck, but we cannot tell which one needs intervention first."
These findings revealed a deeper mismatch between software behavior and operational reality.
05 / Emotion Journey map
I mapped emotional pressure
Emotion journey maps guide where to invest design effort by identifying which features will reduce emotional friction most, while validating that you've solved the real problem rather than just surface symptoms.
Low points = redesign to reduce friction, Neutral points = streamline or add delight, High points = maintain and reinforce,
08 / Affinity Themes
Grouped findings into six recurring problem themes.
Each theme appeared repeatedly across software, team operations, and customer-facing interactions.
Tool fragmentation
Multiple tools and third-party portals per journev.
• Excel used as a bridge between systems.
• No unified operational view
Manual data movement
Frequent copy-paste between stages.
Manual entry of device details.
High risk of data loss during transfer.
Communication overload
Heavy dependence on calls and callbacks.
Customer context not retained consistently.
Follow-ups rely on memory.
Weak knowledge capture
Feedback stored in diaries/sticky notes.
No structured tracking of outcomes.
Low reuse of learning across cases.
Capacity bottlenecks
Single-person dependency in critical tasks.
Manual throughput limits.
Delays propagate when one step stalls.
Install coordination friction
Difficult alignment across customer, installer, delivery.
Location and compatibility constraints.
Repeated re-coordination.
I reframed the design challenge around operational clarity—aiming to improve flow reliability, ownership visibility, and decision velocity.
06 / Final product proposal
I proposed an operational model centered on real-time visibility and clear ownership—enabling faster decision-making and reduced friction.
Based on deep operational research and process analysis, I identified four critical features to optimize the fulfillment workflow:
Unified Operations Dashboard
Provides all stakeholders with real-time visibility into order status at every stage
Tracks ownership and responsibility for all changes and customer feedback (RBAC)
Designed in consultation with product and leadership teams to balance visibility with Dev effort
Enables quick order state searches through advanced filtering capabilities
Integrated Internal Communication Tool
Replaces fragmented personal SIM card usage with a centralized calling system
Automatically logs all customer conversations for quality assurance and performance tracking
Pre-populates caller details from previous interactions, eliminating repetitive information gathering
Structured Feedback Capture
Systematizes feedback collection currently lost across manual notes and sticky notes
Captures customer requirements at each touchpoint (typically 4-5 interactions per order)
Tags all feedback to orders for continuous process improvement and historical context
Barcode Scanning for Device Registration
Eliminates time-consuming manual serial number entry through barcode scanning
Reduces data entry errors and accelerates device registration workflow
After aligning on the proposal, I translated these ideas into the final feature set and UI screens.
07 / Final features and screens
I organized the final design around key moments in the OPS journey.
Add your final feature screenshots below in the order you want reviewers to read them.
Software Issue
Most delay sat between stages, not within stages. Handoffs were the real bottleneck.
Software Issue
Most delay sat between stages, not within stages. Handoffs were the real bottleneck.
Software Issue
Most delay sat between stages, not within stages. Handoffs were the real bottleneck.
Most delay sat between stages, not within stages. Handoffs were the real bottleneck.
Software Issue
Most delay sat between stages, not within stages. Handoffs were the real bottleneck.
Software Issue
Most delay sat between stages, not within stages. Handoffs were the real bottleneck.
Most delay sat between stages, not within stages. Handoffs were the real bottleneck.
Software Issue
Most delay sat between stages, not within stages. Handoffs were the real bottleneck.
Software Issue
Most delay sat between stages, not within stages. Handoffs were the real bottleneck.
After aligning on the proposal, I translated these ideas into the final feature set and UI screens.
08 / What is the impact
I measured impact at operational, team, and customer levels.
This deep-dive explains not just what changed, but why the changes mattered to the business and users.
Operational impact
Order throughput improved from 1,500 to 6,000 per month.
Pending-state turnaround dropped from 183h to 7h.
Delivery cycle reduced from 624h to 162h.
Team impact
OPS team shifted from status hunting to issue resolution
Manager-agent collaboration improved with shared visibility.
Escalations became earlier and more targeted..
Customer impact
Faster activation improved customer confidence and trust.
Reduced delays lowered follow-up uncertainty.
Clearer service progression improved experience quality.
Beyond outcomes, this project sharpened how I approach enterprise workflow design under operational pressure.
09 / What this project has taught me
I learned that visibility is a product capability, not a dashboard feature.
This project reinforced the habits I now carry into every large-scale operations redesign.
Design lessons I carry forward
Map handoffs first; bottlenecks often live between teams, not within tasks.
Prioritize action hierarchy over information completeness.
Use journey + emotion mapping to align stakeholders on where interventions matter most.
What I would do differently next time
Define telemetry and success signals earlier in discovery.
Run structured validation checkpoints per workflow milestone.
Bring implementation constraints into wireframing earlier to speed iteration loops.
10 / Closing reflection
This project changed how I think about design impact.
A short reflection on what this experience taught me as a lead designer.
This project taught me that operational design succeeds or fails on one thing: whether people can see the right problem early enough to act. The breakthrough was not adding more screens, but redesigning how information moved across teams so bottlenecks became visible, shared, and actionable. Watching the OPS team shift from reactive firefighting to confident decision-making was the strongest proof that the work was effective.
Personally, this case sharpened how I lead under complexity. I learned to frame ambiguity faster, align stakeholders around evidence instead of opinions, and turn research into systems that scale beyond a single feature. If I carried one lesson forward, it is this: in high-stakes workflows, great UX is not polish — it is operational clarity that changes outcomes.
09 / How I would redesign with AI in 2026
I would keep the workflow, and add AI at the friction points that caused the most delay.
If I relook this product today, I would focus AI on verification, customer back-and-forth communication, and installation coordination while keeping humans in control of critical decisions.
AI for verification speed
Document pre-checks to detect missing fields, mismatches, and low-quality uploads at intake.
Risk score to flag orders likely to stall before they enter pending loops.
Agent copilot suggesting next best action with reason and confidence.d from 624h to 162h.
AI for communication clarity
Auto-generated status updates tailored to the customer's current stage.
Smart missing-information prompts that ask for exactly what is required.
Conversation summary for agents to reduce repeated questioning and handoff gaps.
AI for install coordination
Recommended installation slots based on availability, travel, and completion probability.
No-show and reschedule risk prediction with proactive re-confirmation.
Fallback recommendation when the assigned path is blocked.
What data I would use first
I would start with existing operational signals already generated by the workflow: stage timestamps, status transitions, document upload states, installer assignment and scheduling logs, and customer communication history. This allows AI support without waiting for a large platform rebuild.
Rollout approach (vision aligned to basic AI maturity)
Phase 1: decision-support AI only (human-in-loop for all critical actions).
Phase 2: automate low-risk actions like proactive status nudges.
Phase 3: optimize queue priorities and coordination recommendations continuously.
Beyond outcomes, this project sharpened how I approach enterprise workflow design under operational pressure.