This is a repost of the Design Matters series I run as part of my newsletter, originally sent to my subscribers on 04 August 2023.
If you'd like what you read, consider subscribing so you can get all upcoming issues fresh when they're first out!
Welcome to issue #4 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.
In the last issue of Design Matters, I talked about how I map users and context using the concept of Journey Maps from UX Design. I adapted the original idea to the context of developing dataviz and dashboards and made it available to my subscribers here.
The middle of the loop: Reflect
Our previous issues were concerned with defining the guiding principles, the audience and the context of our dashboard. All of that falls under the first third of my Loop Process - Observe. They belong to the early stages of development, when you’re narrowing down what warrants further time and effort investment from you. We need to organise all this information before we start development.
But as I mentioned in issue #2, if we want our dashboards to be useful and impactful, we need to approach their development like an architect. We have mapped the area, the environment, and the context in which the dashboard will be used. Now, we need to draft a blueprint. This blueprint will serve multiple purposes: it will help us create a good layout for our information; it will serve as a common vision between developers and users to enable conversations about features and needs and it will keep us on track, preventing the dreaded scope creep.
If you've now mapped your users’ journeys and identified their pain points, you'll have reached a stage where you're starting to see a vague shape of what the final data product you're developing might become. You may see some obvious features that might be needed, and you might even start writing them into Job Stories (or User Stories, if that's how you do it). However you choose to sort them and turn them into a list of features, you now have reached the point where the dashboard’s vision starts taking shape.
This is an exciting moment, and many developers jump straight in from here. They miss the inflection point, the Reflect stage of The Loop.
The abstraction ladder we climb up and down
Turning data into neat visuals on a page for people to extract information is a complex process. And It comes down to how we encode and decode information. This article by Evelyn Münster explains this process really well, and I often go back to it. It's well worth a read.
When we record data, we get a bunch of fields, or columns and rows, and encode them into measures. We then further aggregate these measures into metrics based on assumptions. After that, we further encode them as data visualisations.
Suppose you're in a Sales team. Your team makes one sale. You'll have a database somewhere with one row split into multiple fields, recording all details of Sales Order 0001 - which product was sold, when, to whom, and for how much. You may have a second database where you record how much that particular product costs to produce or ship. Your sales manager will ask you what the Profit of this sale was. You'll then grab your product cost, your sales value and calculate your Profit. That's one step up the abstraction ladder. You got two measures directly related to your process (selling a product, with a price and a cost) and calculated a metric from them (your sales order's Profit). Every time you further modify this piece of information, you climb up another step in the abstraction ladder.
You now want to create an actionable KPI that can be tracked against a target across multiple channels, products and markets. You might want to calculate a Profit Ratio - a percentage representing how much of your sales revenue has become Profit (profit/sales revenue). And another step up the abstraction ladder you go. And you keep climbing it up as you introduce new ways of representing this information. Your Profit Ratio is now depicted as a Line Chart over time. You add a target line as a reference. Up the ladder, we go a bit more.
Tired yet?
Once all this intricate work is done and displayed in the form of a dashboard, the user's job is to go back down the ladder! They'll look at the line chart you created, read the title, and think, "humm, Profit Ratio…?". One step down the ladder they go. They'll then look for a definition, and in their minds, while looking at that percentage, try to imagine what it means. Another step down the ladder. And so they'll go until they can relate what they see in that line chart back to their reality and the decisions they can make. It demands a lot of effort from all sides.
How do you bring your users into the journey of encoding data into an interface? How do you get them excited about testing features early on? How do you ensure that your vision and their vision align and that you'll need less back and forth with reviews upon reviews and the ever-increasing risk of out-of-hand project scopes?
Wireframes - your dashboard's functional blueprint
Borrowing yet another User Experience (UX) Design technique, cue in wireframes! The Interaction Design Foundation defines wireframing as
"a process where designers draw overviews of interactive products to establish the structure and flow of possible design solutions. These outlines reflect user and business needs. Paper or software-rendered wireframes help teams and stakeholders ideate toward optimal, user-focused prototypes and products."
Wireframes are skeletons. It's like when you start writing an article and outline the themes and headings first, then fill it in with content. Or when you start a drawing by sketching out the basic shapes, filling in the details afterwards. And this can substantially improve your dashboard development.
Wireframes can help you in many ways, such as:
outlining flows, and interaction points;
discussing options with users
focusing more on the functional side of your dashboard development than on the form side;
it's how you get to test hierarchy and layout.
it helps you give your abstractions an early concrete shape that can be iterated more quickly based on feedback.
it is an incredibly helpful tool to help stakeholders and clients see what all your technical talk is about and confirm whether it will become what they actually need.
it gives a starting point to discuss potential caveats and gaps. It helps to communicate and align the project's vision with everyone involved.
And this is not an extensive list! I have always been intuitively adept at sketching ideas before implementing them, so the transition into using wireframes before development happened naturally to me. But I know there's some resistance to the idea in the Analytics community. I often hear two prominent arguments against wireframes in dashboard development, and both are somewhat related. That "*it is a waste of time*", or "*why draw in a different place if I can just put some rough charts together in my end BI tool while I explore the data?*"- which sort of also ties into trying to be time-efficient.
Let's understand why these two myths might hold you back in your quest for better dashboards.
Understanding the data is a crucial step in shaping metrics, coming up with insights and understanding what it can or cannot helps us with. But there is often confusion between two distinct stages in a dashboard development, and for the sake of time-saving, a lot of analysts assume they can be bundled as one step:
creating visuals for their own exploration and understanding of the data, and
creating visuals to help others understand and use the data's message.
We will often explore our data sets in the same BI tool where we will develop our final dashboard - which others will use. Why create something else if I'm already here creating this for my own understanding? Can't it all just be one thing, and I'll derive the visuals and layouts for my users from my own explorations?
Well, no. Remember all I said above about the abstraction ladder? When you are going on your own journey of discovering the dataset, you may find heaps of interesting paths to follow. You'll notice little nuances and details. But are all of these details interesting to further your user's objectives? Will they need to see the same level of detail? Are the visuals you created for yourself the same ones that'll address your user’s pain points? Likely not.
The end result of trying to bundle these two different stages into one is more time spent on refining, iterating and reframing the user needs at later stages of development - often when commitments have already been made and technical and design debts have been introduced.
This is usually the origin of many irrelevant dashboards - the ones that the developer poured their hearts into but that fell flat in adoption from the user's side.
If these two steps are instead treated separately, you'll be able to understand what your users are actually interested in, at a much earlier stage.
And the more time you spend figuring out what will make your deliverable relevant to them, the less time you'll spend addressing misunderstandings later on.
I have personally participated in developments with and without wireframe stages. The difference is not so much in how long the delivery takes but in the distribution of the project's time.
This distribution affects the relationship between developers and users and the user's overall trust in the process. If they're involved early on, the chances of them already being familiar with the dashboard's interface, interactivity points, design elements, and choices are much higher - and you'll have built trust and skill from the get-go. Adoption is a consequence of people getting what they need and feeling comfortable with changing their ways of working. Wireframe stages are enablers of this process.
Technical Debt & Design Debt
Another point for wireframes is preventing the increase of technical debt and design debt.
The idea of "debt" first came from software development. It represents the cost you'll have to pay back for not addressing small but compounding issues while you rush development with the quickest but not most optimal solutions. Later on, you’ll have an amounting debt that needs to be paid back - with interest. The time it takes to debug and fix a problem introduced early on is usually much higher than allocating time to do this optimally from the start. Design also can have debt. It goes with the concept of death by a thousand paper cuts: an interface that is not completely bad but has so many small issues that the user either gets irritated or gives up before accomplishing their task.
My favourite analogy of this concept is that technical and design debts are akin to playing Tetris.
In Tetris, you have a sequence of pieces constantly coming through, and every time you complete a row, it disappears. This gives you more space to deal with the new pieces, which come at ever-increasing speed. A technical or design debt happens when you miss a square. The row doesn't disappear because it wasn't fully completed. And as you play and miss more and more squares in new rows, they pile up. And now you have a constant flow of new pieces and less and less space. Sometimes you might be able to rush through and complete the missing square in an old row, but that takes a lot more effort than if it had been done the first time around. Wireframing is like having a view of the next 2 or 3 pieces in Tetris - it allows you to make decisions that will help you complete more rows, more efficiently, as the pieces come.
Design debt is also a crucial concept to be aware of if you're trying to build trust with your users. If your users can't find their way on an interface, if the dashboard is difficult to use, cluttered, or has broken elements, they'll wonder what else may be messy and not functional? Maybe it's the data! The concern is a natural evolution of a bad interface experience - design matters more than we think.
How difficult is it, though?
Wireframing can start as a simple sketch with pen and paper or a whiteboard.
For the longest time, my way of wireframing consisted of writing a description of each element on post-it notes and re-arranging them until I landed on a good user flow and layout. I would then take pictures of the options and discuss them with users. Low cost, low effort and extremely effective! After a while, they'd even want to join me in the little post-it brainstorming sessions I had. It can be a great opportunity to bounce off ideas with your users and get them to expand on their requirements.
You don’t need to be good at drawing, either. Low-effort wireframing exists, in the form of Priority Guides. These are text-heavy wireframes (in a way, my post-it method was a cross between regular wireframes and Priority Guides). You won't be reproducing charts or images here. You lay out squares with text-only descriptions of your potential content and go from there. This is a great technique to help improve your layout skills, as you can clearly see the function each visual will perform, and the effects of placement become more obvious.
Wireframes also don't have to be High Fidelity (hi-fi), perfect reproductions of your final ideal deliverable. In fact, it is advisable to use Low Fidelity (lo-fi) representations at early stages.
The thinking behind this is that with a lo-fi wireframe, you're helping yourself and the users to focus on function before form. It helps to steer the conversation and feedback into interaction points, layout, hierarchy and flow between screens and options. If you've ever presented a hi-fi prototype of your work and got vague feedback like "But I don't like this shade of blue" or "Make it pop more!" you'll know what I mean here. It is easy for users to get overwhelmed or dazzled by a dashboard. It is also frustrating for developers who would like more input into the usability side of things.
Lo-fi wireframes also help developers not get too attached to their own creations. When you spend a long time curating the details of a piece, you'll perceive it as having more value - after all, you spent so much time creating it! It is easier to take blunt and negative feedback when you don't have an emotional attachment and don't feel the need to defend the hours you spent creating something.
Lo-fi for the win.
You can go as simple or as fancy as your heart desires or your environment requires. Wireframing is not supposed to be a chore but a useful tool for discovery and vision-setting.
As my practice evolved, I refined my wireframing process more and more. From post-its to nice quality dot-grid notebooks to having stencils to help me create neat shapes (yes, I have stencils). These days I have my own Data Viz Design System in Figma, which I painstakingly developed across the almost four years I've been creating dashboards as Data Rocks.
If you want to look more into how you could start wireframing in your dashboard process, here's a neat list of (mostly free) tools to create wireframes.
Next week, I'll go deeper into how I create wireframes, with examples and techniques you can leverage and use in your own process.
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 04 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!
ความคิดเห็น