Enterprise Application Service for Java 0 → 1 Launch
Establishing the core UX from strategy through cloud launch of a platform streamlining application delivery.
PRODUCT SUITE
IBM WebSphere
KEY CONTRIBUTIONS
- UX/UI design
- Stakeholder management
- Prototyping
- User Research
- Strategy
ROLE
UX Designer
TIMELINE
Q4 2023- Q4 2024
Overview
Enterprise Application Service for Java (EASeJ) is a cloud-native Platform-as-a-Service (PaaS) solution designed to simplify how product teams build, deploy, and run applications. I joined at the inception as the first UX designer, defining product experience strategy and core patterns.
What began as an engineering proof of concept and design sketches evolved into a cloud-first enterprise solution launched at IBM Think 2025.
Context
Developers and SREs are stretched thin
Modern product teams don’t struggle to write code - they struggle to ship it.
Application delivery has evolved into a layered ecosystem of pipelines, infrastructure, security controls. Each layer improves reliability. But together, they create friction.
Product teams have to spend more time managing systems than delivering value.
SOME STATS
16% of a developer’s time is spent writing code
33% of engineering time is lost to technical debt.
Distributed and fragmented architectures are to blame for this, forcing teams to juggle multiple platforms. Modernisation should solve this. Instead, it often adds another burden.
SOME STATS
76% of organisations report that architectural complexity directly reduces productivity.
140+ person-years are required for the average enterprise to fully modernise applications.
To move faster, they must modernise.
To modernise, they must slow down.
This revealed an opportunity to reimagine application delivery so developers and SREs can take back control of their time and momentum.
Research
I led the foundational discovery alongside my design lead. We conducted over 40 user sessions with Developers, Platform Leads, and CTOs. While most patterns reinforced our secondary research, two stood out:
Preserving complexity
Developers don’t want oversimplification. They want respected complexity. Too simple feels like a toy; too complex kills usability.
Anchor in Git
Version control systems like Git were non-negotiable anchors for trust and adoption. This would form the backbone of our user flows and mental model.
Designing EASeJ meant balancing these competing needs without compromising user experience.
No two product teams are alike, so we focused on identifying the core user archetypes directly involved in delivering the product, each with distinct goals and areas of expertise.
These weren’t abstract personas; they were people sitting across the table from us every week, telling us where their time and energy were being lost.
01
Lead Developer
WANTS
Governance
KEY TASKS
Setup and Monitoring
"We need a secure, scalable collaboration platform with a unified dashboard for full visibility and streamlined management."
02
Developer
WANTS
Autonomy
KEY TASKS
Development & testing
"I want to focus on writing code and have a reliable build pipeline that automates testing and stores artifacts."
03
SRE
WANTS
Reliability and control
KEY TASKS
Deployment & diagnostics
"I want every change to reach production safely and predictably, with strong monitoring, and alerts."
Journey mapping and prioritisation
I mapped out the entire end-to-end journey to understand the friction areas faced by each user at each stage of application delivery from setup and onboarding to deployment and monitoring.
Working closely with the product management team, the friction points were highlighted and prioritised to deliver the highest impact for our MVP. To prevent scope creep, we defined three role-based hills:
User flows and initial concepts
Understand, design, repeat
Using insights from research and MVP prioritisation, I mapped out the end-to-end flows for EASeJ across different users, from setup to monitoring.
I tried to balance the trade-off between ease of use and complexity while Git remained our structural anchor, shaping both workflows and mental models.
Testing
Understand, design, repeat
We built low- and high-fidelity prototypes with Figma to validate our concepts with 20 users. Participants were given a practical task: launch a sample application to the cloud and modify it.
Testing surfaced areas where configuration steps felt dense. This pushed us to refine defaults, add optional overrides, and improve contextual guidance.
Final designs
A truly joint effort
Delivering the MVP for EASeJ required close collaboration with product and engineering to ensure that the experience balanced complexity and clarity.
Every decision, from progressive disclosure to GitOps workflows, was shaped to preserve technical control while reducing unnecessary cognitive load.
LEAD DEVELOPER
I want to be able to try out a service before onboarding and then quickly setup my application
Setup quickly with good defaults:
Users can quickly explore the value of EASeJ by spinning up a trial instance with an opportunity at the end to try with your own application.
DEVELOPER
I just want to code, not manage complicated build/test artefact pipelines.
Builds happen without SRE support
Developers can focus on what they do best, coding instead of dealing with infrastructure of build pipelines. Artefacts are built, tested and stored into a unified platform.
SRE (SITE RELIABILITY ENGINEER)
I want to improve system reliability, not spend time maintaining artefact and deployment workflows.
Deploy simply, scale easily, troubleshoot smartly
EASeJ simplified deployment and scales environments. Problem determination is built in to diagnose problems
Impact
EASeJ was showcased at IBM Think 2025. Additionally, the IBM CIO Office, using EASeJ’s Application Modernization Accelerator (AMA) tools to modernise a Global Financing application to the cloud, found:
99%
reduction in time required to migrate the application
80%
reduction in setup time (weeks to hours)
25%
decrease in SRE/platform time spent on operational toil
20%
increase in developer capacity due to reduced infrastructure and pipeline overhead
Reflections and what's next
Seeing my work showcased at IBM Think was surreal.
Investing early in learning the domain changed how I approached design, enabling me to contribute on an equal footing with product management and engineering, even in a highly technical space.
I also became an onboarding asset, helping new team members ramp up faster so they could begin contributing sooner in a complex domain.
Onboarding session for new team-members covering basics of the domain and the product.
What's next:
With the MVP launched, the next phase focuses on scale and intelligence.
AI-assisted workflows (IBM watson)
Surface optimisation opportunities and reduce cognitive overhead without diminishing control.
Cloud-agnostic expansion
Support multi-cloud deployment, introducing new abstraction and governance challenges.
Request a case study
Want to learn more about this project? Get in touch to request a case study.