Home

IBM: Microclimate

Helping developers move from monolithic apps to microservices without getting lost.

My role UX designer responsible for information architecture, core workflows, and end-to-end interaction design across key product surfaces, partnering closely with engineering and research to validate and iterate
Scope Product + engineering + dedicated researcher | Multi-sprint program | IDE to deploy workflow, build and deploy guidance, Kubernetes decision points, language and environment options
Challenges Complex developer workflows spanning IDE, build, and Kubernetes deployment, plus the need to make advanced capabilities feel approachable without oversimplifying for experienced users
Impact Helped establish a clearer, more guided project creation and deployment experience, grounded in interviews and testing, and supported adoption by aligning patterns with how developers actually work
Skills Complex information architecture, developer workflow design, task-flow definition, prototyping and iteration, research-informed design, making advanced technical concepts approachable

Microclimate was a tool that helped developers modernize monolithic apps by building and deploying microservices to Kubernetes. I led UX design, turning research into task flows and prototypes, then validating designs with users and engineering partners to keep the product grounded in real workflows.

My role as UX Designer

As the UX Designer for Microclimate, I led the user-centered design process, ensuring the product met the needs of developers like Jane. My responsibilities included:

  • Research and Discovery: Conducting user interviews and contextual inquiries to deeply understand user workflows and pain points
  • Defining User Goals: Writing user stories and creating user task flows to clarify objectives and map the journey through the application
  • Design Development: Translating research insights into sketches, wireframes, and prototypes, which were regularly validated with development colleagues
  • User Validation: Collaborating with a dedicated user researcher to test prototypes with actual users and incorporate feedback into iterative design improvements

The design process

Our journey began with a design thinking workshop, where we unpacked the problem space as a team. This collaborative effort involved creating key artifacts such as:

  • Stakeholder Maps and Empathy Maps: To identify and understand the needs, frustrations, and goals of our target users
  • Needs Statements and Product Hills: To articulate user requirements and align the team on measurable product outcomes
An empathy map.

An empathy map synthesized from user interviews, a core Design Thinking artifact that captures what users say, think, do, and feel. Patterns across all interview subjects were then consolidated into a single proto-persona representing our target developer archetype.

"Working with microservices, and especially the step of deploying to Kubernetes, can be a pain."

— Interview subject
A user persona.

A proto-persona for Jane, our target developer, built from early interview signals before full research was complete. The format follows IBM's design studio conventions and was used to keep the team anchored to a single, consistent user reference throughout the project.

"I love the built-in IDE!"

— Interview subject
An as-is scenario flow diagram.

This is a simple as-is flow diagram done for adding a new programming language to the application. The diagram can clearly expose where we have gaps in understanding.

The as-is flow ended in four steps and a wall: the application didn't support adding a new language, and the user quit. What the diagram made clear was that the problem wasn't discoverability. The user was already in exactly the right place. The system simply didn't offer the capability.

"Just make it easy for me to find my project and deploy it."

— Interview subject
A user task flow diagram.

The task flow format was a deliberate choice — developers found it easier to follow than the sticky note scenario maps, so we adapted the artifact to fit the audience rather than the other way around.

Mapping the core task flows early revealed two distinct mental models for getting started: users creating a new project and users importing an existing one. Keeping those paths separate in the UI, rather than forcing them through a single creation flow, was a direct result of seeing them side by side here.

Key decisions Summary: one guided path, guidance at stall points, flexibility surfaced early
Unify IDE, build, and Kubernetes into one guided task flow
DecisionDefined an end-to-end creation-to-deployment sequence that connected steps users previously pieced together
TradeoffReduced flexibility in early steps to provide a dependable default path
WhyBaseline workflows were fragmented and required external documentation and prior Kubernetes comfort
ResultParticipants could navigate the deploy path without relying on outside docs
Add guidance at the stall points, not everywhere
DecisionInserted explicit guidance only where users commonly failed or stalled
TradeoffAccepted a slightly more guided experience instead of a minimal interface
WhyBuild and deploy failures were often caused by unclear transitions between local work and Kubernetes steps
ResultHigher first-run success in moderated prototype sessions
Surface language and environment flexibility early
DecisionMade stack flexibility discoverable earlier so users understood scope before committing
TradeoffMore up-front information in exchange for fewer drop-offs later
WhyInterviews showed skepticism driven by uncertainty about fit
ResultParticipants shifted from skeptical to engaged once they understood the tool's range

"You mean I can add whatever language I want to the environment? Cool."

— Interview subject
Outcomes Summary: clearer first deploy path, higher first-run success, stronger developer confidence
  • Time to first deploy — Fragmented workflow across IDE, build pipeline, and Kubernetes with no guided path. Unified task flow validated against how developers actually worked. Confirmed through interviews and task flow validation sessions.
  • First-run success — Developers stalled or failed during build and deploy, especially when Kubernetes transitions were unclear. Explicit guidance added at decision points where users commonly stalled. Evidenced through moderated prototype sessions.
  • Developer confidence — Anxiety about Kubernetes complexity and uncertainty about stack compatibility. Language and environment flexibility made discoverable earlier in the flow. Quote pattern shift in interview synthesis confirmed by the dedicated researcher.
What changed in the product
  • The creation-to-deployment workflow was simplified and made sequential
  • Guidance was added at the points where developers most commonly stalled
  • Language and environment flexibility was surfaced earlier so users understood scope before committing
How we measured

Interviews and contextual inquiry informed the as-is flow, prototype sessions validated the to-be flow with real developer participants, and a dedicated researcher supported ongoing synthesis and feedback integration

Microclimate was a complete development environment with a built-in IDE, logging, performance monitoring, and one-step deployment to Kubernetes.