The beautiful and all-knowing dashboard can be a daunting thing to design. It’s an application’s intuitive and friendly concierge who’s always there to welcome you, fill you in on what’s been going on, and send you on your way.
There are several different types of dashboards: key performance indicator (KPI) dashboards, analytic dashboards, business intelligence (BI) dashboards, and productized application dashboards.
“Designed correctly, a dashboard increases productivity for all users.”
This post will focus on productized application dashboards, which pull elements from each of the others to give a wide range of users an all encompassing view of the application it serves. You can create an incredible tool, but a tool is only useful if the user knows how to use it.
A great dashboard turns a good tool into a great product by making it accessible to the mass public. Designed correctly, a dashboard doesn’t only decrease the learning curve of new users—it increases productivity for avid users.
Here’s me in front of a real, actual dashboard. What a time to be alive.
1. Don’t start before you begin
As with every project in the UX design world: do research before anything. The user is always most important, and you must have an intimate knowledge of your user to design for them.
The 2 key things you need to know about the userbase: demographic and use case. Learn the general age, gender, and interests of the users—you don’t want to use sports terminology on a dashboard for 13-year-old Dungeons and Dragons fans.
Also, learn what key function the application serves for the user (utilitarian or entertainment) and their frequency of use. These 2 things will play a large role in how formal or “cute” we make the dashboard.
“You must have an intimate knowledge of your user to design for them.”
We don’t design in a bubble, so find out what other applications in the market offer. To be clear, I’m not suggesting you steal anything—I’m encouraging you to understand where a logical jumping off point should be. Once you have a clear direction, it’s time to dive deep into the application.
2. Fire up the still
Distilling a large pot of fermented mash will steam out the desired liquids, and after you run them through a refinement mechanism, you’ll be rewarded with a fine bourbon. Much like this process, you must reduce your application down to only its most important functions to include in the dashboard for a superior product.
I’ve developed a method for pulling these key functions from the creators and users of an application. I call it application distilling. This process is perfect for designers because it beautifully combines both the requirements and wireframing processes.
If you only take one thing away from this article, let it be application distilling.
Step 1: Take a large whiteboard and write 3 words across the top: Features, Navigations, and Metrics
Step 2: Give the participants a Sharpie and 3 sticky notepads in different colors. Have them list out everything the application does in each of those categories, and then place each one on the board under its respective heading.
Step 3: Draw a large rectangle on the board to represent the dashboard with a section across the top or left-hand side for the navigation
Step 4: Place the links in the navigation area and the features and metrics in the main area. Note: This process may take a considerable amount of time with lots of back and forth. As the designer, you should challenge the business case for every sticky note placed on the board.
Step 5: Refine the final sticky notes left standing on the board to their basic elements. If you’ve included a calendar in the design, decide which level it should default to (day, week, or month). If you have a file storage widget, choose which secondary actions can be performed (copy, download, share, delete).
Application distilling is a powerful technique that takes the difficult tasks of requirements gathering and wireframing and combines them into a single, easy process.
3. Know your platform
Now that you’ve done your research and distilled the application down to its basest elements, it’s time to design. Or is it?
We must first evaluate the platform on which the software was built. Be sure to know the basic structure and responsive nature of the platform so your design doesn’t have to be reinterpreted by the developer.
One example may be an application that has been developed using the Bootstrap framework should have a dashboard designed on the 12-grid system. There are a lot of very good tools out there that will provide you with a starting file for whichever application you choose.
4. Design it already
The great thing about application distilling is that the wireframe is already largely finished by the time you get into the design phase, so you can jump right into final composition design. Now, this post isn’t a how-to on basic design—it’s a how-to on dashboard design. For this reason, I’m going to skip over macro design principles and touch on a few key components that are integral to dashboard design.
“Be mindful of color theory when choosing a color palette for your dashboard.”
The decision about a color scheme is one of the most important ones you’ll make about a dashboard. Some clients may have a full color scheme already picked out, but when you have the opportunity to create a palette, be sure to be mindful of color theory.
The stoplight usually stands—unless you have very specific reason not to, be sure to use greens and blues for metrics that are tracking well and reds and oranges for those that are not.
Iconography is another important design decision for both stylistic and developmental reasons. When choosing iconography, you can go 1 of 2 ways: use an icon font pack or create custom images.
A nice example of custom iconography created by the Help.com team.
The first option is increasingly more popular because it’s quicker and easier to choose from already created content. It also will make the developer happy because icon font packs are simple to implement. However, a pre-made icon font pack won’t work if you’re designing for a niche application.
If the dashboard design calls for an extremely customized option, such as cartoon-like drawings for a children’s dashboard, you’ll need to either hand-create or hand-pick them.
5. Don’t forget the UX
The dashboard is the face of an application. The conversation it has with users must be well structured. Keep it simple—don’t use jargon or acronyms if at all possible.
“The dashboard is the face of an application.”
I designed a dashboard for a company that does a lot of work with a big box home improvement store. When digging into the application, I found terminology that the creator assumed was general knowledge, but in reality was company specific. It wouldn’t make sense to the average user once the application went to SaaS—it would have been a major negative for the application if it didn’t speak the language of the user. Natural language is the most useful, and powerful, language for an application to use to speak with a user.
Users interact with the dashboard more than any other portion of an application. They may navigate away from and back to it several times per use, and they may use the application several times per day, which can add up quickly. When an area of the system is used frequently, pay close attention to loading time. Any interactions or transitions should be subtle and quick. The user shouldn’t have to wait for interactions to load before they’re able to perform their desired tasks.
Keep it positive—depending on how formal of an application you’re designing for, this can look many different ways. A less-formal dashboard allows for fun colloquial language and maybe even emoticons, like in my example below.
For a more formal dashboard, achieve a positive tone by making the sum of your elements positive. Avoid making every element an action item that the user must complete. Instead, give them some warm fuzzies by showing them what they’ve accomplished.
6.Take it for a walk
Now that you’ve a finished design product, it’s time to get some feedback. There are many different sophisticated and well documented testing methods, and while those methods are useful and important, they’re not what I’m going to talk about.
Remembering that I’m writing about productized application dashboards, I’m going to kick it back to basics and discuss a time-tested and extremely fruitful method: the good ol’ show and tell.
“The dashboard can make or break the success of an application.”
Take your design and show it to your friends, random people on the street, or even your grandma, and see if the design stands on its own. Ask them to tell you about the dashboard. If they can explain the major function of the dashboard and application, then you’ve done your job well.
If you don’t pass the show and tell test, then you’ve found the beauty of iterative design. Catalog which elements of the design were not easily understood and take them back to the drawing board.
Get to work
Design is the new language of business. Companies must speak it beautifully to be successful. A dashboard design project is a large step to take for an application. The dashboard can make or break the success of an application, and we bear a lot of responsibility as designers to produce an incredible product. Let this article act as a step-by-step guide to help you through the process of successful dashboard design. Enjoy the process, and go create something amazing.
The post 6 steps to designing better dashboards appeared first on InVision Blog.