This blog is the third in a series on prototyping. In this series, our first post walked you through why prototyping will benefit your development process. Our second post lists out just a few of the many options to integrate prototyping into your process. This blog will walk you through some best practices to keep in mind during the prototyping process including the building out of the prototype and communicating design choices with the clients/end users of the dashboard.
Tip #1: Try to get the layout as close as possible
The most important thing to keep in mind when working on the design of the prototype is to try to get the layout of the prototype to match what the final dashboard will look like. This means a few different things.Â
One seemingly small, but important, thing to keep in mind while prototyping is the use of color. If the client has rigorous brand standards, stick to those as they will be familiar with how those colors are used in dashboards. If they have certain headers or footers associated with their suite of dashboards then include those as well. If they do not, then this could be your time to shine by helping them to come up with a standardized design for their suite of dashboards.Â
Another thing to keep in mind is to try to do as much as possible to keep the client focused on the important pieces like the chart types and the storytelling of the dashboard.
Lastly, if you are prototyping by hand do everything you can to keep titles and labels as legible as possible to not confuse the client and have them constantly asking you what everything says.Â
Tip #2: Don’t get caught up in the little things
An important thing to keep in mind when putting a prototype together (and something that’s important to communicate to the client) is that a mockup is used to portray the structure and format of the final product and the type of information that will be available in it. Getting caught up in the minor details will not only take longer to develop but it can also be distracting.Â
For example, if you are going to have a bar chart of sales by state, don’t generate a fake label that says $100,000 if you’re not sure of the relative proportion of the sales. A simpler label such as $#### or $total sales will suffice. This will keep you from spending the time changing these per row and it will keep the client from being thrown off by a seemingly inaccurate value. This applies for the dimension values as well. Rather than make up fake customer names, Customer #1/Customer #2/etc. will suffice. Keeping it clean will also help focus the discussion while you’re demoing it to whether or not the overall design speaks to their needs.
Tip #3: Make sure you understand the data structure and limitations prior to prototyping
To some, this might be the hardest part of the prototyping process. Understanding how the structure of the data affects the visual types being used is something that comes with practice.
For example, you don’t want to mock up a filter action that doesn’t actually apply to all chart types if the granularity of the data differs between the various metrics you are displaying. This is key for when the data structure is already provided by the client. On the flip side, if there is no current data structure you have a little more wiggle room with the prototyping you can provide. Not having a data structure also gives you the opportunity to recommend what the underlying data should be structured as to support the prototype you created.Â
One thing to keep in mind in recommending a data structure is that you don’t want to force a structure that won’t be robust enough to handle the variability of the data; this could lead to the dashboard being reworked in the future to accommodate a more robust data structure.
Tip #4: Communicate differences to live product, if any
Regardless of what method you choose for your prototype, you’re not going to be able to get every little thing in. If you did, that wouldn’t be a prototype that would just be development. And not everything needs to be anyway. While filter actions, for example, increase the interactivity of the final product, they add very little utility to a prototype. But it’s important to note these as you go along and communicate that with the client. If there are labels or actions missing, just make sure to call that out so they can more easily picture what the final product will be like.
Tip #5: Communicate purpose and value
So we’ve talked about things that a prototype can’t do or won’t have. But you don’t want this to get in the way of using it as a tool to advance your development process.Â
The last step in prototyping is getting sign-off to move onto the next phase and in order to ensure this goes smoothly, you’ll want to communicate more than just the ‘what’ of what you’ve created. Bridging the gap in the client’s mind between the mockup and what they’ll receive requires communicating the ‘why’ of your choices.Â
- How does that particular chart type contribute to their overall analysis?Â
- Why does the layout of the dashboard help the users understand the full picture of the insights?Â
- What value do additional pieces you’ve weaved in add to the report?
They can see the prototype, now you gotta tell them what it means to them.
What we have mentioned above are just a few of the best practices we think you should keep in mind to be as effective as possible when developing your prototypes. We hope you consider these things as well as what we talked about in our previous two blog posts as you build out your next prototype. Happy prototyping!
Need more help making your dashboards a work of art? Our knowledgeable team of experts is here to help!
