4 Tips for Better Data Visualization on Mobile Devices

Demand for data visualization on mobile devices is on the rise, both in the consumer and business spaces. Whether it is stock price performance or sensor fluctuations in a production plant, data in enterprise helps in monitoring operations, optimizing processes and quickly making informed decisions. One of the challenges in providing uninterrupted access to visualized information is the drastic reduction in screen size when moving from a desktop or laptop to a tablet or a smartphone. Best practices for print or large screen graph presentations are unsuitable: chart titles, axis labels, and other graph elements on a small screen are clutter rather than useful information. Nonetheless, effective data visualization on mobile devices can be accomplished by following these recommendations.

1. Determine what your users need

Before starting graph design for a mobile screen, gather particulars about what kind of data and what kind of format should be presented so that the charts best meet your users’ needs. For example, while temperature data are typically presented on line graphs, a user who really needs to know only how today’s temperature compares to tomorrow’s forecast might be completely satisfied by a numerical representation of a few data points rather than an actual chart. Understanding how users utilize information rather than in what form they expect to see the data will give designers more freedom to explore functional solutions to the problem.

2. Reduce standard graphs to bare bones

Visualized data, when accessed on a mobile device, are typically part of an app that was built for a specific function. For example, various banking apps show user account balances, pending payments and even breakdowns of various spending categories. When a user engages with an app, she has a specific purpose which provides context to the data that will be accessed. For that reason, graph titles, axis labels and other supporting elements can usually be omitted.

3. Take advantage of mobile device capabilities

Mobile device as a data display platform is great for interactive graphs. First, screen orientation (portrait vs. landscape) affords different pros and cons for chart displays. While portrait mode may work very well for a bar chart with a few data points, landscape mode is superior for line graphs. Second, interactions with the graph offer numerous opportunities to provide the user with detailed information that he may need while avoiding clutter on the screen. For example, pinching and zooming on a line graph could show the user changes in data over different periods of time, affording a historical glimpse of the trend as well as a very close look at data over the last hour. Similarly, tapping on individual bar graphs could bring up a modal containing a precise data label for the value.

Moreover, isolating a data point from a graph could give user access to detailed information about the data, allow her to take specific actions such as forward data to a colleague, attach a note, print graph and so on. Alternatively, a drawer that contains detailed information and slides onto the screen from the side of the graph is a good way to avoid visual clutter while increasing data density and preserving more specific information. Here, the user would only need to tap on a point in the graph to access details.

4. Follow design best practices

When designing the chart for a mobile app, especially when it is meant to support business processes or tasks, it is critical that information is legible for users given their work conditions. For example, if app users work on day and night shifts, the graph design should accommodate different lighting conditions for this group. Graphs with higher contrast work best in varying light conditions. Charts that contain multiple data sets (more than one line, for instance) require even greater contrast as two lines of similar hue may be indistinguishable from one another on the device screen.

Additionally, typography should follow the information hierarchy using appropriate size and weight for the level of importance. Avoid compressed type used in print materials as it will be more difficult to read. Similarly, avoid creating interactive graph elements that are smaller than suggested by guidelines for tappable areas. Moreover, assess how modals and pop-ups that are used to supplement graphs affect the users’ ability to extract meaningful information. Conducting a usability test with the graph and measuring the Standard Usability Score (SUS) will help ensure that visualized data meets users needs effectively.

In conclusion

User research should inform design requirements for data visualization. By stripping down graphs that are typically made for print and large screen presentations to their bare bones, you will be able to reduce chart clutter and help your users to better comprehend the presented information. Taking full advantage of the interactions available on mobile devices and weighing the pros and cons of various graphing libraries available to the developers will help ensure that the graph will be interesting, engaging, and, most importantly, informative to your users.

This blog post was written with Stuart Conway and originally published here.

ROI of UX: Mozilla Support Site Redesign

Nielsen Norman Group recently shared a great case study showing return on investment of utilizing user-centered design and usability testing for a website redesign. Take-aways are:

  • Mozilla support website redesign took 560 hours (or 14 weeks)
  • Multiple UX research methods uncovered pain points and areas for improvement
  • Designs were tested as prototypes and improved based on user feedback; 7 versions were assessed during project lifecycle
  • As a result, there was a 70% decrease in support questions submitted, and
  • 80-90% of submitted questions were answered within 24 hrs, an increase from 40-60% rate before re-design


Visualized Data Helps Drive Decisions: A Primer on Chart Types


Information drives decision-making, especially in the business world. When multiple parties are engaged in collecting intelligence, synthesizing data and determining actionable items based on results, effective ways of communicating information are critical. First, it is imperative that data are collected and synthesized using appropriate procedures. Second, it is crucial that results are summarized and presented in an accessible manner. Visualized data is one of the most effective ways to communicate insights from information and spur decision-making.

The basics of graphing data as well as core design principles can help translate quantitative and qualitative data sets into vessels of brief take-away messages. The most common types of charts are bar and column graphs, as well as pie and line charts.

Bar charts allow viewers to visually compare values across multiple categories. Because these charts present data in horizontal bars, they are especially handy when the number of categories is large or the category labels are long.

  • Good use case: Revenue generated by each member of the sales team (assuming the sales team is reasonably small).
  • Bad use case: Regional temperature averages for every month of the year. A line graph would be more appropriate here. 

Column charts, like bar graphs, allow viewers to compare values across categories. Here, however, the bars are positioned vertically rather than horizontally. Column charts are particularly useful when negative and positive values need to be represented, a handful of data points are shown, and labels of categories are short.

  • Good use case: Company revenue across the four quarters of a year.
  • Bad use case: Population across every state in the US. Here, a bar graph or even a table would be more appropriate.

Pie charts should be used to represent proportional relation between several values in a single category. Here, quantitative information is converted to percent values that add up to no more and no less than 100%.

  • Good use case: Mobile device operating system breakdown in a city (e.g. 58% iOS, 36% Android, 4% Windows, 2% Other)
  • Bad use case: Average duration of calls to the Help Desk at a business. Here, a bar or column chart would be most appropriate. Here is another example of a poor pie chart use.

Line charts are best for showing changes in data over time. A line graph can contain several sets of data, allowing the reader to compare them across time, such as company profits and cost of operations. However, multiple series of data should be presented with caution; otherwise, a reader will infer a presence or absence of a relation between visualized data that does not actually exist (see excellent examples of this problem here). Research methods should inform if and when plotting multiple series of data in a line graph is appropriate.

  • Good use case: Coffee consumption rates per department at a company during 2014.
  • Bad use case: Scores on tests measuring different variables (e.g. aesthetic appeal, ease-of-use, and level of an innovation of a website) at a single point in time. Here, a column chart would be appropriate.

Although these are the four most commonly encountered charts, their variants, such as stacked column graphs, bubble charts and treemaps also exist. These alternative chart types have their own specific use cases and should be selected only after carefully considering what type of visualization is most appropriate for the research method used to gather the data, and what insights the chart must communicate. If the amount of information that must be displayed exceeds the capabilities of these standard graphs, often the best practice is to break the data down into simpler, more easily absorbed sections. In most instances, the simplicity of design and clarity of information conveyed by a carefully chosen standard graph cannot be surpassed by their more complex variants.


This blog post was originally published here. 

Why Software Dev Projects Fail: a Classic Reference

About 25% of software development projects fail before launch (source). For many businesses such failures can be the straw that broke the camel’s back. In his 2005 article Why Software Fails, Robert Charette discusses common factors that contribute to such poor outcomes. While some responsibility can be laid on the doorsteps of stakeholders and managers, lack of team-wide focus on user needs and user-focused requirements are also among the culprits. Although it’s been 10 years since the article was published, little has changed in how software development projects are executed. Hence, use this reference to help evangelize user-centered design and user experience practices internally and externally!