Context + role
Project: IBM Multicloud Management Platform
Role: UX/UI design
Timeline: 6 weeks
Team: 3 UX designers, 1 content designer
Contribution: UX research, team leading, UX and UI design
IBM Multicloud Management Platform (MCMP) helps organisations manage applications and infrastructure across Kubernetes clusters and multi-cloud environments. It supports activities such as application deployment, governance, compliance, and policy management across multiple cloud providers.
The challenge was significant: none of our team had prior experience in the domain, we had only six weeks to research and prototype a solution, and half of every working day was dedicated to IBM Design education sessions. We needed to quickly understand a complex enterprise ecosystem while producing a credible design direction.
My role focused on research facilitation, client workshops, sponsor user interviews, problem definition, and co-authoring the Hills that ultimately guided the team’s design direction.
The problem
“Accelerate time-to-market by improving the co-creation of new IT services.”
The original brief was too broad for the time available and assumed a level of domain expertise we simply did not possess.
As the team independently explored the space and later synthesised our findings, one theme consistently emerged: users lacked visibility into the service delivery process. They often couldn’t tell where a service request was, what would happen next, or when delivery would occur.
This was not primarily a workflow problem. It was a transparency problem.
Had we followed the original brief, we likely would have redesigned a broad process without understanding which part was actually failing users. By narrowing our focus, we could address a specific and testable problem that aligned with both user needs and project constraints.
Reframed challenge:
“How might we provide a clear service delivery process that supports services at different stages of maturity?”
Research + discovery
Accessing external users proved difficult. The product team viewed the work as an early-stage incubator and initially questioned the value of recruiting real customers.
I raised concerns throughout stakeholder reviews that relying solely on internal proxies would introduce bias and limit validation. While the risk was acknowledged, the team ultimately were pushed to proceed with the access available.
What I did:
- Facilitated two client workshops with consulting leaders.
- Conducted five sponsor-user interviews using internal proxies.
- Led two walkthroughs of the live MCMP platform
- Facilitated the research synthesis sessions that transformed findings into user needs and opportunity areas.
- Collaborated on competitor analysis.
Key insight
Our primary persona, Craig, an application developer, emerged as the user most impacted by poor service delivery visibility.
Craig faced three recurring challenges:
- No clear view of where a request sat in the delivery process.
- No reliable estimate for when a service would be available.
- No understanding of why delivery timelines varied.
These were not missing features. They were symptoms of a process that users could not see or understand.
How it changed the design
Rather than redesigning service co-creation broadly, we focused on a single question:
Can developers clearly understand the status and expected delivery of their service requests?
This shift shaped our research, design activities, and eventually the Hills that guided the project.
Design process + decisions
1. Reframing the problem through hills
Developing the Hills became the most important activity in the project.
We spent nearly two weeks refining them, revisiting assumptions after additional stakeholder interviews and feasibility discussions.
Early versions focused too heavily on platform behaviour rather than user outcomes. Through iteration, we reframed them to reflect what success looked like from the user’s perspective.
The final Hills were:
Craig is able to see a workflow of a new service delivery from start to finish, from the day the service request is approved.
Craig knows an accurate delivery time of his service within a day of requesting it.
These provided enough focus to guide ideation while leaving room for multiple solution directions.
1. Reframing the problem through hills
Developing the Hills became the most important activity in the project.
We spent nearly two weeks refining them, revisiting assumptions after additional stakeholder interviews and feasibility discussions.
Early versions focused too heavily on platform behaviour rather than user outcomes. Through iteration, we reframed them to reflect what success looked like from the user’s perspective.
The final Hills were:
Craig is able to see a workflow of a new service delivery from start to finish, from the day the service request is approved.
Craig knows an accurate delivery time of his service within a day of requesting it.
These provided enough focus to guide ideation while leaving room for multiple solution directions.
2. Narrowing to 1 persona
Research highlighted several audiences involved in service delivery, including service owners, delivery managers, and application developers.
The temptation was to design for all of them.
I argued against this approach. Within a six-week project, attempting to serve every stakeholder would have produced superficial outcomes for everyone.
Instead, I pushed the team to focus on Craig. Research suggested that developers had the greatest influence on platform adoption. If they could not trust the service delivery process, they would bypass it entirely.
This focus gave the team clarity and prevented the project from expanding beyond what we could responsibly deliver.
3. Separating ambition from feasibility
To avoid prematurely constraining ideas, we divided ideation into two phases.
The first phase intentionally ignored delivery constraints and encouraged broad thinking. The second was informed by deeper domain knowledge and focused on realistic implementation opportunities.
Using impact-versus-feasibility mapping, we identified both:
- Long-term strategic opportunities.
- Short-term improvements that could deliver immediate value.
This structure allowed us to preserve creativity while ensuring our final recommendations remained grounded in reality.
Final design
Outcome
At the end of the six-week engagement, the prototype was presented to the MCMP product team and broader stakeholders.
The response was positive, and the team committed to evaluating the concepts through further research before considering roadmap investment.
This work was completed within an incubator environment rather than a delivery programme, so the outcome was not a production release.
However, the prototype successfully reframed the conversation from improving service creation to improving service delivery transparency. It became an artefact used to guide future product and research discussions.
What I learnt
This project reinforced the importance of narrowing scope in complex domains.
When faced with a broad, ambiguous challenge, there is often pressure to solve everything. In reality, tackling a smaller problem deeply usually creates more value than addressing a larger problem superficially.
The decision to shift from “accelerating time-to-market” to “making service delivery understandable for Craig” was not a compromise. It was the reason the project became actionable.
If I were repeating the project, I would push much harder and much earlier for access to real users. Internal proxies helped us identify patterns, but they could only take us so far. Even a small number of interviews with actual application developers would have provided stronger validation and increased confidence in the final direction.
Grace Lindsell, Project Lead
SAM CATLING 