Published on <a href="https://blog.prototypr.io/3-critical-steps-to-a-usable-dashboard-3474ca1ebb37?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Maya Levin 
Browsing through inspirational website like Pinterest and Dribbble, I’ve noticed the large amount of dashboards showcased. Boxy dashboards, dashboards with lots of whitespace, colourful dashboards, circular dashboards, highly interactive dashboards and static dashboards. They are all indeed very beautiful, but the more projects I complete, the more I find these images are great for visual inspiration, but lack detail and functionality.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*VmWwzGaArj9YFf4ElKSIgQ.png">A screenshot of a Pinterest search for “Dashboard”
Especially in the case of dashboards, usable does not mean beautiful. Function must come before form. This isn’t to say a functional dashboard must be “ugly,” rather that functionality is worked out before addressing aesthetic. To me, a dashboard a simple concept. It is a place where specific data can be viewed by a specific person, for a specific purpose. A good dashboard should allow the user not only to view and access data, but understand it. The level of understanding should get deeper as they delve into a specific section. Dashboards, by definition, consist of multiple pieces of data that are linked in some way. In most cases, the initial dashboard view is the tip of the iceberg that enables the use to access deeper information. This notion of “levels” is directly associated with navigation and the type of framework chosen to contain all the information.
Although dashboards are fundamentally logical, they can get quite complex, particularly when including varying levels of functionality by user role. There are a few steps that can be taken to ensure your navigation, data visualization, and interactions fit with the users’ needs.
<ol>
<li>Talk to real users first</li>
</ol>
<ul>
<li>Understand their context, routine, and basic needs</li>
<li>Identify pain points</li>
<li>Identify risks and opportunities</li>
</ul>
In this first step, the primary goal is to understand context. Ideally, you are doing contextual inquiry: observing your users in action, in their environment. You are talking to them in an unstructured way (no strict interview protocol) to gain an idea of their day-to-day. Depending on if you are designing a completely new tool or re-vamping an existing one, you are collecting intel about how the users feel about accomplishing their tasks. Only if it is relevant, you can discuss opportunities and how they think a different or new system could better serve them. Your exploration in this step should be specific to a task or discussed if the user mentions it. This step should not be taken if the questions you would ask are generic or leading.
<img alt="" src="https://cdn-images-1.medium.com/max/785/1*DuUgFstZdTYEyi4AUpvk5A.png">Sample questions you should ask during contextual inquiry, and questions you should avoid.
2. Establish a hierarchy of user roles, responsibilities and permissions
<ul>
<li>Know how users start to use the dashboard and if there is any setup required</li>
<li>Identify all roles, responsibilities and permissions</li>
</ul>
Some questions you will need to have answered before even thinking of data visualization are around the different types of users that may have access to your dashboard. In one project I worked on, many hours were spent attempting to identify who was supposed to see what information, who was giving permission to who, and who did what tasks. Ultimately, we established 4 “views” that showed different levels of information. These included an “admin” view, a “manager” view, a “supervisor” view, and a “staff” view. This was a critical step in the design because it allowed us to separate user flows and make sure we accounted for all actions and functionality. Having these discussions even helped the organization clarify and change some of their existing roles based on the functionality the new dashboard would offer.
If you don’t know where to start, defining roles and responsibilities using the idea of a RACI (Responsible, Accountable, Consulted, Informed) chart is a great way to define and document hierarchy.
<img alt="" src="https://cdn-images-1.medium.com/max/881/1*nNeYXwHNTREVPYmZDmSWzA.jpeg">Defining roles, tasks, and permissions of various users
3. Create user stories and flow charts
<ul>
<li>Make simple diagrams illustrating the steps a user goes through to complete a task</li>
<li>Identify what depth is needed for information at each touchpoint</li>
<li>Think about back-nav logic</li>
</ul>
When thinking through each “level” of the dashboard, it is important to know why a user is there and what they want to know at that stage. If you know their story, you can break it down into steps, and work back from the deepest detail to the highest level screen.Working in reverse order can help identify the best way to frame navigation in your dashboard, but if working in reverse seems uncomfortable, you can also create your flow by starting with the most high level tasks, then add detail until all levels and tasks are included. You don’t have to get too deep into the navigation components like breadcrumbs and back buttons (yet), but you do need to think of all the possible actions a user would want to take at each stage so that you can think through the type of navigation that will work best.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*MY60ovHslT16fz-8iEdTiQ.jpeg">Example of a flow chart for a blog application. Although not specifically for a dashboard user, the concept of the chart is the same.
Because of the practical nature of dashboards, I would caution against reinventing the aesthetic wheel. Change for the sake of change becomes impractical and ultimately confusing for users who have become accustomed to viewing statistical data in a certain way. Big visual changes should only occur with sound reasoning and research behind them.
Where you can get more creative is in the navigation framework and interactions. If you know your user, you can create a kind of personality to your dashboard that is reflected in how it transitions from one screen to another, in hover states, and of course in the style guide (fonts, colours, line weights, iconography, etc.). This is the area where a strong collaboration with motion and visual designers (or a single individual’s unicorn skills) can push a design to exceed expectations both in function and in form.
Have you made a dashboard lately or come across one you particularly love? Share it!
<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fupscri.be%2Ff51076%3Fas_embed%3Dtrue&amp;dntp=1&amp;url=https%3A%2F%2Fupscri.be%2Ff51076%2F&#038;image=https%3A%2F%2Fe.enpose.co%2F%3Fkey%3DdRXnS9Gplk%26w%3D700%26h%3D425%26url%3Dhttps%253A%252F%252Fupscri.be%252Ff51076%252F%253Fenpose&amp;key=d04bfffea46d4aeda930ec88cc64b87c&amp;type=text%2Fhtml&amp;schema=upscri" width="800" height="400" frameborder="0"><a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a></iframe><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=3474ca1ebb37" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/3-critical-steps-to-a-usable-dashboard-3474ca1ebb37">3 Critical Steps to a Usable Dashboard</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

3 Critical Steps to a Usable Dashboard

Top Stories