Building a user-led design strategy for an energy commodities trading company

Building a proactive design strategy, demonstrating value through user intelligence

Introduction

This case study includes
My role
  • Head of UX
Team
  • 2 UI Designers
  • Business Analyst
  • Development, Research Analysis, Marketing and Data Teams
Stakeholders
  • CEO
  • Head of Technology
  • Head of Marketing
  • In-house traders
Users
  • In-house traders
  • Traders, Researchers and other experts from major energy companies
  • Investors
Timeline
  • April 2022 – January 2023 (10 months)
Overview

The company have an established and successful energy commodities trading arm, and were looking to leverage their expertise in the industry to build out their technology offering based around their in-house trading software, and use it to widen their market share and appeal to major energy companies.

Highlights

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

A photo close-up of a computer screen showing trading information arranged to assist traders predict behaviours
Example of a trading interface
Two side-by-side photos of a phone receiving notifications about trading events, and viewing the trading interface to see behaviours of a trading product
Traders receive notifications about developments in the behaviour of a trading product, and are able to view developments on their phones screen, keeping hem updated while away from their desk

Context and goal

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, and scale the technology side of the company from its current start-up state.

Building the foundation

Devising an approach

  • To approach the challenge outlined above, I recognised that we had an opportunity to develop a design strategy that understood the value of what the different parts of the company offered, and leveraged and understanding of user needs to develop a competitive advantage for the product and the company.
  • This approach was agreed by the CEO and CTO, with the caveat that it should not remove design support from the existing products and teams, and it became clear that I needed to build out the design team to ensure support was provided while I focussed on the new company and product design strategy.

Creating a design team

  • As the current products were fairly mature, they mostly required support in the creation of UI elements, and so I felt it best to hire two UI Designers, who could start by supporting the existing teams, and then be brought into the new product work later on.
  • I hired the two UI designers using Lou Adler’s Performance based hiring process, focussing upon expectations rather than a laundry list of required skills, which would help appeal to a more diverse set on candidates, and help balance out the office.
  • I oversaw the process myself, liaising with recruiters, conducting interviews and organising interviews between the candidates and other members of the company.
  • We used phone interviews reviewing CV information to screen possible interests, inviting them in for a face-to-face interview and task for the next stage, and finishing with a meeting with the CTO.
  • Through this process, we successfully hired our two designers, who I then oversaw working for the product teams, checking in daily on product work, and directing designs to ensure that they followed branding and overall strategy.

Creating a user-based design strategy

  • Before work could start on defining the new product, I needed to raise awareness and demonstrate the value of what I was doing, and get buy in from senior members of the company.
  • I started by devising a research repository, which would act as a single source that everyone in the company could access in order to see my progress. I took the company Confluence wiki, which had previously been separated into two sections (as product teams for the trading and brokerage arms had been separated into two), and ensured that there was a part of the wiki that everyone in the company could access.
Flow diagram showing how research is taken and shared through he company
Flow chart showing how I took research from both internal and external users, documenting them on a central Confluence wiki which everyone could access, and then shared it with product teams and executives to inform both product and company strategy

Research

  • I then started by conducting research with internal traders and brokers, as well as members of the research and sales team to gain a bigger picture and gain a wider understanding of the market before moving on to external users.
  • During my research, I would write up transcripts of my interviews, summarising them into key observations, which would then be posted onto the wiki. This way, I could then quickly share those observations as insights with stakeholders in order to generate interest in my work through weekly update emails, and encouraging discussion of those observations during meetings.
  • My observations covered not just insights for future products, but also providing intelligence that could inform strategic decisions, supporting the work of management, market intelligence, sales, marketing and more.
  • Once I had conducted research with different types of users, I could the use the insights from different individuals within each user type to create personas to sum up those findings, as well as user journeys to explain the work processes which they followed. These were points of focus to understand the differing needs of each types of user, as well as opportunities for people to think of further questions, and identify areas which could be improved, as part of a continual exercise of understanding and development of ideas.
Persona of a typical researcher, detailing their specific needs for the project
Persona detailing the needs of research analysts, how they currently use the platform, and what they want from it, to identify opportunities for improvement.
A single user journey, indicating how the user interacts with the software
Combining the separate user journeys into one (blue notes), and then identifying opportunities (green notes) or further questions (red notes)

Discoveries

Insights gained from research with users included:

  • Product 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.
  • Staying informed: traders, brokers and other users expressed a need to be able to keep up with trends and changes, not just in the office, but also while on the move, being told of changes in prices as well as the events in markets and geopolitics that caused those changes.

Solutions

Following the discoveries above, I worked with senior stakeholders to develop a product strategy which would continue to provide value in the short term, whilst also working on the longer term goal of developing their main trading platform.

Showing data value early

We felt that product awareness was one of the above discoveries that we could address with less effort and maximum impact, as well as use to demonstrate value. One way to generate interest quickly was to leverage the proprietary market data which the company produced, which when demonstrated to users could then underpin the value of the trading platform we were producing.

In order to demonstrate this data, we needed a way for users, including those less technically minded, to be able to access it easily. As many users already used large Excel sheets to pull in data for trading analysis, then we could demonstrate it to them, and they could even pull it into their own trading sheets later on using a subscription-based API.

We worked with our development teams to create an Excel plugin where users could select data streams in markets relevant to their interests, as well as formatted in the way they preferred. This approach also began to address the user requirement for customisation, allowing the user to select the data they were interested in, and only have to pay for that, in contrast to previous approaches where users were provided with information in all markets for a flat subscription fee, which they would then filter down in the app.

This was provided as a free trial for a couple of weeks, with further access available for a price. We also designed and created a promotional page where users could be directed to for information via promotional videos and testimonies, and online signup reducing the need for any manual onboarding.

Part of a web page promoting the API service with the still of a video showing an Excel screen
Part of the promotional page we built for the API, giving quotes from previous users and a run through of how easy it was to import and work with the data in Excel. We offered a trial period, and then users to customise and pay for the data streams that they were interested in.

Thanks to the efforts of our Sales team, the Excel plugin and API helped demonstrate to a wide user base the value of our data, and generated interest in our work on improving our trading platform.

Combining and customising information

Following our success with the Excel plugin and API, we then wanted to adapt the awareness and customisation concepts to our plans for the trading platform. We identified that these could be combined with two other discoveries, namely varied sources and staying informed, where we could bring in other services the company provided to demonstrate value.

Through conversations with users, we identified that while the data was useful, understanding the geopolitical, social and other reasons behind short and long-term trends is vital to being able to predict market behaviour. Therefore, we could use the high-quality market research produced by our in-house team to augment the value of the data, which would align behaviours with world events, to provide a holistic view of the customised information that the user subscribed to.

This also meant we could offer an adaptive pricing model, providing further value to the user by ensuring that they only paid for the information and data that they were interested in, in place of the previous model where users paid a flat fee for the entire service.

Diagram showing a concept around combining previously separate services into a combined information service that users can customise to the markets they are interested in
The principle behind combining the data from different sources, and then providing it as different streams that were tailored to the user’s needs and interests, from different markets to different ways of consuming and using the information.

A “dawn to dusk” service

  • As well as choosing the energy products that were relevant to them and the information streams they wanted to receive, we studied their working patterns to understand just how they wanted to consume the information, and how we could best provide it to them.
  • It was this way that we devised the “dawn to dusk” service, which provided a series of channels and ways of obtaining information throughout the day that Traders could choose to fit their own requirements. These included:
    • A responsive view to the trading desktop, allowing users to access information on smaller devises, with information prioritised for “quick check” (mobile) or “lean back” (tablet) approaches (even adapting to smaller desktop windows), taking their preferred channels and information streams with them on the go.
    • Notifications via inbuilt application, or on WhatsApp channels, alerting them to changes, or providing communication with other Traders or Brokers.

Predictive models

  • Using the data from our controlling share of the market, our teams also devised a way to turn them into predictive modelling, using machine logic to predict likely movements within a market.
  • This prediction model showed the probability of various paths, which informed users of the safety of their trading bids.
A photo close-up of a computer screen showing trading information arranged to assist traders predict behaviours
Detail of the prediction model, making use of colour to indicate the likelihood of the next movements of a price

Aftermath

Following some reviews of the company, the decision was made to downgrade the software production team, and my ideas were shelved in preference for a more pared-down approach. Despite this, I am very proud of the progress I made, and grateful for the opportunity to demonstrate my ability to adapt to an industry I previously had little understanding of, as well as identify value quickly to stakeholders to help champion our efforts.

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, some of which have actually been adopted since I left the company.
  • 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.

Building a remote design team, and advocating for better UX practices

Creating a design team in India, improving skills and permeating UX throughout a company

Introduction

This case study includes
My role
  • UX Lead
Team
  • Leadership
  • Multifunctional product teams
  • My own design team
Stakeholders
  • Heads of Design
  • C-suite executives
Timeline
  • Various roles since 2016
Overview

Since reaching the role of UX Lead in 2016, I have both worked on creating and maturing design teams when I have been given the opportunity to do so. In other situations, I have advocated for user-centred design principles and better ways of working, both within multifunctional product teams and across wider companies. Here I share the work I’ve done, and the methods I’ve used to achieve success in my endeavours.

Building and growing a design discipline in India

I spent several years working in an international product team within a scientific publishing company, with Business and Product Management roles in Germany, and the Product Development team in India. I was then offered the chance to start a UX design team in the Pune office, as it became clear that it would be more efficient for designers to be situated in the same office as the product teams they worked with.

The brief

  • To create a team of six designers who would be assigned to different product teams, understanding the specific requirements of those teams, and ensuring the designers allocated were suited to those requirements
  • Providing support to my team members, helping them with their everyday work and interactions with their team and the company, and helping them to learn and mature as designers
  • To work with my designers, their teams and others within the Pune office to raise awareness of user-centred design and improve working practices.
  • To represent my team and advocate for their needs within the wider international design discipline, covering 36 designers in 4 countries.

Part one: recruitment

  • The first stage was finding the designers to be in my team
  • As I was based in London, I had to initially plan and hold the recruitment remotely, then flying across to Pune to hold in-person interviews.
  • The process had various stages, mirroring the same processes that our design discipline used to recruit designers in other countries, and so not only did I have to plan interviews for myself and the candidates, but also with team members they would be working with (to ensure that they would be able to work together), as well as final interviews with the Global Head of Design.
  • We found the market to be very competitive, with a limited number of candidates who had a good understanding of UX being able to pick and choose roles offered to them. As I also had limited time in which I could interview them in person, I devised a process that would after an initial screener call to assess ability, would get them into the office for a day where we could conduct interviews and practical tasks, before making them an offer by the end of the day. This method helped us to make attractive offers to candidates before another company got to them first.
A diagram showing the devised process for recruiting User Experience Designers in Pune
Sketch showing the recruitment process we used in Pune, from CV reviews and online screener calls to holding interviews and practicals in one day, so that we could quickly assess and hire candidates.
  • As tech roles have a strong male dominance, we wanted to ensure when advertising the role that we could appeal to as diverse a pool of candidates as possible.
  • We therefore used Lou Adler’s Performance Based Hiring, a principle that advertised the role based upon what they would be doing, rather than a laundry list of skills and past achievements. This was due to the fact that candidates who weren’t male often looked at lists like these and assumed that they would not be suitable for it if they could not prove every requirements, while male candidates felt they could apply for a role if they suited some or most of the requirements.
A written job listing, showing what will be expected of an employee in the first 3 months, 6 months and beyond.
An example of a job listing based upon Performance Based Hiring. Instead of listing required skills and abilities, the job posting defines that the prospective employee will be doing, which allows people to adapt their own experiences, rather than being daunted by not having specific experiences.
  • The HR team in our Pune office were very helpful in arranging the advertising and screening candidates, but did have some trouble adopting this new approach. I worked closely with them to help them understand these new practices, and work out the best way to review applicants.
  • Thankfully, the approach worked, and we ended up hiring a very balanced and capable team.

Part two: support

  • Working back in London, I would have weekly 1-2-1 sessions with each of my team members, as a chance to review the work they were doing, and discuss any questions that they were encountering. This also supplemented the fact that they could reach me at any time via Teams or email, so that questions could be answered as quickly as possible.
  • I also had weekly meetings with Product Owners and Team heads to gain feedback on my team, discuss any problems, and plan initiatives to improve ways of working.
  • I visited the Pune office 4-5 times a year, where I would be able to support my team in person, as well as see them working in their own teams. We would also held retrospective sessions to collect feedback from the team about their working experiences, discuss approaches and devise solutions.
  • These were all then reported back to the Global Head of UX, along with my fellow UX Leads, so that we could devise a combined approach to our various teams.
Sticky notes on a board, outlining the outcomes of a session discussing the problems we face
A view of an “anchors and engines” session (deliberately obscured, for privacy reasons), where participants can raise issues that are driving them on, or holding them back. Below are sails (extra things we might do to improve our process) and sharks (things we should look out for). These can then be grouped and discussed to devise a plan of action.

Part three: development

  • As the UX leadership, we defined that the two areas of focus should be:
    • Improving the design skills and maturity of our teams of designers
    • Improving design knowledge and practices across product teams and the wider company
  • Using models generated from Jared Spool’s work, we created two tools to help us with these efforts:

1. Improving design skills

  • In order to measure and improve skills across our teams in four different countries, we needed to establish a baseline on which they were all measured.
  • As UX covers a wealth of different skills and disciplines, some prominent while others are less visible, we wanted to ensure that we could assess each member of our teams on those skills.
  • We devised a Skills Map, detailing every skill and discipline that UX design covers, breaking them down into smaller aspects, and mapped the skills out into five areas; Research, Analysis and Strategy, Design, Delivery and Core Skills. This gave us levels of granularity to properly identify excellence and knowledge gaps.
  • We then created a scale on which to measure ability in each skill, from zero (meaning that they knew absolutely nothing about this subject) through to three (meaning that they were enough of an authority on the subject that they would be willing to stand up tomorrow and give a talk about it).
Feels in a table in excel, showing the overall skill of Analytics, and facets of that skill, such as Basic Concepts, Setting up and Statistics.
Example of a Skill and different facets within to be assessed on. We would discuss each facet with our reports, and assess how much they felt they knew about each section, marking each section from 0 (don’t know anything about it at all) to 3 (could give a talk about it tomorrow).
  • Using these scales, we were then able to sit with each of our reports and go through the Skills Map, asking them to honestly declare how comfortable they felt with each subject. Rather than just taking their word for it, we would challenge them if we felt they had under or over estimated on a certain scale.
  • By doing this, we were able to draw together the final scores to understand where our reports knew a lot about a given area where we could use their knowledge to help educate others, or opportunities for improvement where we could help them understand more.
Screenshot showing the spreadsheet and analytics we used to measure skills levels across the UX team
Using these skills maps, we could then put together a picture of people’s abilities in different sections, and identify areas for study and tuition.

2. Improving design knowledge

  • As well as assessing our designers, we wanted to run a similar process with our product teams, in order to identify opportunities for improving design knowledge and maturity, and recommend better ways of working.
  • Using a UX playbook devised by Jared Spool, which defined areas of design maturity within teams and organisations, and worked on a similar 4-point scale to our Skills Maps above, we were able to conduct similar reviews with our design reports and other members of their product teams, to give their own opinions around how involved and infused UX Design was within their own working practices.
  • As above, this helped us to define a UX strategy roadmap of work to help improve that design maturity within production teams and the wider company, which we could then work with our designer reports to enact.
  • With this approach, we were able to get Product Owners and Business Analysts, Developers and Project Managers focussing their work around user needs. This led to better understand of not just what they were building, but the reason why they were building it, and gave them more agency and satisfaction in their work, which led them taking active interest in how the product performed after launch.

Championing better design practices

As part of the work I did in India, as well as in other roles, I’ve created and delivered programmes of work to help teams and companies realise the benefits of user-focussed production and improve their ways of working.

Introductory presentations

Often within companies who don’t have much design maturity, people who aren’t designers either won’t have heard of user-centred design, or will assume it’s solely the remit of the design department. In these cases, it’s often useful to start with a presentation which helps set out your position, as well as set a level between those people who have never heard of these concepts with those who might know a little.

Screenshot of a presentation slide, with "UX is not", and a list of different misconceptions around UX
A typical slide from a “What is UX” presentation, breaking some misconceptions around what some perceive UX to be.

These talks are not just standalone events, but openings to conversations and discoveries around current practices; are they confused between the terms UX and UI, do they involve users, or is the product direction solely defined by product owners, expecting the designers to just push pixels? By understanding the current situation, as with the example in India above, it helps us to create a program of work to address these understandings and improve the ways in which teams work and products are delivered. What’s more, as these things are hard to deliver alone, it helps you to identify people who might well be useful allies and advocates, to help support and spread your message.

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.

Single sheet explaining the processes behind Lean UX Design
An example “One Page Process Sheet”, explaining principles behind Iterative Processing and Lean UX Design

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.

Step by step guide, showing people how to draw and share their ideas in the ideation session
The guide I provided to the remote ideation session, showing how people could draw and share their ideas with the group

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.

Thumbnail of blog post page
The blog post I wrote on Cats Eyes, and showing the value of iterative design and testing

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

  • I’ve successfully created a user-focussed production culture within several companies, both in manager and non-manager roles, helping them to work together better and deliver more successful products, which have in turn led to increased profits and happier teams.
  • People in teams I have managed have gone on to excel in their careers, with the help of my mentoring. Some have risen to more senior roles afterwards, including Heads and Directors of Design.
  • If you’re interested in what I could do for your company, why not get in touch?

Demonstrating UX value in improving complex trading software remotely

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

Introduction

This case study includes
My role
  • User Experience and User Interface Design Consultant
Team
  • Engagement Lead
  • Client Product Owner
  • Engagement Development Team
  • Client Development Team
  • Client Business Analysts and Subject Matter Experts
Stakeholders
  • Client Product Owner
  • Subject Matter Experts
  • Client traders
Users
  • Client traders
Timeline
  • July – September 2020 (2 months)
Overview

Working as part of a consultancy team to a major bank, we turned an originally intended “lift and shift” in updating their trading software into an opportunity to fix some fundamental problems and improve the user experience.

Highlights

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

Conceptual layout ideas on a computer screen

UI design sheet showing organisms, made of atom and molecule components, such as tickets
Full screen version showing a customised layout with large tickets, stacked tickets and supporting analytics Stages of production

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.
Whiteboard with post-it notes and written text, describing simple discoveries in the user journey
My initial explorations describing the stages of the RFQ process (blue), identifying problems and questions (red), as well as questions and opportunities (green)

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.
A screenshot of part of my interview script, showing gaps between every 3-4 questions
A screenshot of my interview script, showing gaps every 3-4 questions, in order to anticipate interruptions while Traders were working.

 

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.
Graph showing the relationships between different types of users along a sliding scale of numbers of tickets versus complexity of tickets
Graph showing the sliding scale of different user types, based upon complexity of tickets (amount of information shown on them) against “traffic” (number of tickets dealt with per day).
  • 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:

A wireframe, detailing how users can define what appears on each part of the screen, as well as save and share their layouts
A customisable screen layout that allows users to prioritise information to their own needs, while ensuring that key data is not obscured.

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.
Wireframe showing how multiple tickets can be stacked and displayed with more or less information
Showing how users could not only change the size of tickets and the supporting information inside them, but also triage tickets to suit their own Trading style.

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.
A series of designs, with a flowchart exploring concepts at the top, black and white wireframes of tickets, and a finished colour version of the ticket at the bottom, showing how the menu overlay works.
Concepts, black and white wireframes and colour UI exploring the concept of the overlay menu to increase or decrease prices incrementally.
A series of user interface designs showing a central numbers and a series of buttons around it, allowing the user to incrementally change the value.
UI exploration around how the “daisy wheel” overlay could allow users to quickly changes bid prices without taking their hand off the mouse.

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.
UI design components sheet showing the styling of buttons
Atoms – showing the styling of smallest components
A UI design sheet showing how atom components fit together to make medium size components
Molecule components – showing how atoms fit together to make slightly larger components
UI design sheet showing organisms, made of atom and molecule components, such as tickets
Organism components, showing how the atoms and molecules fit together into larger components, such as tickets
Full screen version showing a customised layout with large tickets, stacked tickets and supporting analytics
Pulling the whole thing together into a screen that highlights important information, triages tickets and provides background analytics

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?

Improving an online flagship scientific database to “best in class”

Enhancing a flagship online scientific database to best-in-class

Introduction

This case study includes
My role
  • Senior UX Designer (London)
Team
  • Technical and Business Product Owners (Heidelberg, Germany)
  • Junior UX Designer (Pune, India)
  • Business Analysts, Project Manager, 6 Developers (Pune, India)
Stakeholders
  • Subject Matter Experts
  • Academic and Corporate materials scientists
Users
  • Academic scientists and researchers
  • Corporate scientists and researchers
  • A range of companies and institutions
Timeline
  • October 2014 – October 2016 (2 years)
Overview

The product is an online subcription-funded materials science database, provided by a scientific publishing company, which had suffered a decline in subscriptions before I joined the team. We wanted to understand why people were using the database less, and how we could encourage them back.

Highlights

“Transforming a simple scientific information repository into a dynamic data-driven tool”

Page of sketches exploring different details on the page, such as tables and graphs, and how they would work on desktop, tablet and mobile screens

A digital sketch of six screens with annotations

A sketch and a screenshot of a page with a graph and tables of results for a characteristic of a material

Context

The product is an online materials science database provided by a scientific publishing company. Created with data from a series of journals which have been compiled since 1882, it is viewed as a highly-respected source, providing details of experiments throughout its long history, including Albert Einstein, which scientists today could use to inform their own experiments and papers.

However the online database, which had been running for seven years before I came on to the project, had seen a decline in subscriber numbers. The product owners wanted us to understand the reasons for this decline, and explore ways in which we could get those subscribers back, as well as encourage new ones.

The Challenge

“Review the database and understand from its users why they were using it less and less, and develop ways to improve subscriber numbers again.”

Research

Recruiting users

  • The product’s user base covered a wide range of different institutions and companies which depended upon materials science data for their work.
  • However, I found that the Product Owners did not have direct connections to the end users of the products, as the business relationship was conducted through Sales Teams and Buyers, and the Product Owners had only been interested in analytics metrics.
Diagram showing the relationships between different groups, underlining the lack of contact between the software production team and users
Diagram showing the relationship between my team and the users, and how it was difficult to get any users to conduct research with
  • Therefore, I had to go out and recruit users myself, by researching companies and institutions, writing to Heads of Departments, approaching individuals and using on-page surveys to collect initial impressions and request participation.
  • While this was time-consuming, I was able to create a group of users who I could conduct research with to champion design decisions, and test with to assure assumptions.

Research methods

  • As I am not a Materials Scientist, I needed to ensure that I was asking the right questions in my research sessions. Thankfully, the company had a few subject matter experts on hand, who were able to give me an initial walkthrough of the platform, and how it would be used by scientists to find data for their work.
  • In order to observe user experiences, I focussed on examining end-to-end interaction processes with research subjects (see below), asking them to show me how they would find information of interest to them, so that I could assess how successful they were, as well as identify pain points and opportunities for improvement.
  • Users would often have their own suggestions from their own previous experience of the platform, which also provided useful starting points for further ways we could improve it.
  • During this process, I encouraged other members of my production team to listen in to the call, posting questions on Slack for me to ask the users, which helped to encourage collaboration and ownership of the research process, and foster empathy with the users.
A photo of two laptops, one next to each other. The left hand laptop is showing a video call with a website as the main view. The right hand laptop shows a text conversation in Slack. There is a a piece of paper with questions in front of the laptops and a can of Diet Coke to the right of the laptops. This is my set up for when I interviewed people online.
A remote user research call, with the call viewing the product on the main laptop screen. I have my written questions in front of me, and on the right is a Slack channel with my colleagues listening in. My team can ask me to ask questions to users on their behalf, to help their own understanding.

Examining the primary user flow

  • What motivations bring them to the platform
    • Reasons for using the site, experiments and tests being run, information needed to locate, location and device accessed on, and how they accessed it.
  • How they looked for information on the platform
    • How they looked for information on the platform
  • How they worked with information discovered
    • Reading info on the page, accessibility issues, page location, ease of retrieval
  • What they did with the information afterwards
    • Using information (data, text, etc.), taking it away (download, print, formats, etc.)
A handwritten sketch of a flow of box and arrows, showing the four stages I studied: before the user comes to the site, how the user looks for information, how they view the information on the site, and what they do with it after they leave.
A sketch flow of the four stages I defined in the primary user flow for study; what users do before they come to the site, how they find information, how they work with what they’ve found on the site, and what they do with it after they leave. These four stages become a model which I have used on many different products to build understanding of user motivations and requirements.

Discoveries

Major discoveries from the research

  1. Primarily, the database was a reference for users to look up data from previous experiments, that would help with their own experiments and papers.
    • The main process that a user would follow would be to search for a material (such as carbon, steel or benzene), and a property (such as melting point, boiling point, or surface tension)
    • They would then follow the search results to find their chosen piece of data.
    • Having located the required data, they would then take that information by writing it down, or printing it out, and put it into their own experiments and papers, to support their own hypotheses.
  2. However, there were some significant issues which they found with the current state of the database, which impaired their work:
    • They often found the process of trying to locate information difficult, with confusing numbers of pages and steps along the way, often causing them to give up in frustration
    • Searches would often return results which were confusing, and didn’t seem relevant
    • Once they had located the data, they found the process of then searching through the scanned image PDFs cumbersome, as they had no way to search for a result within the PDF, and could only find their results by hand
  3. After defining these frustrations, the users told us that they were enough of an impairment that they felt the product wasn’t worth the subscriptions fee, and that had caused them to cancel their subscriptions.

Personas

To summarise research findings, and to advocate key points to inform product decisions, I created personas that included Researchers and Scientists in both the Corporate and Academic settings, each with different practices, such as theoretical or practical work, or motives such as financial benefit or academic discovery. As they were a fundamental part of our customer relationship, I felt it was important to include a persona of the Buyers as well, so that we could understand the motives of those who purchased the software without a strong scientific background.

Five persona sheets, showing the different types of personas that used the database
The five personas I created to help understand the differing requirements of different types of user; Academic and Corporate Scientists, Academic and Corporate Researchers, and Buyers who weren’t direct uses, but were responsible for purchasing subscriptions for the other four users.

Analysis: co-location

Our product team gathered at our Pune office for a week together to analyse the findings:

  • Product Owners and Business Analysts shared business aims and requirements for the product
  • I shared my research findings and presented the personas, conducting empathy sessions to help the team understand and explore user requirements
  • Explore problems by eploring current user journeys, and thinking about how we could improve them
  • Ideate on solutions by sketching screens and interactions, identifying knowns and unknowns for further research ad testing, and providing a starting point for prototyping
  • Create an Agile roadmap for the coming months, estimating workload and timelines

By involving stakeholders and team members, we helped to reinforce the business and user motives behind decisions, as well as encouraging them to make use of their own skills, rather than just have work handed to them without context.

Solutions

Improving user journeys

Following our analysis session, we identified that reviewing and improving the journeys that users took through the site would be the most effective thing we could fix, with the least effort.

  • We started by identifying “red routes”, key journeys that users took through the site to find information, and identified that the most common was where they looked up a characteristic (say “boiling point”) of a material (say “Benzene”)
  • We had previously identified in research that the user journey had “bloated”, due to “experience rot” (continual addition of extra pages and features outside the original remit that confuse the original objectives and impair user success).
  • We therefore created improved user journeys as clickable prototypes, so that we could quickly test ideas with users, ensure that they aligned with their mental models and gain feedback before we revised the actual database.
  • During this testing, we also discussed opportunities from extra functionality, including digitising the data, which I could then advocate to the business as opportunities for future product development
A digital sketch of six screens with annotations
User journey illustrating the five pages and one PDF, with their interaction points, that the user had to navigate to reach a required piece of information.
A much simpler sketch of a user journey than the one above containing only three screens.
I managed to boil this user journey down to a mere three pages, including the home page, search and details page (see digitised data below).

A responsive approach

During our research, we identified not only the different requirements for each persona, but also discussed with them the different scenarios in which they would access the database. For example:

  • People accessing the site on a mobile device would often want to check a single, specific piece of data, and appreciated the ability to access the information quickly, without having functionality that they did not require at the time get in the way.
    • This also worked for people who would view the database on a smaller window on a desktop, ensuring that their view focussed upon the information that was key to their search
  • People who accessed the site while sat down, with a larger device such as a laptop or desktop, would want to spend more time investigating, and would want more supporting information

By returning to our “red routes”, we could then examine them with an extra dimension, ensuring that the layout and display for different device sizes responded to those requirements

Page of sketches exploring different details on the page, such as tables and graphs, and how they would work on desktop, tablet and mobile screens
Sketches showing how to adapt different parts of pages to different screen sizes. This allowed us to prioritise information around the different use cases for each form factor.

Improving search

The next effective solution that we chose to follow, which would take a bit more time and effort, was to improve the way in which the search worked.

  • We had already identified in the research that users were getting search results that did not make sense to them, and so our first step was to identify why those incorrect results were appearing, which we did by testing with users how they used the search, what results they expected, and which they did not.
  • We then reviewed with the developers, and discovered that it was the markLogic text-based search that was the problem, which only searched for text strings, and didn’t understand context.
  • This was a problem due to the technical nature of our users’ search terms. For example:
    • “tin” refers to the metal; tin
    • “TiN” refers to the material Titanium Nitrate
    • As the search did not understand the context, typing either of those terms into the search would yield the same results.
  • We therefore explored a number of solutions, including:
    • case-sensitive searching, allowing users to search using chemical symbols
    • contextual drop-downs which would allow users to select the context that they meant around their search term
    • bringing in search database experts to implement a graph search, which created a contextual model between inputs (such as recognising tin as a metal, which would therefore have a link to steel, which is also a metal, but not tincture, which is a chemical process, but has the letters “tin” in it)
  • We implemented our solution by working on a separate version of the search, only reachable by the use of a specific URL, which stood alongside the original search. By directing people to this search, we were able to try out ideas quickly, ensuring that our ideas worked before increasing user interface fidelity, which reduced the required amount of development before a solution could be tested.
  • As well as testing these ideas remotely with users over video call, we were able to take them to Chemistry Conferences in the USA, where we could conduct guerrilla testing with attendees at the company stall. This helped ensure a wider, less specialised understanding of how our search worked, as well as get a large number of results by which to measure our success.
Pages from a sketchbook showing sketched ideas around how a contextual search could work, providing prompts in drop-down, or building queries with logic operators like AND and NOT
Sketches showing explorations around ways that contextual search could work, including dropdown prompts to select context, and using logic operators like AND and NOT to build queries

“This is great. It really will save me a lot of time searching in the future.”

Corporate Researcher during testing at Materials Research Society Boston Conference 2016

Developing the homepage

As well as catering to the requirements of the scientists and researchers who used the platform, by examining the needs of the Buyer, we recognised that the homepage had three important roles:

  1. To provide a starting point for users to explore the content
  2. To update returning users with new developments
  3. To demonstrate value for non-technical users such as Buyers

We therefore redesigned the homepage to include the following features:

  • A summary of the different types of content for new users to explore,
  • A timeline of latest additions and improvements to update returning users
  • Details of the depth of information and sources to demonstrate value for Buyers

These changes were added over time, to accommodate the work around supporting these features, and other efforts on the database.

Before and after versions of the homepage, showing clearer layout, browsing prompts and latest developments
Before and after versions of the homepage, showing how we introduced clearer information and layout, browsing prompts and latest updates

Making data digital

One of the most fundamental solutions that we identified with the product, with the highest level of impact but also the greatest level of effort, was the fact that the data needed to be digitised. At the start of the project, data existed solely within the database as scanned-in pages from scientific books and journals, which frustrated users, and led to users feign that the product was not worth the subscription price.

it was this impact on subscription revenues that allowed me to petition Product Owners to organise a way of tackling this problem. Using the company’s relationship with client institutions, they were able to find a group of post-doctorate scientists to work through the scanned pages, performing specialist data entry to extract and annotate data for the graph search database, converting the scanned data into a fully digitised format. This work took about a year to complete, but this had a profound effect on the how we could make the product more valuable to users.

Surfacing results early

The digitised data meant that we could include it within search results, meaning that simple questions could be answered sooner, and demonstrating value more quickly. These could be displayed as search snippets, filled with simple answers, that led on to pages with more complex insights.

Sketch of a search snippet - a box showing details such as the boiling point of water as 100 degrees Celsius, the chemical compound of water, and a small graph with further information below it
Sketch suggestion detailing the ways in which information could be surfaced early by providing simple details that inform users and lead them on to more in-depth information on subsequent pages

Working with data

We recognised that the majority users searched with the same pattern, namely a material (such as iron, benzene or carbon) and a property (such as boiling or melting point, band gap, or similar). By understanding this, we could use our newly digitised data to improve our offering:

  • When a user first searches for a material and property, then we can surface the simplest answer in the search snippet, as described above.
  • If the user wants more in-depth information, then they can click through to a page providing a dynamic graph, which uses the findings from scientific papers to plot data in a visual away, demonstrating the behaviour of the material and the property against a scale – for example, demonstrating how the boiling point of steel changes when submitted to different atmospheric pressures.
  • Alongside this graph, the results are also provided in a tabular format, which allows users to work with the data displayed in the graph. They can change criteria, expand or limit the dataset, all to ensure that they get the information they require for their purposes.
  • As the last part of the model we discovered, this data can then be exported into a range of format, such as visual images of the graph, or spreadsheets of the results, facilitating use in the user’s work.

“This is awesome. I don’t think anyone else is doing this. Where do I sign up to get it?”

Student Researcher during testing at American Chemistry Conference, Philadelphia 2016

Page of sketches showing information shown on different screens such as search results, graphs and tables, as well as the search snippets shown above
Sketches exploring how details can be surfaced progressively, providing key information early, leading on to more customised detail later on. These concepts helped me to explore concepts and develop solutions with my team.
A sketch and a screenshot of a page with a graph and tables of results for a characteristic of a material
My sketch and a screenshot of the results page – showing details of the behaviour of a property of a material that the user has searched for. The table below shows the information in numerical form for export and links for citations.

Retrospective

  • Our work reversed the customer attrition that 
the product was experiencing, and brought a 32% subscription increase from academic, corporate 
and other clients
  • Within two years, that extra revenue paid for all of our salaries and the money that the company had paid into the project.
  • Developing the digital data pages won accolades 
for the product as a “best in class” tool from the 
American Chemistry Society conference in 2016
  • In 2017, the Indian Government bought licences to provide the product in all libraries across their country
  • A site survey, run at the end of my tenure as UX design lead, showed that 69.2% classified the product as “great”, a 22% improvement on when I started.

Designing notifications, or how we could learn to love our phones again

Perhaps the problem isn’t the phone, but the way in which it interacts with you?

Introduction

Another day, another article providing a soul-searching insight into why quitting smartphones is the new quitting smoking. These articles seem to occur regularly in the media these days, with accounts of people who feel trapped by their overuse of their phones, how they feel that their digital life is impinging on their real life, with their phones turning into monsters that continually buzz at them with notifications. These articles end up preaching solutions such as digital detoxes, phone stacking in restaurants, and have quotes from people saying how much better they feel when they don’t have their phones switched on, or even with them.

For me, the problem doesn’t lie with the way we interact with our phones, it’s about how our phones interact with us. When the web giants such as a Facebook, Google and Amazon began to realise just how much money could be made by advertising, they not only cashed in, but began to manipulate their properties so that they could multiply their efforts. The way that this was achieved was by factoring in design and functionality that encouraged compulsive behaviour. You may have heard of the “slot machine” effect of the Facebook newsfeed, encouraging you to pull down and refresh to refresh your newsfeed and get that dopamine hit of new content, or feedback on your contributions (in the interests of fairness, this isn’t actually exclusive to Facebook, many other apps have the same action, with similar effects). Many sites and apps use patterns to encourage further participation, and to keep the user on their product, and, whether intentionally malicious or not, some of these can evolve into dark patterns.

One such dark pattern that’s prevalent on almost every mobile device I know of are notifications. Even if, like me, you’re very stringent on keeping notifications on your phone to a minimum, whenever you download a new app the assumption is that the app can, unless you tell it otherwise, make noises, put messages on your lock screen and show banners whenever it wants to. In order to curtail this, you have to go into your settings and specify what notifications you receive. Apple and Google have made this easier to access in recent years, but it’s still an opt-out process, rather than an opt-in one, and for good reason – app makers want your attention on their products, and so want this way of bombarding you with information regularly, in the hope that you will give in, click on the link, and buy the product. Chances are, you’re probably not quite as hardcore with your notifications, so just imagine how fewer ones you would receive if you could choose to opt-in, rather than have to make the effort to opt-out?

Chances are, companies such as Facebook and Google aren’t going to go away, and they will certainly be around longer than the time you decide to go on your digital detox and later decide to rejoin the connected world, and, what’s more, you can be pretty sure that a lot of your friends are still going to be using them. However, there is a rising tide of interest in how these companies conduct themselves; we’ve seen questions into fake news, how they structure content on your timeline, and whether they should be responsible for the media that appears on their platforms. In my view, we should be asking these companies to not only look at the content they provide, but also the way they provide it. They should work out what their relationship with their users are, and how that they can provide advertising and updates in a more conscientious way. These companies aren’t the only problem, but if we could get them to change and show the benefits of doing so, others may follow suit. Through better notification design, we could learn to love our phones once again.

Designing for stressful situations

How putting yourself in the mindset of a stressed person might just save lives

Introduction

On Saturday 13th January 2018, residents of the US State of Hawaii received an alert on their phones. Instead of a text from their relatives, or the latest football scores, the alert gave the ominous message of “BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL”. In an environment of the realistic threat of nuclear war indicated by the US President’s tweets, alongside the continual goading and threats put out by North Korea on their state television networks, the announcement was met with derision, confusion, and overall, undue widespread panic. It turned out later, following a second message indicating that the first one was a “false alarm”, caused by an employee during a shift change at the Hawaii Emergency Management Agency, who intended to send out a “test” message, instead of a “live” one. This resulted in a public apology from the Governor of the state, and much embarrassment amongst those responsible.

Much has been said in the days that followed the incident about the way in which such a mistake could have been made. Aside from the general panic, it has the extra element of “cry wolf”, where, if the alert is sent out again, those receiving it will now view it with a level of skepticism, instead of immediately acting upon the advice – something which is crucial in the estimated 20 minutes that it would take for a nuclear missile to reach Hawaii from North Korea.

Aside from the social or political elements of this situation, it also raises some questions around the design of the system built to send out these alerts, and how to ensure that users can ensure that the intended drill of “test” or “live” messages are being run. Two luminaries of the design world, Don Norman, author of Design of Everyday Things, and Jared Spool, founder of UIE and the Center Centre have both written insightful pieces on their views of what went wrong, and how it can be prevented in future by the use of better design principles. Writing on Co.Design, Norman’s piece focusses on the fact that we like to blame people, rather than poor design and that the system should have been thoroughly tested before it went live. Spool’s piece on Medium focusses on the fact that the system incorporated poorly chosen file names, as well as poorly designed software.

Both pieces come to a similar, and vital conclusion. When we design and build a system, we should always consider the possibility of what it will be like for someone to use it under stressful conditions. We may not ever come to the point of designing alert mechanisms for incoming nuclear missiles, but we should still consider how easy our webpage, app or system might be to use if the user is pushed by a tight deadline, for example, or is being distracted in some way. Interestingly, my workplace at this very moment, is incurring stress upon my colleagues and I, as work is being done on the roof, and we are frequently subjected to loud bangs, or the sound of hammering and drilling. These interruptions frequently distract us from what we’re doing, causing us to lose focus on where we were with our work, and having to spend time reacquainting ourselves with the task at hand. In this situation, it is common for us to make mistakes as our brains make incorrect assumptions, and we then have to realise those mistakes, and correct them.

So, how do we design for these stressful situations? Thankfully, much of this is already incorporated into the skills we learn in User Experience Design. Giving structure to pages and forms, giving visual dominance to important elements, and clearly labelling and colouring key features can help the brain realise what needs to be done more quickly. We also need to consider what the implications would be if a user made a mistake. How easy would it be to choose the wrong thing? Can an error be easily rectified? Does the system indicate clearly the user’s selections, so that they can go back and fix it later? We can even test these things ourselves – take a prototype or a test version of the system, and go and sit in a busy or noisy environment and ask people to try it. Compare this with people in a quiet, calm place, and see if there is a difference in successful outcomes. The more we trial the system or software, the more sure we can be of its success. We can say that good design and testing can improve revenue or experience, but some day, in the case of the Hawaii Missile Alert, it might just save our lives.

A new design for The Guardian


This morning, The Guardian, the UK based newspaper, revealed a new design for their website and mobile apps, in conjunction with their release of their newspaper in a tabloid format, instead of the original broadsheet. Naturally, the design decisions of the team at the Guardian have been analysed, over and over, throughout the day by designers and readers alike, giving their opinions about whether they think the new look is good or bad.

Continue reading

Talking with machines


Improving the way that humans and computers communicate has always been a prerogative of the web designer, causing many attempts to get not only humans to understand how best to navigate and use an interface, but also how to best represent a system, so that user actions translate into something that machines can understand. Lately, the idea of a conversational interface, such as those found in Whatsapp and Facebook Messenger, has been an approach that has found popularity, especially with systems that involve transactional exchanges, such as buying tickets or booking hotels. The technology that has replaced what was originally a human representative is now, somewhat ironically, resorting to a method that emulates the human that it has replaced, but not without problems.

Continue reading

A discussion on survival in the modern world


I’m currently in a bit of a hiatus from Facebook, and, to some degree, from reading the news. The culmination of post-Brexit blues, the rise of Donald Trump, the constant barrage of news stories about people slaughtering each other with machine guns, knives and bombs around the world, the refugee crisis, the decline of the UK economy, the constant conjecture about how bleak the future is going to be, it’s all a bit much at the moment, and certainly giving me an increased feeling of Weltschmerz. Combine this with the way that I’ve seen behaviours change over the past month or so, in myself and others, where arguments have become more savage, emotions easily whipped up by unchecked facts, and accusations flung all too readily, and I feel like something is wrong, and I should step away in order to take stock. I love my friends, and I’ve always maintained that supporting others is great, but it’s rather like a human pyramid, and you’re the guy in the middle, at the bottom; if you can’t support yourself, how can you expect to support anyone else? 

So I’ve switched off. Posted an apology for my absence up on Facebook for my friends, and am spending time concentrating on fixing this problem – namely, identifying what happened, why things got out of hand, and perhaps what I can do about it. Whilst doing so, I’ve take the opportunity to catch up on some of my reading list – all those sites and articles I’ve had saved, and meant to look at later. Ironically, some of the pieces I’ve found have actually given me some thoughts into not how to fix all the massive world events taking place, but rather how to approach the media on which they are being projected. Whilst this doesn’t fix everything, it might give us some insight into some of the more subtle ways in which we are affected, and what we can do, or actually have the power to fix, to improve our relationship with the outside world through them.

(NB: I appreciate that the media I’m presenting on this post is a little long. If you don’t have the time to go through it now, I do suggest that you perhaps save it, and come back later, I can heartily recommend it all, and illustrates my points more clearly.)

First up, the always fascinating Freakonomics Podcast asks “Is the internet being ruined?”:

This starts off with some interesting points – firstly the reliability on various social media platforms as a conduit for information on current events, the reasons why some are better than others, and, in turn, the reasons why those platforms are engineered that way. A lot of it comes down to the problem a lot of content producers and providers on the Internet are experiencing now, namely how do we pay to produce and provide content?

Many people believe that the Internet allows them to consume content for free. Whilst this can be true, to some extent, there are still costs incurred in creating content, and putting it up on the Internet for people to consume. Whilst there are plenty of interesting ways being dreamed up to fix this problem, from Kickstarter to Patreon, to subscription based models and even an Internet tax on your broadband costs, nothing has been found to stop people from trying to access content without paying for it.

Therefore, unsurprisingly, some platforms have gone with an advertising/sponsorship model, using the revenue gained from that to pay for the content they create, and to keep their sites running. The problem here is that the advertising has grown to such a level, that the fixation over the revenue from the advertising has overtaken the original concept of content creation and submission, that now we, the users of that platform, have stopped being the consumers, and have started to become the product. The message on the platform becomes shaped in such a way that instead of getting the information you want, you get the message they think will keep you on there the longest, and your eyeballs on the advertisers messages the longest.

(This could start, for my UX based friends out there, a massive discussion about dark patterns, data driven thinking, and the unscrupulous methods of advertising, but I’ll leave that fun for another day.)

The conclusion I feel we can bring out of this part is that we should be wary of not only the message, but also the platform on which it is being conveyed. What biases do they have, what are they trying to achieve, and where does that put us, the user, in the whole relationship? (And, maybe, are there other opportunities to get the same, or similar information, in a better relationship?)

Following on from that concept about changing our relationship with platforms such as social networks, I was shown the above video last week at work, which talks, from a designer’s perspective, about how we get distracted by many different sources, how this impacts our health, our productivity and our time, and what we could do to fix this problem. After seeing this, a colleague I was with scoffed and declared “oh, I don’t get that problem, I’ve got perfect focus!”. Whilst that may or may not be true for that person, I think this is a very real problem for the rest of us. I often find that I get quite tense when I am trying to concentrate on something, and my concentration often gets interrupted by a wealth of different sources, from the messages popping up on my screen, to the animated conversation being held by a group of developers about three metres away in my open plan office.

We can, in some ways, take actions to remedy these problems, turn off notifications, manage our distractions, put on some headphones to drown out the noise, and so on, but I feel that some of these problems should be solved at a more fundamental level. Taking into account the previous piece, the motives for these distractions can be troublesome, as, all of a sudden, we find that we’re being distracted so that we can contribute to advertising revenue or shareholder value, which makes me very uncomfortable. Aside from that, I firmly believe that, as a designers, my colleagues and I have a responsibility to ensure that notifications and messages put to the users should be presented in their interest, and, of course, that in any given situation, the need of the user are put first.

The final piece which has come up recently is a fascinating interview with someone who I respect greatly, Mr Stephen Fry. In this interview, he presents a viewpoint, in a way which I think is provocative to the point of being vaguely insulting to his interviewer, suggesting that his country, the United States, has in some way, failed in its attempt to become the bastion of liberty and freedom which it set out to be. Through this failure, he suggests that culture has been affected in such a way that we resort to a form of infantile behaviour, regressing to a level where we engage in childish behaviour and don’t accept anything more complex than absolutes; black and white, good and bad, and so on. Whilst I don’t fully agree with his perspective (I believe that the superhero films to which he refers have far much more scope than merely the characters hitting each other, although I will concede that, from the outside, they can look that way to a casual observer), I do agree that we have lost an appreciation of the nuances of modern life, and need to consider our approach to complex problems, and challenge ourselves wherever possible – questioning the sources of information before trusting it implicitly, and understanding the implications of the information.

So, where does this all lead us? Well, I think that the three pieces above outline some very interesting points of regarding how we relate to the world, and the conduits through which we understand it. We should, naturally, be questioning everything, and understand not only what the information we’re receiving is, but also its provenance, and the provenance of the medium on which we’re receiving it. We also need to be able to control that medium, and ensure that it’s working in such a way that it is manageable to us, and in such a way that it it works to our advantage. I certainly will be using some of these lessons to improve my relationship with the information I receive, in an attempt to not let it all get “on top of me” again. I hope you might find them useful, too.