This is Part 2 of 2, for Part 1 of 2, please click here

4. Visual design

After wire-framing is done, it’s time for the fun stuff: visual design. In this phase, we will bring the experience to life by ‘dressing the skeleton’, using colors, typefaces, icons and other design elements.

During this phase we define: (branded) visual guidelines, color palette, iconography and typefaces. 

We often start by using a moodboard to communicate the ‘visual feeling’ that we will seek to convey – and design.

Example of design moodboard

A moodboard is unmissable in creating consensus about general look and feel, and moreover communicates inspiring (visual) examples. Then, when the moodboard has been agreed upon, it’s time to design an element library. We often apply Brad Frost’s atomic design theory, offering an elegant yet flexible way to build up visual design for digital solutions.

A design element library – or often referred to as Design System – is composed of the building blocks that we need to actually start designing the ‘canvas’, built up from individual elements. By working in such a way (as Brad Frost also emphasizes) you allow yourself flexibility in creating different ‘design compositions’, yet maintain an overall consistent look and feel – regardless the device your user is on (desktop, laptop, mobile, smartwatch).

Example of element library

When the element library is done and all the right icons, fonts, colors, etc. have been created, the visual design of the dashboards can start. For this, we take the completed wireframes and start ‘filling in’ the visual components in a coherent and consistent way, where the ‘motto ‘form follows function‘ really counts: you want a dashboard to be functional first and foremost. After that comes the beautiness of it. Less is more, in many cases – especially when you’re designing a functional tool such as a dashboard. Trying to reduce the mental/cognitive load on the user should be your primary goal, and visual design can great contribute to that.

A great tool to help reduce cognitive load, is by respecting the Gestalt theory: Reification, multi-stability and invariance are important factors to take into consideration when grouping, dividing, aligning and distributing objects.

Example of finished prototyping dashboard

Example of prototype on iPad

5. Prototyping

Lastly, there is the prototyping bit. Depending on the type of software ‘backbone’ you use (Tableau/Salesforce/Qlik/custom), you will have to ensure that your prototype is compatible with – or optimized for – that specific platform. In our example, we have a custom built dashboard with custom APIs endpoints, thus giving us quite some freedom in design and prototyping. However, often you will be constrained by the software

Variety of prototyping tools

If you want to create a clickable mockup/demo (a very easy and fast way to demonstrate the desired user experience), there are many prototyping tools you can use. InVision, Principle, HTML with Javascript and Framer are just some of the possibilities you have here, but really the possibilities are endless. Whatever works best for you. In general, we stick with custom HTML & Javascript when there is quite some customization to do, and use Framer when the prototype is animation-heavy. However, before we start prototyping, we use InVision Freehand to collaborate on the user experience flow and general setup of the prototype – even with the client sometimes.

InVision Freehand for collaborating on final UX flow

6. Bringing it all together & testing

Finally, when you have gone through all of the above steps, it’s time to bring it all together: crunch time! Most prototyping tools offer great ways to export your prototype to a directly usable HTML/web experience, offering a super easy way to publish your prototype.

However, it’s very important to know (and plan for) which purpose the prototype serves.

  • How does your client want to use the prototype?
  • As a stand-alone demo on an event?
  • Across multiple devices?
  • Should it be accessible without internet connection?
  • What’s the maximum internet speed that the demo will be shown/run at?
  • Should the demo be publicly accessible or be private only?
  • Should the prototype be fired up from an app, browser or directly from the OS?

These – and other questions – should be answered to best plan for your prototype release.

Testing is another very element that should be taken into consideration. At this moment in time, you have a first MVP to show to potential clients and users. This allows you to gather feedback and see what improvements should be prioritized based on these tests results. We won’t go in-depth on how to test your MVP, but there are plenty of resources out there, to help you with that.