Designing the IBM z/OS Connect user interface

This section of the case study explores the design and development process of the IBM z/OS Connect user interface.

To set the scene, IBM z/OS Connect is a well established product with 7+ years of investment on the Eclipse IDE platform. In 2019 the decision was made to shift the product to the web based experience, enabling the product to expand into new markets, and speeding up our users time to value. For full details of the design research that led to this product change, please read Defining the future direction of IBM z/OS Connect.

The first stage of the design process was mapping out the users journey through the existing z/OS Connect eclipse interface. This ensured we had a clear understanding of how to create a Db2 API in the existing tooling, and served as a basis for future discussion with the clients and team.

The second stage of the design process was to explore the other products in IBM’s integration suite. The objective of this research was to understand what UX patterns had been used, then utilise similar patterns to create a familiar product experience where possible.

To achieve this we mapped out the product experience for multiple IBM products including IBM App Connect, and IBM API Connect.

The next stage of research was to build a better understanding of the ‘contract first’ process. This was a key requirement identified during the preliminary research whereby users wanted to build an API starting with an OpenAPI contract that had been defined by the business.

[Slides from: 2021-04-08-design-partnership-playback-deck]

Our design research later informed the creation of our to-be user scenarios which outlined the steps of creating a Db2 API in the tooling.

With a clear understanding of our requirements we began exploring possible designs for the interface. During these early stages we explored the different scenarios to give us an overall understanding of how the end product might fit together. We did this to ensure we weren’t design ourselves into a corner as more functionality was added in the future.

Throughout the design process we shared the designs with our clients to get their feedback. While we received some great feedback from clients, it became increasingly evident that our clients saw these screens as the final designs rather than early mock-ups. We concluded as a team that we needed to share low-fidelity mockups with the clients to better validate the flow.

Critique sessions were organised with the development team throughout the design process. These sessions gave the team awareness of the direction we were moving in and provided a forum for the team to give feedback at the earliest possible point. These sessions were fundamental to ensure the designs were technically feasible, and allowed the team to start thinking about implementation.

As a team to we painstakingly critiqued each screen, assessing the ordering of steps, the language used, and the UX patterns. After each session we’d collate the feedback and create the next iteration of the designs.

Having created a vision of the overall product, we sought to narrow our scope and define a minimum viable product (MVP). I.e. the smallest thing we could deliver that could provide our users with value. As a team concluded to firstly build the ‘contract first flow’, and removed a lot of the non-critical functionality.

Having defined our MVP, we began to build a low-fidelity prototype. By building in low-fidelity we hoped to focus our users on the core steps of the flow, and give them the perception that this was not a finished product.

Once the designs were refined we began testing. These early user tests sought to validate basic navigation of the UI, and the ensure the API visualisation matched our users mental model. We conducted these tests with a selection customers and IBM stakeholders. These tests were carried out by supplying our users with a written scenario, then asking them to complete the task in the prototype provided. We asked our test subject to talk aloud throughout the test so we could better understand their thought process.

4 Customers
6 IBM stakeholders

As a team we gathered to discuss the feedback we received from our clients and IBM stakeholders. While all the feedback was valid, we had to make a decision what could be implemented in the short term, and what would be added to the backlog. We had constraints on time and development resource and therefore had to define a Minimal Viable Product (MVP) that would serve as a foundation for future development.

In light of our feedback and subsequent prioritisation, we created the next iteration of the prototype. We later carried out the same test with the same subjects to validate our improvements. During these tests we also shared our prioritisation grid with the clients to communicate our current vs future intentions.

Having tested multiple iterations of the lo-fi designs we were confident to begin creating hi-fidelity designs. These designs would introduce stylised elements based up IBM’s Carbon Design System. We continued to refine these designs based upon the feedback we had received from the previous round of testing.

As with the low-fidelity designs, we continued to test the hi-fidelity designs with a group of clients and IBM stakeholders. In the same format as our previous tests we provided the test subject with a scenario and a prototype, then asked them to complete the given task. To give the perception that these were unfinished designs, we converted each screen to greyscale.

6 Customers
5 IBM stakeholders

A limitation of our testing was the shortcomings of a clickable prototype. During the tests our users wanted to explore the UI freely, but the prototypes were only built with the golden path in mind. It was decided from this point that it would be more valuable to test and refine the coded solution.

After further refinement and testing, the high-fidelity designs were ready for development. To aid our developers we created detailed specifications of each component and how this was satiated in the flow. The specifications would include the following:

Development was a very collaborative exercise, and by no means a ‘throw it over the wall” process. Throughout the development process we maintained close communication with our development team, we were always on hand for calls, always testing early prototypes, and often re-factoring the design to capture details that had been overlooked.

We’d produce a number of artefacts with the development team including; component reviews, accessibility reviews, and test plans to ensure the product was well implemented.