HR reporting design: part 5 – Putting it together

In the previous articles we focussed on the user needs, information that would be needed to meet those needs and why measurement would often be needed to provide a full picture.  We now look at how to communicate the message.

There are two typical ways of communicating report-type information:

  • In a static document, such as a presentation
  • In a dashboard.

As noted, there are advantages and disadvantages with both and one should consider the tradeoffs concerned, led by the user experience.

Whichever route you take – and you might find you need to incorporate both – there are some common themes.

Flow

Flow is vitally important in communicating information and ensuring that the audience understands a consistent and accurate understanding of the key messages.

In a presentation the flow can be considered as the story throughout the document. This story needs to be convincing and logical to communicate an insightful and powerful call to action

A modern dashboard is increasingly acting like an application to guide the user through the analysis process.  As such they need designing as other on-screen applications with clear usability, simplicity and a logical structure so new users can use them effectively without considerable instruction.

Data communication

How we perceive communicated or visualised data is an emerging science and there are numerous books that cover this subject in detail.  Coercing many data visualisation tools used in the workforce to present information in the optimal manner can be a time-consuming process and few do so by default.

There is also an issue between how viewers comprehend information.  Someone trained in statistics will view data with a different set of filters to a lay-person.  Powerful visualisation techniques such as box plots often will need some explanation when confronted for the first time.

Learn, prototype, measure cycle

Effective designs aren’t created by chance, or solely by a talented designer working as an all-knowing expert but are the result of a systematic process of prototyping, testing and evaluating the results.

This process needs to be done with real users not the project team (who will be biased in how they view the ‘product’ or just conditioned by what they meant to show). Fortunately the design industries have presented us with a sophisticated toolkit of how to  test and measure the effectiveness of design.

 

 

 

How quick should this cycle be?  It’s certainly possible to complete it within 3 days per iteration for most activities.  At the beginning you will probably want to use wireframes or even lo-fi paper testing (even for applications that will be on-screen).  Getting the design as close as possible before moving to the final tools is the key to an effective design.

Andrew Marritt