Graphs — a bumpy design ride

Don’t tell anyone—but I love graphs. Such a weird thing to hold dear, I know. When I wrote my Bachelor Thesis, I spent more time designing the graphs than writing the text (my professor calmly nods from his chamber). I wanted to make them perfect. My thesis was built on a quantitative research, where I had gathered a lot of data and made an attempt to illuminate it with graphs. I thought they looked really cool. Such nice curves. Amazing distance between the horizontal dividers. And those X and Y legends? Perfectly balanced.

A month ago, I started a new project at my current work, Tink. It was a dream come true; I would spend the coming weeks building a huge analytics tool. Graphs everywhere. So much data to digest. So I reminisced about my old Bachelor Thesis graphs and decided to walk down memory lane and look at the Thesis for the first time in 7 years. I was hoping for inspiration. But when I opened the document, I closed the computer in milliseconds after viewing the graphs. What. A. Disaster. After staring at a blank wall for 1 minute (or 1 hour — time and space kind of disappeared for a while), I opened my computer again and tried to iron out what it all ment. But couldn’t. There was just too much information on too few pixels. I don’t have a scanned version of it, but here’s a graph I made in minutes to illustrate how terrible it was.

Not my Thesis graph (fortunately) but it was almost as silly

I returned to reality and tried to wash of the newly discovered low self-esteem from watching my old graphs. Twelve self-motivational YouTube clips later, I opened up Sketch and started out my new graphs project for work. I needed to do better.

Weeks passed and I made probably hundred graphs. I’ve iterated on them and have received feedback and implemented updates. I believe I’m a couple of steps closer to creating at least a decent graph now. In 6 chapters, I will go through - step-by-step - my process and explain how I designed, how I iterated and why the end product looks and functions like it does now.

Part I

Starting off with the first draft

First draft of the graph was literally a copy, paste & scale of a graph we have made for the fintech app we’ve built at Tink.

📈 Pros

The good thing about this graph is that it’s clean. It doesn’t have any real clutter. It’s so few parameters that it actually works without legends / explanations of the Y-axis and X-axis.

📉 Cons

We’re building an advanced analytics tool. You don’t get the breakdown of what you’re looking for with this little amount of information. It’s difficult to apply advanced metrics with so few controls. It’s not very scalable for potential data that we would like to showcase down the road.

✅ Learnings

Make it simple. Make it easy to read — without having to study details to be able to understand what it tries to tell.

Keep that in mind whilealsoaddingmorefunctionalityanddata to the graph (because there will be a lot of data down the road).

Part II

Moving into adding functionality and data

Being born from the minimalistic graph above, I made a couple of changes that were needed to be able to visualize more data as well as more advanced data. Also, there needs to be a way to filter the data.

📝 Updates

Filter by time

Hover over an endpoint needs to show more information

Dates needs to be shown more prominent

There needs to be a line behind the hover circle to indicate where it is

The line in itself can’t be round. Rounded corners doesn’t reflect accurate data points when hovering to see more exact data.

Larger fonts everywhere because this isn’t mobile and we have space to play with here.

There needs to be lines indicating the x-axis.

📈 Pros

This graph is clearer; it shows more data points and are detailed enough to get the grip of how it’s going for your app. It’s also nice that you can hover and get more exact details if you’re looking for something specific. The lines are not rounded anymore which makes it more exact as well. The dates are clearly showing below, hanging alone so they’re easy to read.

📉 Cons

It gets a bit messy in the top right corner. The filter section of the time filter gets a bit crowded with the Y-axis values. I also believe that there’s too few lines behind that indicates somewhat where the 500 data point is. Even though our brand color is that kind of salmon, when I showed this to a developer they experienced it like it indicated error.

✅ Learnings

You can make an advanced graph by not showing too much, but by letting the user discover what they want by actions (like here, filter and hover).

I should move the Y-axis numbers to the left since it’s not going on as much on that side.

Evaluate the color

Part III

It’s the little things

A few style enhancements on each component helped making this clearer. In the iteration part of evolving a design, it doesn’t have to be redrawn from start as we all now: working with one component each - component by component - gives it a sweet holistic result.

Graph: Part III

📝 Updates

Changed color to our secondary brand color: dark green

Moved Y-axis numbers to the left

Added small lines underneath the bottom line to make the dates align better

Added a line between each “whole” line to make it easier to read the graph without hover, while still keeping it loose so it’s not overwhelmed with lines

Moved filtering into a sub section that is foldable to give the power of filtering to power users, while keeping the filtering hidden for most common case user.

📈 Pros

The accumulations from all the previous Pros could be inserted here, as well as the added benefit of moving the Y-axis numbers to the left. It’s now easier to read them, and the actions (filter) are standing out more than previously when it was crowded on the right hand side. The lines makes it easier to read and the graph still feels clean and clear. It’s nice that there’s no filtering that takes too much space on top right. With multiple filter options available, it would look messy.

📉 Cons

Folded filters aren’t optimal for power users. But by expanding the filters, it will be remembered to next graph and next session for anyone who wants to see the filters expanded.

✅ Learnings

Adding small details here and there will certainly make it easier to read.

But keeping the added details to a minimum is necessary to still keep it clean and clear.

When I showed this to a colleague, he asked if a bar chart isn’t the better option for this type of data…

So last learning was to rethink the whole thing. Which is never good, because I spent a lot of time with it. But also very good, since there was room for improvement.

Part IV

At the end, start from the beginning

So looking at the line graph, the value between one point and the next one only makes sense for certain data.

Like money, if you want to show your personal credit card expenses, a line graph makes sense because between point a and b,there’s an exact value of money.

But showing something binary that can’t really be other than an integer and as shown in the graph below, it’s between two data points, trying to show people in the right graph during the night doesn’t make sense. We know it’s a decline, but the line can’t explain how much exactly, since we don’t keep record of the decrease per second.

Graphs: Part IV

✅ Learnings

Try bar charts for the scenario where the change between data point a and b can’t be explained by a line.

Part V

A new day

With the feedback, I redrew the graph to be bars instead of a line. It shows really clear data for each X-axis value, and pushed me 3% closer to nirvana when looking at it.

Graph: Part V

📝 Updates

Bars instead of a line.

📈 Pros

Clearly showing the amount in x-axis. Easy to read each date as well; showing a bar for a date is clearer to see than when you have a line going between multiple dates. It makes it easier to scan.

📉 Cons

Too much white space between each graph, but could be solved by adjusting the bars as well as distance between far right and left of the container.

Part VI

Wrapping it up

I’d like to finish the article with a couple of extra insights I gained during this whole process.

1. Keep It Simple Stupid

1. Keep It Simple Stupid

On the left, the data is split up to two different graphs that you switch between instead. This is because it gets messy and crowded and unreadable as soon as you start adding more graphs (as seen on the right). Showing two lines might work, but not ideal, but when you start adding more than two lines — it’s a guessing game what the graphs are and are not.

Final note about having multiple lines in one graph: what happens if they have the exact same data? They’ll just be on top of each other, cancelling one of them out by hiding it beneath the other.

2. Highlight what’s important

2. Highlight what’s important

When you want to see the details of a certain bar or certain data — make it easy to read and understand. On the left, the user is hovering over a certain data point and the other bars fade out to make it easy to read. The others are not completely hidden because you still might want to compare that bar to the others. On the right, there’s no fading effect and it’s a struggle to read that bar because of it.

3. Tabular vs. Proportional

3. Tabular vs. Proportional

It’s no cardinal sin to use a proportional font, but if you’re about to build a product that lean heavily towards exposing a lot of data in tables and graphs, adding a secondary font that is suitable to display numbers in a tabular manner is a good idea. It lines up the numbers so that they have the same width and hence the columns align properly. A lovely article and a more deep-dive into this can be found here, in an article by Matthew Ström.

It’s a cardinal sin at my current workplace to use multiple fonts, hence we keep our proportional font in graphs. But my word of advice is: if you are in the process of selecting a new font for your company or start a new company and get the freedom to select a font of your choice, check if that font provide a tabular version —they seldom do, even at premium prices.

Part VII

That is actually the wrap! I believe I’ll work on designing graphs here and there during the rest of my life, so trying to keep a record of learnings along the way seems like one of those rare good ideas that I have. We’ll see.

A lot of the design improvements and feedback that made this better along the way is due to the developers (Jon, Gustav, Stephan, etc.) in my team at Tink as well as my design colleagues like Henrik Hedvall.

If you have any recommendations or insights, don’t hesitate to reach out to me. Thanks for reading!