Guerrilla UX in a pandemic: encouraging best practices in adverse situations

Highlights

“Improving a complex user interface in an adverse situation to demonstrate value to the client”

[images of user interface]

Context

During the pandemic, I worked with a UK software consultancy, and was placed on a team supporting a major international bank. Our team was initially tasked by the client to work on a “lift and shift”, converting their RFQ (Request for Quotes) bonds trading software from the soon-to-be deprecated Adobe Flash platform into a modernised HTML5 version. Initially, the client expected me to provide simple User Interface design support, converting the original user interface with only a few tweaks. However, when speaking with their subject matter experts, I found that their system had some significant issues in their user experience, which needed fixing. However, I also found that their Product Owner didn’t really appreciate the value of user experience, and so it was up to me to demonstrate the value of what I was doing while working to improve the product.

The Challenge

Justify the value of improving the user experience of a complex system to a skeptical client, working remotely during a pandemic.

Research

Initial explorations

• My initial steps into understanding the situation started with conversations with Subject Matter Experts – developers and business analysts who worked on our client production team who had knowledge and experience of how the software was originally designed and built, as well as colleagues within the consultancy who had experience in creating similar systems
• Through these discussion, I managed to improve my understanding of the context of Bonds trading, as well as previous issues with the platform that we were rebuilding
• I was also able to pull together a picture of how the Bonds RFQ trading process worked, mapping this out in a user journey (shown below) that allowed me to also identify possible pain points and opportunities for improvement
• This work prepared me for conversations with actual users, knowing what to ask and areas to explore, making my research process more efficient and successful.

Speaking with traders

• Bonds trading involves different teams, known as desks, each of whom have their own particular requirements for the software, and so I asked the Product Owner to put me in touch with representatives from each desk, to get a full understanding of those requirements.
• As this was during lockdown, conversations took place remotely, either by video or audio call, and were sometimes early in the morning for traders in East Asia or later in the day, for those on the West Coast of the USA.
• As with other projects, rather than get a “laundry list” of requirements, I spoke with them about their work, getting them to describe the RFQ process to me, and what they looked for while they traded (in cases of complex context, understanding method and motivation provides the data you need to identify opportunities).
• The traders were unable to stop trading while being interviewed, and so I had to adapt and anticipate interruptions every 5-10 minutes during our conversations, grouping questions into small bunches to ensure I got the answers I required before any interruptions and the trader losing their train of thought.
• Despite this somewhat adversarial situation, I found that the traders were keen to talk about their work, and provide in-depth insight into their experiences with the current system, allowing me to validate hypotheses and identify opportunities to improve the system.

Examples of my questions, showing gaps between every 3-4 questions, to anticipate interruptions.

Discoveries

Major discoveries that came from my research

• In RFQ Bonds, much like other trading, speed and accuracy of communication are absolutely essential toward making successful trades.
• The current system had been initially built as a solution for a few desks, and was rolled out to other desks over time, which led to those desks making new requests for features and functionality to be added to it.
• As the extra features were added after the initial development, they weren’t considered within the scope of the overall project, which led to experience rot. This made the system slow down and harder to use, and led to traders missing important trades.
  • One example of this was the any in which RFQ “tickets” (small windows showing details of each trade) would overlap each other, each with bright colours and making loud noises as they appeared, which meant that the experience could be quite confusing and frustrating for the traders.
• Speaking to each trading desk, I found that they could be placed along a scale based upon their requirements:
  • At one end, some desks trade a high number of tickets per day, requiring less supporting information, such as analytics, in order to make their trades
  • At the other end, other desks traded fewer tickets per day, but required more supporting analytics information in order to make their trades.
• Traders would triage tickets, sorting them into ones that they wanted to deal with themselves, or others that could be ignored, or traded automatically, based on specific criteria. This was particularly important during times of high traffic, such as the end of each day, when traders are trying to get rid of all the tickets they are holding, so that they don’t become swamped with information.

Demonstrating value through discovery

Following my research, the Product Owner was keen to see some visual progress of my work, and I felt it was best to demonstrate the value of my efforts with ideating and testing assumptions through low-fidelity prototyping, which I could test with him, the Subject Matter Experts and Traders, in order to answer questions while showing progress.

Below are some of the concepts I experimented with:

—

Demonstrating value through discovery

• Following my research, the Product Owner was keen to see some visual progress of my work, and I wanted to demonstrate the value of what I had discovered.
• Therefore, I made the decision to work on an Agile iterative wireframe approach, in order to have visual representations of early concepts, which I could then demonstrate to the Product Owner, Subject Matter Experts and Traders, in order to gain feedback.

Customisable screen layout

• It was clear that the platform needed to present multiple tickets clearly to the traders, without overlapping each other, and that they needed to be able to amend their displays to show information that they found important.
• The first step was to establish a customisable screen layout, where traders could build the layout that suited their needs, as well as save that layout, and share it with others (we found that Traders preferred to copy each other’s set-ups, rather than define their own).
• Within each section, further customisation would be possible, so that traders could see just what they needed, and nothing else.

Working with tickets

• It was important that we gave Traders the ability to work with tickets in a way that suited their requirements, so we devised different approaches:
  • Showing larger tickets with more information
  • Displaying tickets stacked horizontally, so they could see the stream of incoming tickets, and work with multiple tickets at once
  • Traders could also set rules to have the system deal with tickets automatically, if they met certain criteria (such as everything below a certain value would be automatically declined), these could then be put into a “drawers” so that they are out of the way, but can be checked, if required.
• This meant that Traders could “triage” tickets, to display the way that they wanted, and also could adjust these rules for different behaviours for busy periods, so that they weren’t overrun with tickets.

Numeric inputs

• As mentioned, speed is of the essence with RFQ trading, especially when countering by adjusting a quote and sending it back as a counter-offer.
• We therefore needed to provide a way for traders to make quick, precise adjustments that they could be sure of, before sending them back.
• We explored a number of options, and ended up settling on a radial “daisy wheel” approach, with buttons around the input box, allowing for rapid mouse changes, as well as mouse input.

Pulling ideas together

Atomic design system

• The previous system was being continually added on to, leading to a confusion on messaging, information and alerts.
• I therefore devised an atomic design system, which defined everything based upon a hierarchy:
  • Atoms (smallest possible items, such as buttons or labels)
  • Molecules (combinations of atoms, such as an input form)
  • Organisms (groups of molecules, such as a ticket)
• This helped to define onscreen colours, information and messaging that didn’t fight for the user’s attention, and helped them to focus on what was most important.
• Due to the modular nature of the design system, this also helped the Development team to produce a modular component system using Storybook, meaning that quick changes to the master would cascade down to code that had already been implemented.

Conclusion

• Despite the fact that the project wasn’t started with design thinking in mind, I was pleased to have been able to conduct research and a small degree of testing to demonstrate how we could make the trading system better by understanding the needs of the different trading desks, and designing to adapt the platform to their needs.
• The initial engagement lasted three months, after which I was moved on to another project, only to be asked back again by the Product Owner, saying that it was important to have me on the project, as I was “the only Designer available who understood the context”.
• The product has since been implemented, and reports have come back saying that Traders find it much more efficient and intuitive, leading to faster trades, and reduced stress during busy periods, both of which were objectives that I outlined during my research, and agreed with the client.
• I was later asked to be part of a town hall interview at my consultancy, explaining the work that we did, and how we made it into a success. I also wrote an in-depth analysis of how and why you should conduct better user research in your projects, to help demonstrate to colleagues and clients why design should be considered at the start of the project, and how that can help to make highly successful outcomes.

If you’re interested in how I can help your complex project to be more successful, why not message me, and we can discuss your requirements?