Sketches, Wireframes and Prototypes

What's in a name?

From low levels of fidelity sketching to high levels of fidelity prototypes, each has its place in communicating your dashboard ideas to stakeholders and for generating feedback.

Each type is a way to validate or invalidate our assumptions. They simulate the experience we want to deliver without requiring us to build the real thing. You shouldn't worry about making them perfect as long as they communicate the idea and are appropriate for the feedback you are aiming to get.

Sketches

Sketching is an important part of UX design. You do not need to be a natural born artist to be able to sketch meaningful designs. Sketching allows you to form and evolve ideas at speed.

Wireframes

Wireframes serve as a middle ground between sketches and your first prototype. They help you plan the layout and interaction patterns of your users without distracting details like colours or copy. The user journey should be clear without needing colour or shading or fancy menus.

A wireframe is a low fidelity layout of the design which has three simple but direct targets:

• To present the main information group.

• To draw the outline of structure and layout

• To provide the vision and description of the user interface.

A wireframe has very obvious visual limitations as it usually only shows lines, boxes and different greyscale colours.

Prototypes

Prototypes are early models of your product built to test a concept and learn from it. They are designed to emulate not just the functionality of the product but also the look and feel. Where possible, develop prototypes with the intention of recycling code from the prototype into the finished product.

Wireframing best practices

To bring the best out of the wireframes and to set a proper foundation for the next step of the process UI, follow these several simple rules below.

• Understand the goals, objectives and key functionalities of the dashboards before building a wireframe.

• It will be a great help to have the use cases available before starting on the wireframes. Ask the business analysts / product managers to provide the use cases, approved by stakeholders.

• Wherever possible use real data. If real data is not available, use 'meaningful but random data'. This should start with having some information about the data - the approximate number of data points for example, their range and spread, and so on.

• Use the simple design of the components / visualisations - adding detailed components will take you a lot of time and effort without being particularly useful.

• Maintain consistency - similar components must look the same on all your wireframes.

• Use annotations to describe the functionality / logic to the developers.

• Based on the use cases, provide the viz options to the stakeholders which make sure the viz is not overcrowded (we recommend not to show more than five measures on a single viz).

• Plan the user journeys - consider what could be the entry points to the dashboard, and its tabs.

• Think of different options a user could try on the filters and how the data should display accordingly.

• To give a better sense of data to the users, group and categorise the related viz / tables. You can achieve this by using boxes, borders or background colours.

• Follow a consistent style for the text eg the links / buttons / information icons and anything that is interactive should be in blue throughout the dashboards.

• Wherever possible, update the results on the dashboard only after the user selects all the required attributes within a filter and click the 'apply' button, rather than updating it for every single option selection.

• Minimise the use of colour in wireframes wherever possible.

• In a few instances when the wireframes aren't the best solution, start with the sketches and present your ideas to the stakeholders.

Simplicity is key

• Avoid designs that will confuse or will make it difficult for them to navigate.

• Consider quality not quantity, don't overload the view.

Design guidelines

Things to consider when designing your dashboard

• The first place your eyes go to is the top of a screen. Placing information here will create a good visual hierarchy that users can easily scan.

• Use consistent size for all dashboards in a workbook.

• Guidelines and borders should be used sparingly and only when absolutely needed.

• Without any white space, your dashboard will look cluttered. This makes it difficult to distinguish which information is the most important.

• Grouping like data together will allow users to navigate through the information easily.

• The NHS logo should be placed on the top right hand corner of each dashboard tab.

• Stand far back from your screen to check your layout and presentation.

• Print the views in black and white to consider how it may look for people printing the report or for another perspective.

• There should not be any nulls on dashboards. Use appropriate values to replace these i.e. 'Unknown' or 'Not Applicable'.

Effective communication

Things you should consider to better communicate information to users.

• Consider your audience and your message carefully before starting to design your report and dashboard.

• Apply a clear and consistent style across reports.

• Avoid overloading reports - remove any elements that are not needed to convey the message.

• Use colours and shapes economically, limiting the number of colours and shapes in a report or a dashboard.

• Use fonts consistently as per this design guide.

• Emphasise key information while de-emphasising less important information.

• Use sizing effectively to make sure your visualisation and text is easily visible.

• Ensure methodologies are included, especially when including metrics or statistics.