IBM — Microclimate

IBM Microclimate

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 and constraints 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 demonstrated Complex information architecture, developer workflow design, task-flow definition, prototyping and iteration, research-informed design, making advanced technical concepts approachable

Empowering Developers to Modernize Applications.

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

This is a simple as-is flow diagram done for adding a new programming language to the application. What I like about these, is how the diagram can clearly expose where we have gaps in understanding.

This is a to-be flow diagram for adding a new programming language to the application. I used this style of diagram as it was easier for the developer to understand.

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

Outcomes

Summary: clearer first deploy path, higher first-run success, stronger developer confidence

• Time to first deploy
  Baseline: Fragmented workflow across IDE, build pipeline, and Kubernetes with no guided path
  Change: Unified task flow validated against how developers actually worked
  Evidence: Interviews and task flow validation sessions with developer participants
• First-run success
  Baseline: Developers stalled or failed during build and deploy, especially when Kubernetes transitions were unclear
  Change: Explicit guidance added at decision points where users commonly stalled
  Evidence: Moderated prototype sessions plus confirmation from the dedicated researcher
• Developer confidence
  Baseline: Anxiety about Kubernetes complexity and uncertainty about stack compatibility
  Change: Language and environment flexibility made discoverable earlier in the flow
  Evidence: 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