What I’ve learned from designing complex systems for finance

Fin-tech is one of the biggest areas in the tech world at the minute. Go onto Dribbble and within minutes you’ll find tens if not hundreds of designs for financial dashboards, trading interfaces and fancy gifs showing a doughnut chart loading. All these designs make it appear that designing for big data interfaces is super easy and takes no more than some slick graphs and animations to create a functional interface. The reality is that when you get into it, big data design is hard, very hard. There have been books upon books written about how to correctly display data, heck there’s entire job fields dedicated to it.

Knowing what chart to use for what type of data is a whole separate subject which people much smarter than I have written books about. So this article won’t cover that, but I would definitely recommend reading up on it in your spare time. This article will cover the lessons learned from working on a number of complex financial products and some tips that may make your life easier if you are currently in the throes of your first data-heavy product.

"Making something so complicated seem so simple is one of the principal aims of design and doing this well takes time and attention to detail."

Get in with the numbers

One of the first things I learned about working on complex systems is that you have to be willing to ask questions, even ones that seem obvious. If you don’t get clarification on absolutely everything from the start it could end up creating an unstable base on which your designs are built upon. It’s good at the beginning of any project to get one or two stakeholders on board that will be willing to help you, answer your questions and provide you with feedback on your designs.

Another good friend to make is the back end developer or developers working on the project, they will be able to help you map out how the data is connected. If the product you’re working on is brand new it means you have a bit more flexibility, it’s a blank slate to start from in terms of structure and what you can do with the data. If you’ve been brought onto a project with an existing data structure then you need to spend time, with the stakeholders and the developers on the project to understand how the different pieces of data relate to one another, as the structure of the data can shape what you can and cannot do in terms of graphs and tables.

A good starting point is to map out the flow through the product and highlight the data at each step. I generally start out on paper and once I have a good idea of a flow I’ll move onto digitisation. Creating a visual guide has been shown to help with understanding complex structures. Flows and maps will be your best friend at this early stage. Map everything; map the user flows, map the data flow, map the internal processes, create spider diagrams showing how things are connected. Don’t be afraid to go over the same thing more than once with different people on the project. Getting different points of view might highlight an area for improvement, but also relying on one point of view for information may lead to unexpected blind spots in your flows. If the person you’re speaking to isn’t aware of a particular process within the company or is wrong in how something functions it may lead to inaccuracies in functionality or data.

Don’t be afraid to iterate

It’s good to set expectations early on in the project, it’s impossible to get everything 100% right from the get-go. I’ve always found that in pressured situations where you have to get something done without allowing time for feedback, you usually end up discovering down the road that the design doesn’t cover all the required use cases and can often lead to having to either re-do a design entirely, or trying to shoehorn something in. Emphasising the need for iteration being a part of the design process will give you breathing room to experiment with different ways of displaying the data and will give you space to get feedback from stakeholders and users. Their feedback will be invaluable here as they will be able to direct you in terms of what data they would find most useful.

Rather than asking users what data they want to see, a good place to start is to ask users what questions they want to be answered by this product. This will direct you to the type of data you need to answer their questions. You may already have this data to show but in some cases, it may require additional metadata collection to provide users with the right content. Finding this out early on in the project will help you provide value quickly. Doing this may also highlight the need for distinctive dashboards within the product to meet individual user needs. Yes, it does mean more work but if you are designing an application which is to be used by different types of people with different roles it makes it much less likely that you will create a dashboard that fits everyone’s needs. Providing your users with invaluable insight the moment they land on your site will provide enough reward for it to be worth it.

Start by creating personas for each user type. Don’t worry about names and background stories, all we need to know here is what questions they want to be answered. This leads us to the data required to answer those questions and how we can best provide that to them, which if you conducted the initial user research you should already know.

Additionally, if you’re working on an existing product, check to see if they have analytics or mouse tracking installed on the product. This can be a great initial data set to help you see which types of data users are most interested in and can help narrow down the data areas that should be brought forward and highlighted to users.

Remember your design basics

Some people, including myself, can get carried away when designing for data-heavy interfaces, the possibilities are endless but one of the best things you can do is go back to basics.

Error Recovery and Prevention
Helping users understand errors and providing easy solutions to recover from them is an important part of complex systems. This is something I overlooked when I first started working in this space, the sheer number of errors that can happen is on another level. It’s also easy for errors to be overlooked by developers as it may only happen once in every 100 times you try to do something. A good way to ensure you stay on top of this is to speak to the developers you are working with and ask them to let you know if they find an error so you can write copy for it and add any design considerations to it.

When writing error copy remember to use human language rather than technical terms it will make it less confusing when things go wrong and can reduce user frustration. For example, if a table has failed to fetch some data, make it clear to users that this is what has happened and explain what they can do to recover from it e.g. refreshing the page. This may mean you need to spend some time writing out error messaging for the many different types of errors in the system but will be beneficial to your users in the long run.

Another mistake often made is that everyone using the platform will understand all the data shown to them. Thinking all users are power users will alienate those that need guidance. Providing users with tooltips, FAQs and descriptive chart titles will help them understand what is being shown to them. Reducing the use of speciality language through the system will reduce the barriers to the adoption of the product.

"Reducing the use of speciality language through the system will reduce the barriers to the adoption of the product."

Consistency is Key
Consistency is one of the most important design fundamentals and will help users get to grips with the system faster than designs which are inconsistent. It also has a nice secondary benefit of taking some of the stress out of design; you don’t have to try to remember what padding you’ve put on form fields and it means you don’t have to keep recreating the same components over and over again. Your devs will also thank you for it when it comes to development. Being consistent is as easy as ensuring the buttons in your flows are always in the same place, or always showing table actions in the top left. However, it is important to note that consistency goes beyond your own platform. If your users are used to specific patterns within their field, try not to deviate from these. Jakobs Law states that “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.”

Hierarchy of Content
An often overlooked idea within the design is ensuring the hierarchy of content within your design calls the right things to the users’ attention in the right order. Having the wrong order may mean that your user overlooks useful or important data and can lead to frustration and confusion if they can’t quickly find the content they are looking for. Your users should know at first glance what data is the most important on the page, from here they should see a clear path to take action on that content (if that’s what your product provides). Hierarchy of content can be visualised through font weight and size, visual spacing and colour. Learning about content hierarchy will help you make the right layout decisions when organising your content structure.

Clean and Minimal Design
A clean, minimalist design may seem contrary when working with extensive amounts of on-screen data, but introducing breathing room in your designs will help users absorb data without overloading them. This is especially important with complex systems where the cognitive load is already more than with less complicated products. Sometimes it can be as simple as adding more white space around cards on a dashboard or allowing tables to side scroll, rather than trying to fit 10 columns in a set width. But sometimes it can be choosing to remove data from a screen and only showing it in a drill-down. There are many ways to progressively display content to users and trying to find a good balance can take some back and forth. Consider expandable table rows and drawers for drill-downs where possible.

"Introducing breathing room in your designs will help users absorb data without overloading them"

A point to note here is that in some instances, users may be used to cluttered, data heavy interfaces. I’ve worked on projects with users who are so used to using Bloomberg every day that when confronted with a clean interface didn’t like it at all. But at the same time, I had other users who hated Bloomberg and saw the clean design as refreshing. Trying to find a balance was hard, but getting user input helped us find the right amount of data to display and ultimately it came down to the ability to use familiar shortcuts within our platform.

Accessibility and Colour
Use of colour is a great way to provide additional context for your users. A good example of this is if you have data live-updating within a dashboard, using colour can be a good way to highlight this to a user. You can have a border highlight to show when content has updated. However, it is important to remember not everyone sees colours the same way. When using colour in data-heavy interfaces it’s a good idea to use a tool like Stark to help you see how your designs may come across to people who are colour blind.

The painful bit

This next part is going to make you hate me… After working on my most recent project for a while and having countless meetings with devs about data, I realised that the only way to get everyone on the same page was to create a library of all potential graphs, tables and charts with what data is required for the component and how it should be sorted (I’m sorry). For example, if you have a line chart showing spending over a year with a budget indicator, you should add a note to the design saying; ‘line graph showing the sum of spending over the previous year with the x-axis showing the past year in monthly segments and the y-axis showing the cost in £, and a threshold line indicating the current budget’. This will allow the devs working on a project to get a grasp on what data is required for your designs and how the queries for those cards should be structured. It will also ensure you 100% understand the data and what is possible to do with it. It also means that if you are designing reports or dashboards you will have a pre-set library of graphs and tables to choose from.

Congratulations, you can now see the matrix.

Designing data-heavy applications can be tedious and make you feel like pulling your hair out at times, but breaking it down into digestible chunks will help you become a better designer. Making something so complicated seem so simple is one of the principal aims of design and doing this well takes time and attention to detail.