Photo by Maxim Hopman on Unsplash

Building a strategy to demonstrate proactive design value

Introduction

Starting as Head of Design at a relatively young commodities trading company, I quickly identified a common pattern that I had seen in previous roles – namely that the Design department currently existed as a reactive entity, addressing requests from development teams, management and other departments, leading to a focus on UI design work for production. I made a more proactive Design approach my objective, so that we could help provide research insights to help inform strategic decisions, and provide design value in a more holistic manner to ensure visual and functional unity across all of our properties.

Communication

To get this approach started, communication would be key – the company already had different teams spread across three offices, as well as teams working in a siloed manner, often unaware of efforts made by their colleagues. To start, I advocated for a single unified Confluence wiki for all the technology teams, and ensured that everyone involved with those teams, from the most junior developers to the CEO, were able to access the pages on the wiki. This resource would become a central repository which would record all our efforts, from initial ideas through to final releases, and provide a way for anyone in the company to come and review our work.

It was here that I was able to define the structure of my plan above, and share it with C-level executives and other department heads. This came a regular weekly update, where I could provide an email, summarising our work and progress, and providing links back to the wiki for more information, not only keeping everyone updated, but also inviting opportunities for collaboration, and making use of more people’s skillsets.

Hiring

Previously, the Design discipline had primarily been part of the team working on improving the current design platform, and so it was important to maintain this support while also being able to expand out the Design offering. To get started, we arranged to hire an experienced contract User Interface designer, so that they could start supporting the production teams as soon as possible.

I wanted to ensure a fair hiring process, and so developed a job specification which was based around Lou Adler’s Performance Based Hiring method. Instead of a creating a “laundry list” of skills and requirements which can be intimidating to some demographics, I created a set of expectations for the role, based around what they would be going in three, six and twelve months, which not only helped them to apply their varied experiences to the role, but also gave better vision of how the role would evolve from UI support for a current project, to being involved in wire framing for future concept projects. I’m proud to say that, using this approach, we managed to encourage a more diverse set of candidates, and have a better range of choice for the role.

Research

Having secured UI support, I was then able to devote resources towards research. It was my aim to establish continual “rolling” research, so that interviews were being conducted with a regular cadence, providing continual insights as well as a resource to quickly get answers to any new questions which arose during production work. 

To start, interviews were set up with internal colleagues who made use of the trading platform, to better understand how they used it (providing insights into improvements) and also examining their work practices (understanding how the platform currently fitted into their work, and identifying opportunities for other ways in which we could improve their situation). These interviews were recorded, so that we could then listen back and draw out observations, which then acted as a central repository of insights to build analysis from, identifying trends between responses from different people, or different use cases for each. These insights not only helped to build a picture of needs for current and future versions of the platform, but also a wider picture of the way in which the needs of our users affected the direction for different products in the company.

Analysis

Taking the feedback, I was able to put together a journey map for each type of user, which allowed me to examine their interactions, flag up problems and opportunities, and highlight questions that arose from those discoveries.

These journey maps could then be combined to get a wider picture of the whole ecosystem, and understand the touchpoints where users interacted with the products, and well as their requirements when they weren’t using the software.

Some of the insights I collected included:

• Simplifying the user interface: previous versions of the platform had presented fill details to the user of all the different commodities and markets. It was clear from the research that the majority of users were only interested in one commodity, or specific markets, and they found it useful to show and hide information which wasn’t relevant to them.
• Combining interfaces: users found that the various products offered by the company, alongside other information sources, led to a confusing number of tabs to keep track of. This verified a business requirement to combine the trading and research products, as well as considering how other information sources could be integrated.

Ideation

I was able to share these discoveries with management and colleagues in a series of ideation sessions, which not only helped inform them about my discoveries and progress, but through a series of activities, we were able to make use of the skills and expertise of everyone involved to devise ideas and plan ways to address identified problems and develop new initiatives. These included:

• Architectural mapping with stakeholders: reviewing current information  architectures, identifying experience rot and obsolete features, and comparing user journeys to help product more intuitive structures which fitted with user expectations and requirements.[image of revised information architectures]

• Competitor review: investigating competitor products and presences to understand the wider market, identify gaps, understand where we can and cannot provide a unique value.
• Discussion and ideation: we were able to present findings to C-level executives and then discuss the impact these discoveries would have upon future company strategy and product plans.

Conclusion

These approaches generated some very good ideas for the future of the company and it products, and I feel that they would have certainly helped lift the company’s offering above that of its competitors. Sadly, the company decided that they wanted to follow a different direction. I would be very keen to evolve this approach and develop it for use in other companies, so that it can be brought to properly benefit them instead. If you are interested in this approach, and would like to apply it at your company, please let me know!

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

Summary

Working as UX Designers, we can often be put into situations where clients are unaware of the value of UX practices, and we have to not only explain that value, but to also demonstrate it. In this portfolio piece, I describe how I worked remotely on a technically complex project during a pandemic, with no affordance made for discovery and research, how I helped the client understand the value of what I was doing, and worked tactically to demonstrate value beyond their expectations to make an outcome that everyone was proud of.

Brief

• Working remotely as a consultancy team, I was part of a team brought in to improve our client’s bonds trading system
• The systems worked on a “request for quotes” mechanism, simply described as:
  • A trader will offer up bonds for trading
  • Other traders will make “quotes”, offering trades for the bonds, which come back as tickets on the system
  • The initial trader can accept, decline, or adjust the amount and send it back to the other trader as a counter-offer
  • This process continues until the trade is agreed, in which case it is them submitted for the trade to be processed, or the trade is declined, and the process starts again.
• Previously built using Flash, which was being deprecated at the end of that year, we were initially taken with “lifting and shifting” it to an HTML based solution, with my role providing user interface design support to the developers, creating design artefacts upon request.
• During initial conversations, I found that the system had been modified continually beyond original remit since it was launched, slowing down the process and obscuring tickets, leading to experience rot.
• This provided an opportunity to not only improve the development, but also review the design, finding ways to make the system address the needs of users, and help traders make trades more efficiently.

Research – initial explorations

• As I had very little knowledge of bonds trading, I conducted a series of discussions with the Product Owner and Subject Matter Experts, as well as colleagues within Scott Logic to improve my understanding of the process
• Through these discussions, I was able to build a simple user journey of the RFQ process, as described in the Brief above, which helped me to also identify assumptions to be challenged, as well as areas where problems might occur, and opportunities where we could improve things.
• This is what my initial user journey looked like:

Research – flexible interviews

• Using what I had learned, I was able to convince the Product Owner to put me in contact with some actual Traders to conduct research with, so that I could understand their current experiences with the platform, as well as challenge my own assumptions
• I managed to talk with 12 Traders, one from each trading desk, to understand the subtle differences in their requirements
• As this took place during the pandemic, I had to conduct the research over video and audio calls, which, while they proved fruitful, were not as ideal as actually being able to oversee the Traders in situ, but I did not have the luxury of that option at the time.
• One thing that I learned during my first few interviews was that the Traders were not able to stop trading during our sessions, and so would be frequently interrupted with loud noises and the need for them to break off our conversation and conduct a trade
• I therefore had to cut my questions up into sections, in order to try and anticipate these interruptions, and ensure that I got the information I needed before we lost the flow of conversation. You can see my interview script here, complete with the gaps every couple of questions:

Research – discoveries

The key discoveries I made through my research:

1. In RFQ Bonds trading situation, reaction speed and accuracy is key towards making successful trades
2. The current situation had initially built as a “one size fits all” solutions, and then continually added to by requests from different desks to suit their differing needs.
3. This led to the platform suffering from experience rot – the system slowing down due to increased demands, and the traders missing important trades.
4. This also led to problems with the user interface, with the current system showing information in overlapping windows that obscured important information, employing bright colours and loud sounds to grab attention with no bearing on other parts of the interface, leaving to confusing and combative messaging.
5. Each of the trading desks could be placed along a scale, with Traders at one end trading a high number of tickets per day, with less supporting information required to make trading decisions, and Traders at the other end performing fewer trades, but requiring more supporting information:

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?

Preventing the loss of customers through improving user experience

Summary

How do you improve upon something which has already been built? In the summer of 2015, I was brought onto a project that sought to stem the loss of subscribers to their flagship scientific database, and devised a way of seeking out users, identifying key problems, and showing value to them by making it easier for them to find that they were looking for.

Introduction

The company I was working for, an internationally renowned scientific publisher, had evolved their main scientific database product from a series of books of data that they had been publishing since the early twentieth century. Their product was known as a reputable, if not expensive, source of data, which presented a problem for them – despite their reputation, they found that subscriptions to their product were decreasing, and they could not find out the reasons as to why.

Starting research, and finding users to talk to

My initial attempts to understand the product were confounded by the fact that the company did not have access to the users. Their product was, in the main, purchased for an institution by a buyer, a librarian or facilities manager, who had control of the purse strings, but didn’t have much in-depth knowledge of the information provided in the database, meaning that my company’s salespeople could not get any feedback from them, or even manage to get details of any users with whom I could conduct research.

The way I overcame this was to conduct my own campaign of finding users. I researched academic institutions and scientific companies who were our clients, found people who were responsible for the relevant sections, such as heads of departments, and wrote to them all, asking if they would be willing to provide people to help with my user research studies. As an incentive, I also managed to secure a supply of book vouchers, which could be given to participants, encouraging them to sign up (ironically, while younger participants were happy to receive the vouchers, many of the more established participants, such as tutors and professionals, were happy to take part just to help with improving the product). This campaign took some time, and, on average, I would have a positive response from roughly 1 in every 20 emails I sent, but, after some time, I began to build a stable of willing participants, with whom I could conduct research sessions.

The main aims of this research was to understand context, and so I asked a range of questions, starting with more basic ones, such as:

• What do you do in your everyday work?
• What challenges do you face in your work?
• How does this database help you with this?
• Is there anything that the database doesn’t have, but you would like to see?

I would then move on to more precise questions, understanding how they use the site, what kinds of information they are looking for, and even asking them to show me how they would go about trying to find a particular piece of information. This gave me a picture of the different types of user, what they were looking for, and how easily they found that information.

Improving user flows

Given the information I had gained from the user research, I could then put together a picture of the “red routes” – key popular user flows through the site, and examine how easily they were found, and my examinations turned up some surprising results. It turned out that one key route to find a particular piece of information consisted of navigating through six different screens, and then having to download a PDF to find the relevant piece of data. Looking at the analytics for this path clearly indicated that at each of the six screens, users were becoming frustrated and leaving the site.

This was a clear indication of experience rot, contracted from the fact that the site had been continually added to over time, without consideration of overall scope, leading to a degradation of the user experience. What’s more, keeping the information on scanned PDFs, meaning that they weren’t machine-readable and could not be indexed, and the separation of the data on the PDF from the rest of the site often resulted in further loss of users, as they were not encouraged to engage with the site further.

In order to address this, I worked, not only to reduce the number of screens needed to locate a piece of data, but to also understand what users did before and after they came to use the database. Did they write the information down? Did they print it, or copy and paste it into another application? By knowing this, I could therefore understand not only what users were looking for, but how they were using that information, even after they had left the site, and therefore design the site to demonstrate value to them, encouraging more frequent interactions.

Digitising data

To further improve the process of locating data, it was key to digitise the data found in the PDFs. This not only put the data on the actual site, reducing the chance of users navigating away from the site, but it also made it machine-readable, meaning that it could be found more easily in search. This process, however, was quite lengthy, as it involved much persuasion of stakeholders to invest resources in getting subject matter experts to go through the PDFs, enter the data in by hand, and contextualise it, so that it could be properly indexed within the site.

One useful benefit of making the data machine-readable was that it could also be used in modelling. I worked with the subject matter experts to design interactive pages, where users could map data onto a graph, and then adjust details to see changes, and focus in on the parts of the data that they found relevant. They could then download the graph and relevant data for use in experiments, presentations and writing papers.

Using data to improve search

The machine readable data also provided us with an extra way to enhance the site, by opening the way to a richer search experience. Working with the developers, we were able to improve the way in which the search reviewed information, moving from the literal matching of words to understanding context around a piece of information (referred to as a “graph” search). This provided richer results, which I could then leverage further, by surfacing relevant data earlier – a search for water would not just provide a link to page on water, but might also provide information such as the boiling point for water, its chemical composition, and so on. This concept was inspired by the rich results that search engines such as Google and Wolfram Alpha provide, and helped to demonstrate further value to the user.

Homepage improvements

Our final step in improvements to the database was to provide signposting to users, both new and old, of ways in which the site had improved, as well as encouraging them to try some of the new ways of finding information and explore the new site architecture. We therefore redesigned the page to provide lists of content, recent updates, and showcases of specific items, so that any visitor to the site could quickly discover the resources and tools offered by the database, as well as appreciate the enhanced user experienced and increased value.

Testing and outcomes

Throughout our process, we engaged in user testing, to facilitate the “build, measure, learn” strategy, allowing us to continually test and iterate upon ideas throughout production. Towards the end of production, we took the product with us to various scientific conferences on the East coast of the United States, where we showcased key features and conducted guerrilla testing on a booth with passers-by. The people we talked to were highly impressed, and this was reflected when we began to roll it out – customer attrition was reduced, subscriptions began to rise, and licenses for the product were even purchased by the Indian government for libraries across the entire country. The product was an awarded a “best in class” tool from the American Chemistry Society, and in surveys of users, 69.2% classified the product as “great”, an increase of 22% from when I started.

Conclusion

Due to the 2-3 years I spent on this project, I was able to make a lot of significant improvements, and effect changes which benefitted from continuous work with stakeholders, developers and subject matter experts. This allowed a methodical approach to improving the site, which I would have not been able to achieve on a shorter engagement. Overall, I’m pleased to have changed the product into a firm foundation that others can build upon, and help to further improve.