Design

Design strategy for a trading company

Posted on by Andrew Robert Burgess
Abstract image of candle graph lines against a dark background

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.

Diagram showing how collecting information into a accessible wiki can help inform both project and company strategy
Diagram showing how collecting research intelligence and analysis can help inform both project level and company level strategy

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.

A single user journey, indicating how the user interacts with the software
A user journey for a single user type, showing their actions before, during and after they use the software, and including possible issues indicated in red and opportunities indicated in green

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.

Diagram showing combined user journeys between different types of user, helping to understand the wider ecosystem
Combined user journeys, understanding the wider ecosystem of how different user types interact with each other, as well as 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.
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
An idea to combine previously separate services into a single information service that users can customise to focus on the one or more markets that they are interested in, which a variety of touchpoints for them to access information.

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]

A tree diagram showing the original architecture of the website for the trading company
Turning complex website structures…
A tree diagram showing a much simpler layout with fewer pages and less complexity, making navigation easier
…into fewer pages and less complexity, improving navigation

  • 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!

UX advocacy within various companies

Posted on by Andrew Robert Burgess

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.

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.

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

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!

Trading system for financial company

Posted on by Andrew Robert Burgess

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.

Introduction

Just before lockdown was announced in March 2020 in the United Kingdom, I had started work with a software consultancy whose clients included some of the more well known financial institutions in the City of London. One such company wanted us to help them update their fixed-income bonds trading software, as it ran on the soon-to-be retired Adobe Flash platform, meaning that their software, through which millions of pounds flowed through every day, would stop working. Alongside this mainly engineering led objective, I was included in the team with the somewhat abstract goal of “improve the design while we fix the platform”.

One of the major challenges that I also faced was the complexity of the system. Fixed income bonds trading can take up to six months to learn to just get started, and I was working with a client who felt that I should be producing designs as soon as possible, as they had only previously worked with User Interface designers, and did not appreciate the value of a proper UX process.

Demonstrating value, while conducting discovery

I therefore needed to be able to demonstrate value quickly, and the easiest way to do this is to ensure that the client is kept regularly appraised of progress, and sees a constant series of artefacts to demonstrate the progression in thinking. I started by persuading the client to grant me access to stakeholders and users, so that I could begin to get a better appreciation of the project context. I started with the stakeholders, who consisted of project members and subject matter experts on the client side. I was able to set up a number of calls with them, for them to explain their perspectives and opinions on the project. This provided a firm foundation from which I could then begin to assemble my own picture of the situation, which I coalesced into a user journey, expressed on a whiteboard. On this whiteboard, I was able to define the definite known parts, assumptions and questions I still had yet to answer.

Whiteboard with post-it notes and written text, describing simple discoveries in the user journey
Mapping out the overall stages and observations around the trading software user journey

This whiteboard became my first “information radiator” – an asset where I could share my thoughts with others on the team, and get their inputs and insights. Usually, a whiteboard like this would be placed somewhere prominent in the workspace, ensuring that people saw it regularly, and inviting people to leave comments and ideas. However, as we were all stuck at home, I had to ensure that it was freely available to everyone on the project in a digital form that could be easily updated, so I carved out my won section of the project Confluence wiki for my UX work, where I began to write up my thoughts, post pictures, and encourage people to check up regularly, leave comments and feedback.

A typical confluence page showing how information can be shared in wiki format for everyone working on a project
Sharing information in a project using confluence (note: this is a generic screenshot from Atlassian, and not a page from our project confluence)

Conducting dynamic interviews

Using my explorations on the whiteboard, I could then collect the “unknowns”; the questions, assumptions and ideas I had written down, and use them to make a interview guide, which was also shared with my colleagues for feedback. I could then begin to arrange some sessions with actual users, with a list of ready questions to ensure that we filled in as many gaps in my understanding as possible.

For user interviews, I would usually try and meet with the user face to face, discuss their working practices, and examine the ways in which the product would fit with their requirements. However, as this was during the pandemic, and we were all stuck at home, I had to arrange calls with them instead. This situation was useful in some ways, as their isolation meant that they weren’t as distracted as if they were on a busy trading floor. However, they were still working, and our conversations were often interrupted by a steady stream of notification sounds coming from their trading software, with them often having to pause answering my questions to deal with a new trading ticket that had come in, and required their urgent attention, which could often interrupt the flow of the conversation.

Image of obfuscated text, showing grouping of questions on a page
Mock-up of my questions sheet, showing how I grouped the questions to anticipate regular interruptions during interview

In order to deal with this, I had to work around these distractions by arranging my questions into small groups. This would help me to ensure that I could get answers I required, hopefully before the next distraction came. It didn’t always work, but it did help me to arrange my questioning to something of a more successful outcome.

Demonstrating value through discovery

Previous to conducting the interviews, the client had voiced skepticism around the value of interviewing clients, in the light of their decades of technical expertise, and my lack of previous knowledge of the subject matter. However, upon finishing each interview, I would collect up my notes and define clear observations from my discussion. I would the compare and contrast those with what others had said, and was able to produce a series of discoveries, which I was them able to share with the client, to demonstrate the value of my efforts by providing ideas for improving the product. These included:

A sliding scale of requirements

One key discovery was understanding the relationship between the different types of trader, which provided a scale between the amount of tickets that they dealt with each day, against the amount of supporting analytics information that they needed to deal with those tickets. The current solution had been a “one size fits all” approach, which was then tweaked as users complained that it lacked the functionality they required for their specific working style. This led to a product that was full of “experience rot”, and ran slower and slower, as more features were demanded and added. This increasing slowness of the system led to traders actually missing important trades, and a loss of potential revenue. By understanding the basic needs (as shown on the Kano model) of different types of user before the system was rebuilt, we were able to factor in the requirements along the sliding scale, without impairing the smoothness and speed of the final product.

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 against “traffic” (number of tickets dealt with per day).

A noisy user interface

Speaking to the users, I also discovered that the current user interface was very noisy – lots of bright colours and sounds vying for the user’s attention. This was again the product of the previously executed “bolted on” process, where functionality had been added upon demand, with no consideration for the relationship between different features on screen, leading to a screen full of notifications and a visual and auditory cacophony. What’s more, tickets would “pop up” on the screen, often obscuring other vital information, or other tickets. In busy periods, the combinations of tickets rapidly popping up, as well as all the colours and noises that came with them, led to a very frustrating experience.

Implementation

Having presented these and other observations to the client, I could then proceed with designing solutions to address them:

Number inputs

Interaction design showing a series of number fields and instructions on how users can easily change the values within them incrementally
Interaction design around providing a way for users to quickly select and change values within the number field, helping with speed and precision of trades

For traders who needed to deal with large numbers of tickets in a short time, being able to accurately adjust values on the ticket was key. I therefore explored ways in which traders could adjust numbers incrementally for small adjustments, as well as type new numbers in for larger changes.

Ticket prioritisation

Designed an interface which allowed users to triage tickets automatically, setting up rules that would divert tickets under certain criteria away from the main interface, so that they could focus on those that they found more important. The diverted tickets would be relocated to “drawers”, allowing the user to still check in on those tickets, when they needed to.

A modular interface

Diagram showing spaces on a screen to indicate areas for users to customise their screen
A customisable screen layout, ensuring that users can tailor the screen to their needs, and be able to see all the information they need at once.

In combination with the previous two ideas, I provided a customisable, modular interface, allowing users to tailor their screen with the information that they needed, and leave out anything that they didn’t. This also prevented the need for pop-up tickets, as they could be shown on the screen using the triage system, thereby ensuring that they didn’t cover any other important information.

Atomic design system

To complement the modular layout, and to help the development team, I created an atomic design system that regulated how each component looked, worked and fitted together. The atomic design system was developed using symbols in Sketch meaning that any changes would disseminate throughout the whole system, and, most importantly easily provided an overview to ensure that colours and layout did not override the overall information architecture of the screen.

Conclusion

The client was pleased with the outcome of my work, and the new system has now been implemented. Due to the nature of the engagement, I was moved on to another project, and I would have liked the opportunity to stay on and be able to test my work more with users, so that I could have a more defined metric of success. I also hope that my work has demonstrated the value of UX research to the client, and, in future, they consider taking a more user-centric approach, instead of assuming that they can successfully dictate product success with their own experience. As a result of my experience, I wrote an in-depth analysis of how and why you should conduct better user research in your projects, using my experience on this and other projects to help inform others of the discoveries I have made.

Flagship scientific database product

Posted on by Andrew Robert Burgess

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.

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

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.

Diagram comparing the reduced number of steps between the old and new user journeys, as well as an appreciation of what the user does before and after coming to the database
Comparing the old and new user journeys to find a single piece of information on the database, as well as dining an appreciation of what the user does before and after coming to the product.

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.

Mock-up of the interactive page design, showing a search bar, graph and table
Mock-up of the interactive page, showing how the user could search for information, have it plotted on the graph, and build a table of data beneath it for export

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.

Sketch of a search results snippet showing the point at which water boils, visual chemical composition, and links to a chart showing more data
Sketch proposition of how the improved search results could surface valuable information, including basic information over boiling point, chemical composition, and links to the graph functionality to discover more.
Sketch of a progression from simple data to graph to data table
Sketch proposition of the improved user journey, from simple data to graph manipulation and selection, resulting in a data table of data that is relevant 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.

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

Posted on by Andrew Robert Burgess

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

Posted on by Andrew Robert Burgess

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

Posted on by Andrew Robert Burgess

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

Posted on by Andrew Robert Burgess

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

Posted on by Andrew Robert Burgess

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.