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”

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.

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:

Customisable screen layout

• To overcome the issue of displaying tickets that overlap each other, we needed to revise the design in order to ensure that tickets could be shown and prioritised without obscuring key information.
• I therefore designed a screen layout which users could adapt to their preferences, using the rule established above, showing prioritising components showing tickets, or supporting information, in a way that suited their own workflow.
• Traders could set up the screen the way that they wanted, save them, and even share them with colleagues, as we found that many Traders would often copy from the one Trader who had taken the time to revise their set up.

Working with tickets

• Also following the trend that we had identified, we wanted Traders to be able to be able to customise the ways in which they viewed and worked with tickets within the tickets section of the app
• We wanted tickets to be able to show either fewer large tickets onscreen at one time, to show more supporting information, or more smaller tickets with less supporting information, depending upon where their Trading style fitted on our trend line.
• Traders could also arrange “triage”, setting criteria to sort tickets into ones that they dealt with themselves, or ones that they could get the application to deal with automatically (such as refusing tickets that were below a certain price, or changing settings to cope with high traffic periods).
• To give the Traders more control, we built in the ability for them to check these automatic trades “under the hood”, ensuring that they could quickly check and see that things were going as they had planned.

Improving functionality

• • As speed is the essence with RFQ trading, Traders expressed the need to be able to adjust bid prices quickly and precisely as a counter offer before returning them back for confirmation.
  • Observing the ways in which the Traders worked, we found that they relied on mouse input, and didn’t want to keep swapping back to the keyboard. It was because of this that we developed the “daisy wheel” approach, allowing users to quickly adjust big prices in set increments in a controlled way.
  • This also allowed us to show other prices, so the users could stay informed with adjusting their bid without having to look over at another side of the screen.

Creating a design system

• As the sole designer on the team, I had to redesign numerous components, each of which had to be reviewed by stakeholders and tested with Traders.
• This led to numerous revisions of components, which had knock-on effects to other elements within the user interface.
• In order to reduce workload and maintain fidelity, I devised an atomic design system defining 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 testing to demonstrate how, by understanding the differing needs of the Traders, we could recreate the platform into a much more functional and intuitive interface.
• 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?