This is a repost of the Design Matters series I run as part of my newsletter, originally sent to my subscribers on 10 August 2023.
If you'd like what you read, consider subscribing so you can get all upcoming issues fresh when they're first out!
Hi Friends!
Welcome to issue #5 of the series Design Matters.
In this series, I’ll share with you how design can help your dashboards go from average to awesome.
You might be a seasoned Business Intelligence developer, an enthusiastic manager, or an analyst dipping your toes into the field for the first time. Regardless of where you find yourself in your data journey, the goal of this series is to shed light on how design plays an indispensable role in data analytics - not just in making things look pretty but in affecting understanding, communication, and decision-making.
Last issue of Design Matters, I talked all about wireframes and how they can help you elevate your dashboard development process. I discussed technical debt and introduced the concept of design debt. And I also brought to you one of my favourite concepts about data visualisation - the abstraction ladder.
This week will be part 2 of the wireframing theme. Now that you know the why of wireframes, it is time to show you the how. I’ll make several call-outs to concepts covered last week, so if you’ve missed it, here’s the link to issue #4
How to wireframe
Let’s assume we’re working with a Sales team that has asked us to build them a dashboard. If you do it like me, you’ve interviewed each member of the team - either separately or in a workshop, making sure that everyone had their chance to talk. You’ve mapped who your audience is, what they are about, and what they struggle with in the process. You’ve also mapped how they use data in their day-to-day - where do they look at their numbers? With what frequency? Do they rely on KPIs to track performance? If so, are the definitions documented somewhere?
Many questions later, you have a good understanding of how a data display could help them. After spending some time tidying up your conversation’s notes, you landed on the following requirements:
The team has a monthly catch-up where they look at how they’re performing over time with their Sales, Costs and Profit, so they can understand if they’re on track or not against their Sales target.
Targets are only available at an overall level and only for Sales.
When the team is looking at their Sales numbers, they want to understand which Regions have sold the most, so they can understand if they need to concentrate efforts on one or more Regions.
When the team looks at their Sales numbers by region, they would like to be able also to understand if there’s a correlation between those Sales and the associated Costs for each Country, so they know where they can get the best Profit and can concentrate their efforts accordingly.
When the team occasionally needs to understand the performance of a particular Product, they’d like to be able to have the same view for each Product, Category and Segment.
It seems straightforward enough, right? So now, we wireframe!
Step 1 - Map your pieces of information
You can do this with Post-its, in a notebook, or in a Word file. Whatever works for you.
Take note of each piece of information you can identify from the Job Stories above.
For example, I’ve extracted all points below, which will form the basis of what I’ll build later:
Total Sales. KPI. The sum of the total amount sold for all regions;
Total Cost. KPI. Cost of all goods sold for all regions
Total Profit. KPI. Calculated as Sales minus Costs for all regions;
All of the above, over time, just for reference.
Compare with the period from their last meeting (month on month);
Sales targets - overall only for the year; no breakdown.
Breakdown of Sales numbers by each of the 5 regions they sell to;
Overview of the correlation between Sales and Profits for each country where they have sales;
Filters: region, country, product, category, segment;
The view is always the current month, compared to the previous month.
Ideally, you’ll want to keep going until you’re satisfied that you’ve covered everything they’ve mentioned during the previous steps. The idea here is to turn all those initial conversations into a more solid version of requirements you can work with to start envisioning your dashboard.
We can already see some things taking shape! We have 3 metrics - Sales, Cost and Profit. They primarily want breakdowns by region and country. There is a secondary requirement for other views, which will be used less frequently - product, category, segment.
Pro tips:
If your build is very complex, this step is best done either on a virtual whiteboard (Miro or FigJam, for example) or with lots of post-its - provided you can leave them somewhere accessible.
After you’ve laid down all requirements, group them according to metric, theme and audience. You may realise you have requirements that may not belong together and could potentially become more than one data display or development.
You may start noticing requirements that aren’t possible to satisfy with the current state of your data, architecture or environment. These are still very important insights, as you can then clearly articulate to your clients/stakeholders which points you may not be able to address at this time. At least you’ve already captured them for later! 🙂
Step 2 - Think of your information hierarchy and flow
If we put all of the above requirements in Post-it notes (I’m using a FigJam board), we can start thinking about the hierarchy of all this information.
We have 3 KPIs. They are mentioned as the most important pieces of information in this display - the Total Sales, Total Cost and Total Profit.
We also have important comparisons with the previous month’s results.
They have a target, but just for Sales and only overall. That seems pretty important, as it’s mentioned as the one reason they need to know everything else.
After you’ve mapped the hierarchy, you may end with a more organised view of what you’ll be building. I’ve organised mine by colour, according to each KPIs theme, and then from top to bottom based on hierarchy.
Pro-tips:
If you have a project with lots to map and understand, you can do the prioritisation step alongside your clients/stakeholders. They’re the ones who know best which information matters most to them.
This can take the form of a workshop in which everyone is given dots or stickers, and they need to ‘vote’ on the pieces of information you’ve organised.
Ask them to highlight the piece of information they can’t live without, the one that’s important but secondary to the vital one, and the ones that are nice-to-haves. And if you do run a workshop with them, be prepared to take heaps more notes! Engaging with your stakeholders at these early stages and asking them to help you understand what matters to them is usually a very insightful experience!
Step 3 - Start Lo-fi
Time to have fun!
Now that we have somewhat of an outline of what information we should be displaying and how important this information is to our audience, we can start thinking about the good stuff - laying information out together!
Layout can seem like a daunting part of the process, but it doesn’t have to be. You already know the hierarchy of your information. You can now start playing around with where the information will be placed on a screen.
The tools you use for this step may vary according to what you have and what you’re more comfortable with. It can be on a piece of paper, with the Post-its you were already using before, or with digital tools like Figma.
Whatever you choose to use, here’s how I go about this step.
Crazy 8s
This is a UX Design technique where you time 5 minutes to draw out 8 layout options for the information you have.
First, define the screen format you’ll use - is it a horizontal monitor? A mobile layout? Draw 8 rectangles roughly in the proportions you’ll be building on.
Now, think about what the essential UI elements of this screen will be. These are all the non-dataviz stuff we add to dashboards. You may even have a template to start with! Will you add a header? Title? Subtitle? Logo? A sidebar? A footer? Buttons? Why? Where will they be pointing to? These are your scaffolding elements.
Don’t get caught up with making things perfect. You are just trying to figure out which elements you want to add to your dashboard and where things will be placed on the screen.
Now, add your data elements - the things you mapped and prioritised before. KPIs? Will they go on top? On the Side? Which KPI comes first? Which is second? Why? Where will you place the breakdown by region? What about the correlation chart?
Note that we haven’t even gotten into the process of thinking about how we’ll depict each piece of information (which kind of chart we will use). That’s by design (pun intended). We’re only concerned with the flow of information for now.
You may have more than one screen to map for each display if you already know there will be drill downs or different views. Map those, too, and make sure to map the interaction points where people should click/hover to go to the next screen/display.
You may find this a bit awkward in the beginning and not be able to come up with 8 options quickly. That’s ok! The more you do it, the better you’ll get.
If you’re able to make more than 8, go for it!
Once your 5 minutes are done, assess what you’ve come up with.
I’ve previously said that while it is hard to know why a design works, we’re all pretty good at knowing when something doesn’t work. Use this instinct to your favour, and strike out the 4 options that don’t quite seem to work.
You’ll be left with 4 options to ponder over.
When assessing them, try to think about what makes one option better than the other. Pay attention to things like:
Where do your eyes naturally land when looking at your layout?
If you were in a rush and had less than a minute to look at this before a meeting, where would you look first? Why?
Are there any points of interaction? (places you expect users to click on, interact with, filter, hover).
Make notes on the wireframes to help you process your analysis.
Once you’re done analysing your 4 layouts, strike out the bottom 2.
You’ll end up with 2 layouts that made the cut. Yay!
You might want to involve your clients/stakeholders again and ask them what they think. If that’s not possible, you could still benefit from another set of eyes to help you choose - your team members, for example.
You may receive unexpected feedback from others, and that’s exactly what you’re looking for. Listen intently and adjust if necessary.
Pick your winner!
Pro-Tips:
There are two main ways how most people read information on a screen - on an F pattern or on a Z pattern. One way to assess your layouts is to draw an F or a Z on top of them, from corner to corner - this way, you’ll see what would fall into the pause points of each pattern. These points are the spots that people stop longer to look at. You want your more important information along these areas. (see the Z and F in the images above).
The most classic format for dashboards is to split your view into 2 or 3 levels horizontally or vertically (never both, pick one direction only). If you’re doing it vertically, the most important information will be placed at the top, the middle section will have the secondary details supporting the context of the elements above, and the 3rd section will be reserved for your nice-to-haves. The same goes for horizontal, but you have that from left to right instead.
Consider reducing the space you spend with unnecessary features - titles don’t need to be huge. Everyone who clicks a link to go to your dashboard knows where they are. Logos are another elements you can think of placing on less prominent positions of the screen (maybe the bottom corner?). Your display should be for information, and branding elements often occupy precious space.
Step 4 - Tidy up and add mock data visualisations
Finally, it's time for some dataviz!
Now that you know where the information and the basic elements will be, you can start filling in the gaps.
If you’re more used to this process, you may already have ideas of how the information will be displayed (Big KPI numbers, sparklines, a bar chart for the region breakdown, etc). This step will be a natural follow-up then.
This is also the step where you work on your chosen layout a bit more. This is where you’ll start getting used to looking at things like the distance between elements, if there’s too much information packed into one place, or if you could further split the views.
Here you’ll also start looking at the finer elements of your dataviz and your UI. Remember to make space for things like instructions, annotations, contact info, data source updates, and footnotes about your data.
After you’re done, and you’ve picked some dataviz options to display your information, go back to your clients/stakeholders and ask for feedback.
You may be wondering when will we start adding colour and data to this thing?! There’s a saying that first, you need to get things right in black and white. This means that if your layout is already looking promising at this stage, you’re one step closer to making smarter colour choices later. It also means that this exercise forces you to visualise data without relying so heavily on colour. Dataviz is about encoding data using visual elements. Colour is just one of those elements. If you’re able to visualise your data with no reliance on colour at all, this will make you appreciate colour much more when you use it. Once you get used to a black-and-white wireframe approach, colour becomes your secret superpower to encode only the most special information.
You may also be wondering what it will look like once you finally create this into your BI tool of choice. The idea here is not yet to be accurate in the depiction of your data. Wireframing works to make all of those tiny compounding design decisions less overwhelming. You now have a skeleton to work from, a vision, and a general idea of placement and hierarchy. This is a blueprint, and it will help you make more informed design decisions when you’re building your first prototype with data.
You’ll also have a shared vision with your clients/stakeholders. Their input during this process will help you further refine expectations and gain greater clarity of what problems you’re solving with your build.
Pro-tips:
In this step, try to make your mockup a bit more polished, so you can take feedback notes on top and document it for later. If you’re doing them with physical post-its or with pen and paper, take pictures!
You can use this first wireframe as a reference every time someone comes up with a new requirement or at the end to show how far your humble sketches took you.
This is what mine looks like after tidying it all up nicely:
Step 5 - Iterate!
Congratulations! You’ve built your first wireframe!
From here, you can use this as the reference of what you should be building in your BI tool of choice.
And if you ‘got it right in black and white’, you’ll be ready to start working on your pre-attentive attributes a bit more and add some splashes of colour.
But that’s a conversation for next week. ;)
How about you? Do you use wireframes as part of your development process?
Until next time,
--T.
This is a repost of the Design Matters series I run as part of my newsletter, originally sent to my subscribers on 10 August 2023.
If you'd like what you read, consider subscribing so you can get all upcoming issues fresh when they're first out!
If you like what I share and would like to support my caffeinated habits, you can buy me a coffee!
Comentários