Building a proactive design strategy through user intelligence

Highlights

“ Developing a product strategy that leverages industry knowledge to demonstrate value to a wider audience”

[Screen shot of data platform website]

[Other screenshots to be created]

Context

The company had established themselves as a successful trader and broker within the energy commodity derivatives space, including producing their own software for trading in oil derivatives. Their aim was to increase their technology offering, leveraging output from their successful Research, Data and Media teams to increase appeal and buy-in from their customer base, which included major energy companies, as well as traders and brokers within the commodities derivatives markets. My goal was to identify ways in which we could increase that appeal, whilst building out the design team to support both existing projects as well as new initiatives.

The Challenge

Create a way for the company to leverage their considerable domain expertise and demonstrate value to customers to increase revenue.

Building the foundation

Creating a design team

• Previously, the company’s design team consisted of a single designer, working to support production teams in something of a reactive capacity, working off change requests from stakeholders, and limited in scope.
• To approach the challenge outlined above, we needed to be able to develop a new strategic design approach, while also supporting the existing product teams.
• I started by hiring two User Interface designers who could create concepts, wireframes and design components for the product teams, using Lou Adler’s Performance based hiring process, and ensuring that we encouraged a more diverse set of candidates, and a better range of choice for the roles.

Creating a design strategy

• In order to ensure that we could demonstrate value to customers, it was key to to understand what those customers actually wanted
• My plan was to not only conduct research that informed work on existing products, but to also provide intelligence that informed strategic decisions, supporting the work of management, market intelligence, marketing and more.
• Starting with interviewing internal traders, brokers, researchers* and other stakeholders, I built up a picture of the different user types and their individual requirements
• From which I could then create “information radiators” – artefacts such as personas and user journeys, which I could then use to share insights with teams and stakeholders, and validate design decisions.
• These provided a basis from which to build, conducting interviews with external traders, brokers and other industry experts in order to get a wider and richer understanding of the different requirements

[images of personas]

[images of user journeys]

Discoveries

Insights gained from research with users included:

• Awareness: a number of traders interviewed expressed lack a knowledge of the platform or the company’s other offerings
• Reticence: many traders still used Excel sheets to track price movements, which, although unwieldy, provided them with the ability to customise the data they worked with
• Varied sources: as part of their work, users needed to consult a range of different sources or data and news, as well as communication channels. These often got quite complex and hard to keep track of
• Customisation: the majority of users interviewed expressed an interest in only one commodity or specific markets, and wanted the ability to tailor their view to show just the areas they were interested in.

Ideation

• Leveraging different expertise
• Combining information sources
• Customising information view
• Adapting to different screens and use cases
• “Dawn to dusk” information service
• Try before you buy approach

Approach

• Communicating findings: providing weekly updates to management and heads of departments, sharing insights and updates, combining together Confluence wikis as a platform to store and share information.
• Demonstrating value quickly: creating a website to show off data sources, which would generate interest while longer-term work went on.
• Build, measure, learn: developing an approach to building out what would be a large project, testing concepts and challenging assumptions with users and stakeholders (especially as they were more expert in the subject matter than me), preventing any surprises and ensuring a successful product.

[To be continued]

Retrospective

Project takeaways:

• I managed to establish a proactive design team, who worked alongside product development teams to ensure that strategic decisions were based upon evidence from user and business intelligence
• This also challenged the culture of C-level executives changing direction every few weeks, leading to more direction and reduced stress for product teams
• While the company decided not to continue with my plans for the product, they said that they felt I had done some excellent work, and I had provided them with a good template for future product developments.
• I also feel that if this work had been continued, it would have provided a highly competitive advantage in an industry which had been lacking in innovation.

Sharing the benefits of UX with colleagues and clients

Summary

I‘ve worked with a number of companies in my time, all with differing levels of UX maturity. In this case study, I’ll share some of the ways in which I’ve advocated for better awareness of UX practices, and provide ideas around how you can share them with yours.

Introduction

When you join a new company as a UX Designer, one of the first things to understand is the level of UX maturity within that company. Are they carrying out end-to-end full UX processes in their projects, involving non-UX colleagues in their processes, or are they confused between UX and UI, and end up with meetings full of designers pushing pixels while product owners dictating how the product should work, without a user in sight?

The introductory “What is UX” presentation

In many cases, you will have to introduce yourself to your colleagues, as well as set out your stall as a UX practitioner within the company. One popular way of doing this is the “What is UX” presentation, a deck of slides that help introduce those less familiar to how you’re going to introduce better UX practices, as well as providing details about your team, and your plans over how you’re going to implement your plans, ideally liaising with colleagues outside your team to ensure buy-in from everyone involved. This presentation is often given as a roadshow, giving you a chance to travel to different offices and meet colleagues. What’s more, this often also allows you to identify people who are interested in the processes you are talking about, and might become useful advocates later on.

Information sheets

Whilst a presentation might be useful in informing people of your plans, it is also useful to communicate smaller concepts with colleagues and stakeholders during projects. One such method we devised was designing “One Page UX Processes”, a series of one page PDFs which we could use as a tool to help explain a concept to someone, and then leave behind with them to later review, or share with others. We designed the sheets to give a high-level overview, explaining what each concept is, how it works, and the benefits of using it.

Remote ideation workshop

People often learn better by doing, and, when asked to provide a short workshop during a remote office activity afternoon, I saw the opportunity to provide something that would both educate and entertain. I therefore devised a small ideation workshop, which would help my colleagues to learn about the UX process, as well as having a chance to be creative, think in ways they were not used to thinking, and even introduce a note of competition around the solutions they created.

I worked out a simple open ended problem, asking them to devise a route-finding application, and then created three personas – an old man, a blind woman, and a cycle courier. I introduced the team to the problem and these three personas, and asked them to draw a solution which took the requirements of the three personas into consideration. Of course, I assured those who said that they couldn’t draw that this was conceptual, and they could communicate their ideas using boxes, arrows and wording. I gave them about 20 minutes to draw, and then asked each person to share and explain their ideas with the group, encouraging the rest of the group to ask questions and provide feedback after they had finished. The group said that they found the session highly enjoyable, and felt that they appreciated how UX design was focussed upon user needs, rather than something dreamed up by the production team.

Blog posts

UX is a continual learning process, and during my work, I also make interesting discoveries. I was invited to share some thoughts on the company blog, and so again used this as a teaching opportunity. I wanted to share details about the importance of an iterative approach to software production, but felt that just talking about that could be seen as a bit dry. I remembered the story that I had read when I was young of Percy Shaw, who discovered Cats Eyes, the road safety feature that lit up the centre white line of the road by reflecting car headlights back at them. I remembered in the story about how Shaw had iterated numerous times on his design, and had even literally “road tested” his creations on a stretch of country road late at night himself, eventually gaining a contract with the Government to produce them for UK roads, after streetlights were put out to evade bombing runs in World War II. This blog post gained praise from colleagues and clients, and became a useful link to share with people who tried to cut corners when it came to testing the products they were building.

You can read my post here on the Scott Logic blog.

The most important part: conversation

All of the above initiatives can be useful ways of communicating ideas, but their efficacy is severely diminished without one important element – conversation. This could be discussions of UX processes during a project, a chat with a colleague during a coffee break, or any number of touchpoint interactions where you get the chance to discuss how you can help with a problem. The conversations help glue together other initiatives such as the ones above, and help remind people of their existence, so that when a situation arises which could benefit from these approaches, they turn to UX for help.

As previously mentioned, you can also use these opportunities to work out the people who are more receptive and excited by how these ideas can help. These people can often turn into advocates, who can help you spread the message, and, if they are senior, might even help effect change within company-wide practices.

Conclusion

Hopefully some, or even all, of these ideas will help you share the benefits of User Experience within your own work. If you have any methods that you would like to share, or even if you used some of the ideas above successfully, please let me know!

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?