Improving the success rate of deploying an integration by 88%.

Eliminated key UX blockers in integration deployment, enhancing the user experience while enabling IBM App Connect SaaS’s new pricing model.

Top 5 skills utilised

Project overview
March 2023 - February 2024

User problem

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

Testing with 6 non-technical business users and 6 integration developers revealed an 8% (1/12) success rate in integration deployment, highlighting key experience blockers:
1. Switching instances disrupted user workflow and did not match their mental model.
2. Requiring download/upload of an integration file to deploy it added friction.
3. Unclear error messages hindered troubleshooting.

Business problem

We were tasked with introducing a new pricing model for IBM App Connect SaaS to meet analyst expectations.

This also created an opportunity for us to improve accessibility by abstracting complex concepts like runtimes away from non-technical users. Since deployment issues would impact revenue, fixing the experience became essential; securing additional engineering investment while aligning with business goals.

Key successes

Increased the integration deployment success rate from 8% to 100% through repeated user and reduced user clicks from 13 to 3 (-76%).

The new pricing plan is now the preferred experience for sales teams to demo as it accelerates customer understanding of product value.

My role

As the UX Lead, I drove alignment between PM, engineering, and design to enable the design team to deliver a seamless user experience.

As part of this, I:
- Supported our design lead in gathering requirements and I facilitated a co-creation workshop.
- Led stakeholder playbacks and ensured user testing generated actionable insights.
- Designed and refined the UX

- Established a structured workflow with engineering for smooth implementation.

Team: Design Lead (Researcher), UX Lead (myself), Visual Designer, Researcher, Design Apprentice.
Stakeholders: PM, Engineering Lead & Team, Architect."

Aligning on the problem & scoping

We combined business requirements with findings from UX audits and user testing to maximize our impact from the get go. These insights were utilised in an alignment and ideation workshop, ensuring our proposed story addressed both business and user needs.

UX audit on IBM App Connect SaaS

When I joined the product, I conducted a full UX audit of the end-to-end experience. As part of this audit, I identified 21 usability issues in the integration deployment process alone.

I presented these findings to over 30 stakeholders across App Connect Design, Engineering & PM.

The significant number of issues ultimately secured crucial user testing budget to gather key user insights on the product.

Below are my top 3 usability issues I found:

Issue 1

Having to use a UI switcher to deploy an integration

My biggest questions were “why do users need to go to a completely separate area of the UI to deploy something” and “why isn’t there the ability to deploy an integration from where you’ve created it?”.

Issue 2

Having to download a file version of the integration and re-upload it during the deploy experience

My biggest question here was “why aren’t your integrations conveniently listed if they’re in the same instance?”, I had serious doubts that this would match a user’s mental model.

Issue 3

The naming of features in the UI

For example, the word ‘dashboard’ had multiple meanings, resulting in a guided experience tooltip that read, “A dashboard for your Dashboard”; which was almost comical.

User testing on the existing IBM App Connect SaaS experience

Before our design team was formed, IBM App Connect SaaS had already been released. Knowing that limited user testing had been done, we wanted to evaluate the existing experience with users.

I collaborated with IBM Research to define the key experiences we needed testing, including the integration deployment process. 12 participants were sourced to identify critical experience blockers to address in this project.

The users we needed to optimise this experience for, in line with business goals, were business analysts (non-technical business users) which we refer to as “Tia”, while still catering for integration specialists (technical users) a.k.a “Isaac”. Tias had much less success than Isaacs, highlighting that we have a long way to go to optimise this experience for new non-technical business users.

Although we gained many useful insights, the 3 leading blockers found are provided below:

Experience blocker 1

Switching instances to deploy an integration (2/12 success rate)

Integration building and deployment were handled in separate areas of the UI, causing user confusion.

The 2 successful participants mapped to the Isaac (technical) persona.

Experience blocker 2

Downloading and re-uploading the integration for deployment (1/12 success rate)

When prompted to upload the file during deployment, users were visibly confused about where to find it; even though they had just created the integration in an earlier test.

The 1 successful participant mapped to the Isaac (technical) persona.

Experience blocker 3

Confusing integration status (8/12 participants affected)

Eight out of twelve participants mistakenly believed the integration was already deployed when it was actually in test mode.

This revealed a major issue with how integration states were perceived.

New pricing plan requirements

1. Abstracts the concept of runtimes away from the user; making them IBM-managed.
2. Usage is based on number of times an integration is run, rather than the resources consumed.

Kick off workshop

I ran a remote, cross-functional two-day workshop with designers, engineers, and PM to quickly align, iterate, and define a high-level user story for deploying integrations under the new pricing model. Informed by research and UX audits, the story was shared across teams to drive alignment, gather feedback, and kick off detailed designs and further testing.

Workshop structure

The workshop was a cross-disciplinary effort, bringing together four designers, two engineers/Subject matter experts (SMEs), and one product manager. This diverse mix allowed us to get questions answered in real time with SMEs and iterate quickly.

Held remotely over two days, the workshop ensured full-team focus while accommodating US participants and ongoing COVID-19 restrictions.

Outcome

We created a comprehensive user story for deploying integrations under the new pricing plan, informed by in-depth research, a thorough UX audit, and key requirements.

This story was shared with the broader App Connect and IBM integration teams, fostering alignment and gathering valuable feedback. This collaborative approach ensured the story was well-rounded and robust, setting a strong foundation before moving to the next stage of refinement.

Next steps post workshop

This story enabled us to start iterating on the details of the proposed experience through additional sketching, wireframing, visuals & further user testing.

Example activity 1

Assumptions, questions, research insights & ideas

After establishing an initial understanding, I find it crucial to give participants a safe space to raise any questions or note assumptions they may have. These can be addressed immediately by other participants, or, if unknown, can highlight key areas to validate after the workshop. This ensures that no part of the story is based on assumptions, minimising risk.

Additionally, I find allowing space for participants to quickly generate initial ideas based on research insights helps capture immediate thoughts and ensures everyone’s input is heard.

Example activity 2

Ideation/storyboarding

I encouraged participants to create their own storyboards for Tia and Isaac based on the ideas generated during the session. These storyboards were then voted on, with the most favoured concepts forming the foundation for a high-level story.

This rough story was then translated into a Figma prototype, which was presented during the workshop’s final playback.

Example activity 3

Alignment playbacks

Playbacks are essential for aligning the wider team with our planned experience updates. By me presenting the updates from Tia and Isaac’s perspective, the audience can better empathize with the desired experience and understand the benefits, making it easier to gain buy-in.

To ensure we captured all feedback, I set up a feedback form that allowed everyone to log thoughts, suggestions, and concerns throughout the session. This approach ensures that all voices are heard, preventing dominant voices from overshadowing others and helping us gather a comprehensive set of insights.

Ideation

This section demonstrates how the designs evolved in response to restrictions, scoping, and further user testing. While there were many more smaller feature enhancements, rounds of iterations and playbacks than are shown here, these are the most important ones to call out.

Although I led the majority of the UX design, I used this project as a hands-on mentoring opportunity for our studio’s UX apprentice; guiding them through real-world challenges while ensuring we delivered high-quality work.

Early designs

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

Update 1

Removing the instance switcher

The first design change was the removal of the UI switcher, allowing all pages to be presented side by side within a single side navigation. Additionally, all integrations, regardless of state, were consolidated onto one page as there were additional user comments that they don't mentally separate integration authoring from deploying.

This addresses “Experience Blocker 1” from user testing, which had a 2/12 success rate, as well as “Issue 1” from the UX audit.

Update 2

Providing a deploy option alongside the authoring experience

Enabling Tia and Isaac to deploy an integration during the build process makes the next steps clearer, reducing confusion about the integration’s state and helping them progress more smoothly.

This addresses “Issue 1” from the UX audit.

Update 3

Available integrations provided at the point of deployment

Instead of requiring users to download and upload a file, integrations were presented in a list at the start of the deployment experience. This initial design was produced by our UX Apprentice!

This addresses “Experience Blocker 2” from user testing, which had a 1/12 success rate, as well as “Issue 2” from the UX audit.

Update 4

Confusion around statuses

This was later addressed in a separate work item, where we conducted a cloze test to understand how users perceived each state.

Re-evaluating integration states was a significant effort, as it impacted the product beyond SaaS, affecting both our software and container offerings. While this issue was eventually resolved, it was not addressed as part of this project.

Restrictions & Solutions throughout the ideation phase

Restriction 1

We were told we couldn't contain deployment initiation within the authoring experience due to engineering constraints and we were concerned other items might take priority so we needed evidence that this was needed.

Solution

Additional user testing (9/9 success rate) confirmed key experience blockers were resolved. However, it revealed that users’ mental model prioritises finding an integration before deploying it; not the other way around. This insight drove prioritisation of the feature for the second half of the year.

Restriction 2

Combining the authoring and deploy experiences wasn’t feasible due to the architecture of the Software and Container offerings, which were out of our control.

Solution

Given the scale of App Connect and the significant revenue from other offerings, re-engineering the shared codebase was unfeasible. Despite the desire to enhance the SaaS offering, I recognised that pushing for this change would have jeopardised the broader business, so I refrained from pursuing it; meaning authoring and deployment management were kept separate.

Implementation of designs

Here are the key stages of implementation for this project.

MVP (Phase 1)

These were the minimum designs required to address the critical experience blockers identified.

The engineering team was a newly formed group from India, so we implemented weekly remote check-ins to ensure collaboration, feedback sharing, and ongoing discussions. This allowed them to provide input not only on implementation but also on the latest designs. We structured the handover process in sprints to maintain flexibility in delivery.

I was responsible for all new UX updates as part of this (our apprentice transitioned off the project before we got to UX refinement), with support from visual design for general guidance adherence.

Enhancements (Phase 2)

Once the MVP was implemented, we moved on to additional enhancements, such as introducing the ability to deploy during the authoring experience.

By this point, the design and engineering teams were working together efficiently to deliver the project.

My contributions to this stage mirror phase 1; I was responsible for all UX updates/decisions.

To our delight, this pricing plan became the most favoured plan to demo (over the existing one) due to how much more seamless the user experience was for sales and customers to understand. This feedback validated our input.

What about the existing plan with that outdated UI full of experience issues? (Phase 3)

After delivering a vastly improved experience for the new pricing plan, which received strong praise from the wider team, we turned our focus to the outdated UI and persisting blockers in the existing plan.

We successfully pushed to prioritize this in the second half of the year. With buy-in from PM and the engineering lead, it became the top priority in the backlog, allowing us to allocate resources for additional designs and front-end development.

We needed to consider how runtimes played a part in the new experience so, although the experience was as consistent as possible, we had some additional designs here to produce.

This required me to level up my technical understanding further as runtimes are incredibly complicated; from understanding the need for containerisation to advanced configurations. This meant more advanced UX design was required on my end.

By the end of this stage, engineering had fully implemented all design updates; leading to a drastically improved experience.

Project feedback

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

Design Lead, IBM App Connect SaaS

"You fully embrace the value of data for making decisions. You are always asking me for research and you’re 100% focussed on creating designs that solve user problems. For example, the usability study for deploy - you listened to the problems, then created designs to solve them, then you listened to the feedback on those designs and iterated again."

Architect, IBM App Connect

"Now that we are at the point of implementation, I am also really grateful for the time you are spending with the engineering team and I know that they really appreciate everything you are doing and being available for them - would be great to keep this relationship and dynamic continuing moving forwards."

Engineering Manager, IBM App Connect

"We had a very pleasant experience working with you. The regular calls and the Slack conversations were very effective to share progress, learn, clarify doubts and discuss any changes. Never felt like it was a new team we are working with. All the conversations we had were very clear and efficient. We got all the required design input well on time, sometimes even before in our handover calls, to meet development commitments."