The mother of all simplifications

This project illustrates one of the most powerful impacts of good UX design - simplifying a technically complex, multistage, esoteric process down to a simple matter of filling in a few boxes and running a handful of commands.

High level outcomes

Time on task reduced from several hours to a few minutes

Interface transitions reduced from 25-30 to 2 or 3

Steps taken reduced from 40-50 to 4 or 5

User sentiment changed from frustration to delight

The essentials

The project

Use UX processes to audit a complex process, looking for opportunities to reduce time on task and improve usability.

My role

Overall driving force and co-ordinator of the project, advocating for the prioritisation of this work and connecting teams to ensure that we took every chance to enhance and shorten the journey. Instrumental in the early stages to ensure that the existing journey and pain points were captured and communicated clearly, demonstrating the need for the project.

The impact

We took an almost impossibly complex task and reduced it down to a few simple steps. Users who would not have attempted the original process were able to successfully follow the updated journey in tests.

Challenges

The initial process was so complex that digging into the needs of the users was more challenging than normal. Users were so wrapped up in the existing issues that separating desired outcomes from current pains required an iterative research process and some carefully guided role-playing ("imagine this product didn't exist, how would you approach these tasks?").

The basic complexity of the actual task itself (regardless of the software) was also an issue, requiring us to spend longer with developer getting domain knowledge, which we had to validate repeatedly. Our "challenge everything" motto was tested to the max.

The problem

An inherited process for connecting external cloud-hosted systems into the product was far too complex. Even though it was aimed at users with good technical understanding of managing cloud computing environments, the process required too much bespoke knowledge, bouncing back and forth between systems (command line, UI, help, etc.) and was highly prone to error.

The UX team was asked to investigate whether this process could be simplified.

Part 1: validate JTBD and design ideal journey

First, we returned to the basics, developing a clear and agreed-upon understanding of what the user wanted to achieve and what success would look like. We also established the typical level of technical competency among the expected user group.

We conducted interviews with both internal experts and external users to define the feature scope. From these insights, we identified the ideal user journey, including upstream precursors and success criteria at each stage. We collected high level insights into the particular pains of the process, with an eye on filling those out more completely in the system usability review (part 2 of the process).

The JTBD and associated journey were quite straightforward, especially when compared to how this was being delivered in the software. Above you can see the JTBD hierarchy for the task (following the GitLabs method), and below a simplified view of the journey we used to share with users when carrying out reviews (which doesn't show failure modes, loops and branches and all the other little things which make journey maps useful for designers, but cluttered for everyone else).

Part 2: System usability review

We knew the existing process wasn't great, but we didn't have the expertise in the UX team to understand what was poor UX design, and what was sub-optimal at a code level.

We asked several users of the platform to attempt the journey mapped out in stage 1, using their existing knowledge and available resources. We requested that they screenshot and annotate their journey, recording their thoughts and feelings along the way, alongside failure points. These outputs enabled us to identify the most problematic parts of the flow and carry out some early-stage ideation.

A key outcome of this process was a clear understanding of where issues arose. We identified numerous failure points and began the process of collaborating with developers to determine which issues could be mitigated through code changes and which required careful UX design.

The following is an extract from one of the review maps generated by a user. Please excuse the low resolution of the thumbnail images of the UI, this is to protect IP. In the actual process, these were full sized images.

We asked the users to take us through their journey review in detail, allowing us to record their experience in their own words, then ran the resulting conversations through Condens to clarify key insights and build up a picture of common frustrations across users.

Part 3: User insights and tech collaboration

The key insights to come out of the usability review were:

There were far too many transitions between different systems. It would be far easier to follow the flow if the user mainly worked in either the UI or the command line, while they were building the commands to run on the third party server.
There was no visibility of connected systems in the UI, only through calls to system APIs. Whilst the typical user was capable of doing this, it was inconsistent with the rest of the system.
The docs pages explaining the process were as complex as the process itself. They only served to illustrate how complex it was.
It was difficult to know if the process had been successful.
Users were asked to do things which didn't make sense (and that the system could easily do on their behalf).
Details required for configuration files were obscured behind names which didn't make sense (in both the API and the UI).

We explored two routes to solving these issues:

What could the system do itself without requiring the user to do anything (either by command line or UI)?
Could we simplify the user journey so that all of the capability was available without having to switch between systems so often (if at all)?

Tech collaboration

We tackled the technical angle first. There seemed to be a lot of instances where the system knew exactly what would be required to define scripts based on settings, which the user could then run on the third party server to get the connection up and running. It turned out these could be delivered as a 'push button' feature with relatively little coding.

Our collaboration with the development squad responsible for the feature, as well as some technical architects from across the product team, allowed us to eliminate quite a large number of steps; for example, a stage where the user had to set up a system user to authenticate the connection could all be done in the background, with zero user intervention (or even knowledge that it had happened).

This had two key impacts:

The user interface could be a lot simpler.
If using a command line to make the connection via system APIs, this was also considerably simplified.

Part 4: Ideation, design, iteration

Once the collaboration with the tech teams had identified a whole swathe of inputs we could remove from the process, we found we were left with very little to achieve in the UI. From a few inputs, the platform could generate all of the required commands from already-known system variables.

This left us with a relatively simple UI design process, which needed to support these steps:

Define the type of deployment (e.g. Kubernetes, Docker)
Generate scripts to be run on third party server to make the connection
Run a test command to ensure the connection was successful

Nevertheless, we took time to test our initial wireframes with internal and external users and experts. One key area of enhancement was inline help text - this was not a process which would be done often, so users needed a little more reminding than usual what to do, and pointers out to an enhanced docs page with much richer information.

We were able to successfully test this journey with users who would not have considered themselves capable of even attempting the original process.

The result

The development squad delivered a brand new experience based on our designs which:

Cut the typical time taken to connect the systems from several hours to a few minutes
Streamlined the journey from 40-50 down to 4-5 (depending on method of deployment)
Reduced system transitions (i.e. UI to command line, or UI to docs) from 25-30 down to 2 or 3
Modified user sentiment from frustration and anger to surprise and delight.