A brand new integration & runtime monitoring experience to reduce support dependency.

Integrated Observability & Monitoring into IBM App Connect SaaS, enabling users to assess integration health, optimise runtimes, and enhance performance of their system; saving them time and money.

Top 5 skills utilised

Project overview
August 2023 - March 2024

User problem

Prior to this project, IBM App Connect lacked Observability & Monitoring (O&M) capabilities, leaving users with little visibility into integration performance and health.

They had to rely on information logs or manually monitor status changes (illustrated below). We needed to capture and present real-time and historical events for better visibility.

App Connect has 2 distinct user personas; "Tia" a less-technical business analyst and "Isaac", a. technical integration developer.

Business problem

The product lacked Observability & Monitoring, putting it at a competitive disadvantage and leaving users without clear visibility into integration and runtime health.

When integrations fail, end users raise tickets with their organisation’s support teams, who often escalate to our support teams for deeper diagnostics. This dual strain increases operational costs on both sides and slows down customer adoption.

To reduce this burden and increase adoption, we needed to empower users with clear insights and self-service troubleshooting.

Key successes

The project received strong internal recognition (including direct recognition from a Senior Program Director for my contributions) and was a strategic step toward reducing support overhead and improving system transparency; though full KPI validation was limited due to company restructuring.

Segment usage metrics confirmed promising user engagement when our phase 2 was released; this data indicated that these features are actively used, revisited, and delivering real value.

My role

I led the end-to-end UX for this item; addressing the visibility gaps that caused user reliance on support teams. Through in-person design workshops, structured research, and multiple iteration cycles, I defined a two-phase delivery plan aligned with technical constraints. I guided the team through discovery-to-implementation.

Key Contributions:

Facilitated cross-functional design workshops across two project phases.
Ran usability testing and synthesised insights to inform phased delivery.
Shaped the UX through ideation and refinement in the face of ever growing constraints.
Drove collaboration with engineering to refine technically feasible solutions.
Advocated for user needs during prioritisation with product managers.

Team: Design Lead (researcher), UX Lead (myself), UX Designer, Visual Designer & Software Design Intern.
Stakeholders: PM, Engineering Leads & Team, Architect.

Aligning on the problem & scoping

I led a 3-day workshop to align on the problem space and scope the work appropriately, supported by an illustration I created to build empathy with the user challenges.

The user problem illustrated

This illustration I created highlights the core user problem; without visibility, monitoring and alerts, Isaac, our integration developer, had to rely on support tickets or manual log checks to detect issues. This impacted his ability to respond in such a way that customer impact was minimised and increased strain on support.

Kick off workshop

I ran a fast-paced, cross-disciplinary design workshop to explore key opportunity areas, rapidly ideate on solutions, and align early with stakeholders. The outputs formed a strong foundation for user testing the following week; shaping priorities based on real insights. This section covers a detailed view of the workshop and what the outcomes were; although the images provided are of the Mural translations of the workshop, this was held in person over 3 days.

Workshop structure

The workshop was a cross-disciplinary effort, bringing together five Designers, three Engineers/Subject Matter Experts (SMEs), and one Product Manager. This diverse mix allowed us to get questions answered in real time and iterate quickly.

Held in our studio over three days, the workshop ensured full-team focus in a highly collaborative environment.

Outcome

A set of high-level prototypes were created, addressing the key opportunity areas identified earlier in the workshop; a rough and ready playback of the workshop was delivered to the wider team to gather early feedback. This provided a solid foundation for producing designs to be tested with users the following week.

Next steps post workshop

Refine the designs ready for user testing.

Schedule user testing sessions to quickly validate what was valuable versus less valuable, helping to scope and prioritise the work effectively.

Day 1: Gather requirements & identify opportunities

On this day, we aligned on user needs, gathered existing research, and mapped out key pain points across user journeys. We clarified assumptions, determined opportunity areas, and began initial scoping based on insights and SME input.

Activity 1 (presented as a workshop pre-read)

Gather requirements & knowledge sharing - initial scoping & research insights

We aligned on our target users; Isaac the integration developer and Tia, the business analyst, focusing on their distinct needs. Additionally, our design lead, with a background in research, contributed valuable insights from previous sessions across both our product and other IBM tools, enhancing our understanding.

We identified two clear user mindsets: “I want to understand and take action” vs. “I want to optimise.” This alignment gave the full team clarity on priorities, existing context, and the problem space we were solving for.

Activity 2

Assumptions & questions

We highlighted our biggest assumptions and areas of uncertainty, pinpointing what needed validation before moving forward to de-risk any solutions we produced during the workshop. By having SMEs in the room, we were able to get fast answers to critical questions and resolve knowledge gaps early.

This process helped us identify key focus areas for upcoming research and user testing.

Activity 3

Mapping the existing user journey for diagnosing problems

We mapped out the key steps, focus areas, pain points, and emotional responses experienced by Isaac and Tia as they attempted to resolve issues using the current product. This helped surface the friction they faced from a lack of visibility to reactive troubleshooting.

From this, we identified clear opportunity areas. For example, introducing visual cues such as charts and graphs for at-a-glance issue detection, and real-time alerts to proactively notify users of problems. These opportunities laid the groundwork for targeted, high-impact solutions.

Day 2: Ideation & creative thinking

We transformed pain points and opportunities into solutions through structured ideation; using "How Might We...?"s (HMWs), Crazy Eights, and Round Robin techniques. By the end of the day, we had a broad range of creative ideas as well as a set of individual solution concepts ready for further refinement.

Activity 1

"How Might We" and Affinity Mapping

We began the day by analysing the user journey pain points uncovered in Day 1, grouping similar challenges into thematic opportunity areas using affinity mapping. This allowed us to visualise and cluster shared problems faced by users like Isaac and Tia.

From these groupings, we developed targeted HMW statements; user problem-framed prompts that enabled us to explore a wide range of potential solutions. These HMWs became the foundation for the ideation activities that followed.

Activity 2

Crazy Eights & Round Robin

To spark creativity and avoid default thinking, we ran a Crazy Eights exercise consisting of rapid-fire sketching where each person generated eight different ideas in eight minutes for each HMW. This method helped unlock a broad range of concepts from everyone on the team.

We followed this with a Round Robin activity, where ideas were passed around and built upon collaboratively. This collective iteration generated richer, more unexpected ideas by combining individual perspectives, fostering a sense of shared ownership and innovation.

Screenshot 2025-05-02 at 13.20_edited.jp

Activity 3

Diverged and created individual solutions

With a broad set of ideas at our disposal, we each took time to develop our own complete solution stories. These proposals combined elements from earlier exercises and addressed the key HMWs, resulting in concept sketches targeting the most critical user challenges.

This divergence helped us explore a wide range of potential solutions while surfacing individual viewpoints that could be brought together and refined in the next phase.

Individual solutioning is my favourite part of any workshop; it puts everyone on equal footing, gives non-designers space to be creative, and builds real ownership in the solutions we produce together.

Day 3: Rapid prototyping & playbacks

We consolidated and prioritised our strongest ideas, created a compelling end-to-end story, and aligned the wider team through a final playback. This capped off the workshop with a clear direction for the experience; particularly the areas we needed to test to de-risk the project.

Activity 1

Playbacks of individual solutions

We kicked off Day 3 by sharing back the individual solution ideas generated on Day 2. Each team member presented their concept, explaining how it addressed the key user needs and pain points. As they went through, other participants could leave feedback directly in the Mural so we captured all thoughts & opinions equally.

We held an open discussion to evaluate each idea; focusing on which ones best aligned with the users’ challenges and goals. This gave us a clearer direction for what experience we might want to propose for our end to end stories.

Activity 2

Construct stories as a team

Using the top-voted ideas, we worked together to construct a series of stories that addressed both Isaac’s and Tia’s needs.

Due to this being a very discovery-based workshop, I wanted to keep us out of Figma and anything higher fidelity for now as I strongly believed the fidelity should reflect where we were in the process; a.k.a we had a lot of questions still.

Activity 3 (Hosted on Monday to maximise international availability)

End of workshop playback

To wrap up the workshop, I presented our stories to the broader team. This playback ensured everyone was aligned on the direction we were heading, invited early feedback, and gave stakeholders a chance to weigh in before the next phase.

As with the fidelity of the stories, I wanted the playback to reflect this same fidelity, as this was reflective of our uncertainty in some areas. We wanted a lot more fundamental feedback/concerns raised than merely the colour of a button/chart types.

User testing

I ran 6 usability tests on low-fidelity Figma prototypes for integration monitoring and uncovered key needs around role-based workflows, clear homepage alerts, and threshold-based notifications. These insights led us to split delivery into two phases, with phase 2 deemed essential to meet core user needs and truly deliver an MVP.

User testing summary

Participants:

6 individuals responsible monitoring integrations at their companies. These were spread across different sized companies; from small-medium businesses to large enterprises.

Format:
Combined exploratory interviews and prototype testing. We had 2 observer slots available for each session so design, engineering and PM had the opportunity to listen to the feedback live.

Approach:

Started with broad questions about existing tools, error-handling processes and pain points. Then tested 3 low-fidelity prototypes to evaluate core value.

Prototypes:

The 3 prototypes covered how we might initially notify the user of errors to a series of charts, graphs and tables displaying what we perceived as key data. I put together the bulk of the prototypes with our new intern supporting on chart creation to get UX experience.

Key insights

I've collated the top 4 insights that impacted the direction of the project.

Insight 1

Monitoring and development roles are split in large companies, hence the "thrown over the fence" reference when asked about how they take action on an error, but these roles are combined in smaller ones; our solution must support both workflows.

Insight 2

Users want a high-level summary or notification panel immediately upon logging in.

We tested with and without a notification on the homepage as getting updates to the homepage prioritised was always a challenge, so we knew we would need user-based evidence to get this prioritised.

Insight 3

Threshold-based alerts are essential; without them, visual data lacks actionable meaning.

For example, it's fine telling a user 'you've had 2 errors', but in a situation where 100k integration runs execute a day, a few are bound to fail and retry, so offering an adjustable threshold is important to them so they only get critical notifications if the error rate/count goes above a certain level.

Insight 4

Notifications/fixes must guide users clearly; multiple CTAs result in choice paralysis.

We needed to ensure each error had a clear primary action to take and not overload guidance with all the things they 'could' do,

Outcomes & impacts

Informed prioritisation with PM & Engineering

Outcome: We shared user insights directly with the PM and engineering teams during prioritisation discussions.

Impact: This helped ensure technical and delivery decisions were grounded in real user needs, especially around visibility, notifications, and workflows.

Defined a Two-Phase Delivery Approach

Outcome: Due to the complexity of the work, we split delivery into two phases:

Phase 1: Basic runtime visibility (e.g. graphs, tables), alerts and error insights.
Phase 2: Runtime & integration visibility with threshold logic. Additionally the homepage summary widget.

Impact: This allowed us to manage delivery scope while still working toward a more complete and user-validated solution.

Advocated for Phase 2 as essential, not optional

Outcome: We clearly communicated that the product is not an MVP until Phase 2 is delivered, as many foundational user experience needs (like alerts and thresholds) are unmet without it.

Impact: This created alignment on the importance of follow-through, increasing the likelihood that Phase 2 remained a priority in the roadmap.

Ideation on phase 1

Here are the key design proposals for phase 1.

Key features

Here are some examples of the early designs and how they addressed the key experience issues identified earlier.

Feature 1

Monitoring dashboard

Focused on runtimes, showing CPU and memory usage, along with indicators for crashes due to memory overload or high CPU usage.

It also provided error insights, helping users quickly identify when and where errors occurred. Graphs and charts supported Tia’s preference for visual cues (as she is a less technical business analyst), while detailed tables catered to Isaac’s need for deeper insights (As he is a technical integration developer).

Feature 2

Runtime drill-down

Allowed users to explore individual runtimes in detail, including error history, to understand issues and take appropriate actions.

This helped users make informed decisions about adjusting resource limits based on past runtime behaviour.

Feature 3

Dashboard customisation

Offered flexible settings such as time range filters to match user preferences and workflows.

Restrictions & Solutions throughout the ideation phase

Restriction 1

Initial engineering spikes revealed the feature set was more complex than expected, leading to significant scope reduction. As a result, only the dashboard and runtime drill-down pages, focused on runtime data via charts and tables without errors or the summary widget, were feasible for delivery in Phase 1.

Solution

To adapt, we streamlined designs to maximise value within these constraints and continued to advocate for the remaining features. Once again, we clearly communicated that without error alerts and the homepage widget, the experience was incomplete and not representative of an MVP.

Implementation of phase 1

We partnered with an existing App Connect engineering team who, while highly skilled in back-end development, had to ramp up on front-end capabilities. Their expertise was invaluable for surfacing runtime data, though front-end limitations caused delays. Thanks to strong motivation, structured design handovers, and targeted support sessions, we made steady progress; albeit slower than initially expected.

Main dashboard

This evolved over several iterations as we navigated new design and engineering constraints. Limited chart options in the Carbon Design System meant we had to get creative in representing complex performance data like CPU and memory usage.

I was responsible for iterating on the UX of the charts through collaborative sketching and ideation sessions with engineering, while I was supported by our visual designer for their in-depth knowledge of the new chart components.

Runtime drill-down

We designed the drill-down page with future integration data in mind, knowing their relationship to runtimes was critical for diagnosing crashes.

Although integrations weren’t included in phase 1, we avoided designing in isolation to ensure future compatibility—laying the groundwork for a cohesive experience in phase 2.

As with the main dashboard page, I was responsible for extensive UX iterations for the general page, specific charts and table.

Implementation in progress

This snippet is from a work-in-progress update shared by engineering during implementation. While there were several visual and functional bugs at this stage, it represented a midpoint in development and was not yet fully polished.

Additional workshop for phase 2 & further ideation

As the structure largely mirrored the first workshop & ideation, this summary highlights only the new focus areas and outcomes.

Phase 2 workshop (3 days, in person)

I ran a focused follow-up to the initial workshop, these session aimed to close the key experience gaps left by phase 1. Designers, engineers (including the full delivery team), and PMs collaborated closely to align on phase 2 goals.

Workshop activities

Day 1

Revisited research and testing insights, mapped assumptions, pain points, and refined “How might we” statements to guide solutioning.

Day 2

Ran a sketching warm-up to engage the full team, followed by a targeted 4-step sketching session to generate and discuss refined ideas.

Day 3

Created rapid prototypes and shared with the wider team for feedback.

As we had existing designs by this point, we could easily pull together prototypes including the enhancements so a higher fidelity set of designs & playback was more suitable for this workshop.

Key outcomes from the workshop and ideation areas

Outcome 1

Introduced error counts, integration monitoring, and threshold alerts.

This addressed the key gaps from phase 1 for this to become an MVP.

Outcome 2

Added a notification panel visible across the UI (including homepage) to surface urgent issues.

This addresses the earlier user need around being able to see, when they first log in, what errors have occurred while they've been away so they can take immediate action.

Outcome 3

Reflected warnings on the “Manage” page to support in-context action.

To support in-context action, we extended monitoring capabilities to the “Manage” page; ensuring errors and insights appear directly alongside runtimes and integrations. This was especially important given our finding that, in larger organisations, users like Isaac who don’t access the monitoring dashboard, will still need clear visibility into issues through the assets they regularly interact with.

Implementation of phase 2

Phase 2 addressed critical experience gaps from the initial release, including error visibility and threshold-based notifications; enabling users like Isaac and Tia to diagnose issues faster without relying on manual log checks or support tickets. However, due to the acquisition of webMethods and the resulting strategic shift, the full team was transitioned before completion. As a result, some designs remained unimplemented, and gathering user feedback to validate the success of phase 2 was not possible.

Error counts & integration monitoring

We added a new chart to the dashboard displaying total error counts across runtimes. Users could drill into specific containers within a runtime to identify where errors were originating.

This provided a high-level overview and the necessary detail to act quickly—particularly important for large-scale environments with many components.

I was again responsible to rapidly ideating on the initial designs with engineering whenever new constraints came up e.g. we needed to introduce a container break-down as this was very important to integration developers especially. I also supported on visual design as we now had a a better understanding of the new charts.

This was successfully implemented.

Runtime/integration warnings on the “Manage” page

To support in-context issue detection and reduce the need to visit a dedicated dashboard, we surfaced warning indicators directly on the tiles for runtimes and integrations. This was crucial for users like Isaac, who often engage with assets via APIs or management views rather than the dashboard itself. This change helped ensure that error insights were visible in the natural flow of their work.

The UX for this was fairly simple (A range of different statuses to indicate whether a runtime was passing various thresholds vs. actually erroring, displayed on the existing tile), but I also liaised with the content team to provide appropriate explainability as I needed to up their understanding of the requirements.

Successfully implemented.

Taking action directly from the log viewer

Given that Isaac often operates from the logs when resolving issues, we connected relevant error insights and suggested fixes directly into the log viewer interface. This enhancement made it easier to move from diagnosis to action without navigating across multiple screens.

I integrated the 'edit resources' button into a new design produced by our intern for the logs page which redirected to our brand new runtime experience (See Project 2). This was super simple UX updates.

Successfully implemented.

Notifications panel across the UI

This panel was fully designed to offer real-time alerts across the interface—making critical issues visible no matter where a user was working. It would have supported immediate action and fulfilled the earlier user need for homepage-level visibility.

However, due to uncertainty around how notifications would be handled at the platform level post-acquisition, this was paused to avoid wasted effort.

I had to go through several UX iterations largely due to scalability considerations. The fact that some users might have hundreds of errors meant I needed to push for some customisation of the Carbon component as it was then.

Errors widget (Dashboard and homepage)

This component was designed to be reused across the monitoring dashboard and homepage, giving users a quick view of recent issues when logging in. It aligned with early user feedback requesting immediate awareness of problems without hunting for them.

Despite its value, it was not implemented due to shifting priorities after the acquisition.

This required a few UX iterations to make sure I was displaying the right information in line with the 'choice paralysis' insight gained from testing; I made sure the information was clear and there was one primary action of 'take action now' vs. a secondary action of 'inspect problem further'.

Project feedback

Samples of some feedback received on my input on the project.

UX Designer, IBM App Connect SaaS

"I have observed how you worked with engineering to determine what is feasible and refined the UX for the 2023 MVP. You quickly build a very strong relationship between the design team and the squad that are delivering the designs. The squad are visibly keen to collaborate closely with design, regularly sharing feedback from an engineering perspective as well as to ensure they deliver to the exacting standards."

Product Manager, IBM App Connect SaaS

"I think you’ve done a really great job organizing the design work. This is a major net new item so there was a lot of figuring out to do as this isn’t as incremental as a lot of our other work so really appreciate how flexible you and the broader design team have been with it. I think the most recent playback was really helpful to see as it gave us a lot more clarity to be able to define the vision and will service us quite well for several phases."

Architect, IBM App Connect

"Really impressed with the way this work was approached to understand some of the technical aspects, get insights from team and user studies. The playbacks were great, and I know that the engineering team really got value from the involvement."

A brand new integration & runtime monitoring experience to reduce support dependency.

Project overview August 2023 - March 2024

User problem

Business problem

Key successes

My role

Aligning on the problem & scoping

The user problem illustrated

Kick off workshop

Workshop structure

Outcome

Next steps post workshop

Day 1: Gather requirements & identify opportunities

Day 2: Ideation & creative thinking

Day 3: Rapid prototyping & playbacks

User testing

User testing summary

Key insights

Outcomes & impacts

Informed prioritisation with PM & Engineering

Defined a Two-Phase Delivery Approach

Advocated for Phase 2 as essential, not optional

Ideation on phase 1

Key features

Restrictions & Solutions throughout the ideation phase

Implementation of phase 1

Main dashboard

Runtime drill-down

Implementation in progress

Additional workshop for phase 2 & further ideation

Phase 2 workshop (3 days, in person)

Implementation of phase 2

Error counts & integration monitoring

Runtime/integration warnings on the “Manage” page

Taking action directly from the log viewer

Notifications panel across the UI

Errors widget (Dashboard and homepage)

Project feedback

Project overview
August 2023 - March 2024