As a UX Designer at SAP, I designed the experience for interactive charts for a native iOS enterprise design system

Two iPads and two iPhones displaying screens with charts

Designing a chart library for native mobile apps

One of my main projects as a UX Designer at SAP was to design the system of chart components for the SAP Fiori for iOS design language.

Sections of this case study

Introduction
1.
Overview of the project and my role
2.
Quick look at the designs
Exploration of three UX challenges for mobile charts
3.
UX Challenge 1: Displaying selected values
4.
UX Challenge 2: Designing for flexible content
5.
UX Challenge 3: Encouraging best practices
Conclusion
6.
Looking ahead
1

Project overview & my role

My team created a design language for the mobile enterprise

I worked on the team at SAP that is responsible for creating and refining SAP Fiori for iOS, an enterprise design system bringing together the business process expertise of SAP and the intuitive user experience of iOS.

We worked in close partnership with Apple to define the appearance, behavior, and rules behind this enterprise design system.

I worked to bring charts into the design language

For over 6 months, I worked to define the appearance and behavior of chart components for SAP Fiori for iOS.

It all began with (some) research

Before I joined the project
The team already had early designs based on app explorations and client engagements.
When I came on board, we:
•
reviewed the chart requirements coming from our app teams
•
explored existing analytics apps
•
defined and prioritized our initial feature scope
Screenshots from left to right, top to bottom: SAP BI, Vizable, Tableau, Salesforce Analytics, Power BI, SAS BI, & Apple Health

My role evoled over time

Gaining expertise

After starting in a supporting role to a Senior UX Designer, I eventually became the team's lead designer for charts.

Team collaboration

Under the guidance of a design lead, I worked closely with one other designer, as well as with a developer and an architect.

My responsibilities included:
•
Defining the structure and interaction of chart components
•
Gathering requirements from app teams
•
Defining and prioritizing the initial scope
•
Creating specs and ensuring builds aligned to the designs
•
Refining the features roadmap for future releases
•
Writing detailed design guidelines for app teams

We gathered insights from multiple partners

Through conversations with a number of groups at SAP and Apple, we learned about our topic from various viewpoints.

We also learned where our project fit within the larger SAP ecosystem, and how that impacted the goals for the project.

We prioritized our feature set based on:
•
SAP app team requirements
•
Technical feasibility
•
Our points of view (and those of our design leads) about what would provide the most value to users
•
Note: We did not have a budget for external user research.
Drawing of a package
Researching analytics
Reached out to analytics subject matter experts at SAP and researched competitive offerings in the market
Drawing of a package
Concepting + Prototyping
Created early concepts, led team reviews of designs, and generated Flinto prototypes to show chart interactions
Drawing of a package
Working with developers
Met regularly with development team to work through concepts and supporting frameworks; worked with design and developers to ensure components were built to spec
Drawing of a package
Writing guidelines
Produced detailed usage guidelines for chart components
Text
Text
‍
- Text (Text)
- Text (Text)
- Text (Text)
Back to top

A quick look at the designs

2

In January 2018, we released our first charts to the SDK

The first release included 4 chart types:

Line charts
Column charts
Horizontal bar charts
Combo charts

Different situations require different means of accessing data

Users may need:
•
quick, at-a-glance access to data
•
detailed quantitative information
•
to be able to interact with data

To meet these varied needs, we created four chart variations:

Header charts

Simplified chart; summary info only, in the header, tappable link

Card charts

Simplified chart; summary info only, in the content area; tappable link

Static charts

Detailed chart; summary & detailed info in the content area; non-tappable link

Interactive charts

Detailed chart; summary & detailed info in the content area; full-screen; fully interactive

Back to top
3

UX challenge 1: Displaying Selected Values

Making it easy to see details on chart items users tap on, given complex constraints

We evaluated the benefits and drawbacks of existing approaches to define a more robust way of showing chart values

I analyzed two methods in use for iOS apps to display selected chart values:
•
Popovers
•
iOS value selector

Industry approach 1: Popovers

Popovers are being used by a number of apps to display details of chart items selected by the user.

Salesforce Einstein Analytics app

SAP BI app

Benefits: Proximity to data

Popovers allow details to be displayed very close to the related chart item, which helps clarify the relationship between the value(s) and the selected item.

Salesforce Einstein Analytics app

SAP BI app

Drawbacks: Blocking data, using small text

Particularly on a small screen, popovers can end up partly or completely blocking other chart items.

They can also be quite small, meaning their text content can become tiny.

Salesforce Einstein Analytics app

SAP BI app

Drawbacks: Apple does not approve of them on iPhone!

Moreover, Apple recommends not using popovers on iPhone, which was a key limiting factor when working in partnership with Apple.

https://developer.apple.com/ios/human-interface-guidelines/views/popovers/

Drawbacks: Popover + modal is disruptive and inconsistent

If we followed Apple’s guidance above and used a popover on iPad but a full-screen modal on iPhone, this would have presented two more challenges:

Full-screen modals can be disruptive

Modals are more appropriate for focusing attention on a discrete task like data entry than for quickly reviewing chart data.

Different display methods could create a disjointed experience

We wanted to find a solution that would be consistent, regardless of the user's mobile device.

Popover on iPad (Photos app)

Popover on iPhone (Reminders app)

Industry approach 2: iOS value selector

Enter Apple’s iOS value selector, used to display chart values as the user scrubs through data.

Benefits: Selector does not block data (on horizontal charts)

This value selector works well for charts where data is arranged horizontally (such as a column or line chart).

The selector has a dedicated row that allows it to move left and right and expand/contract to fit its contents without blocking underlying information.

Drawbacks: In other cases, the selector blocks/shrinks content

When used on a horizontal bar chart, however, the value selector starts to break.This value selector works well for charts where data is arranged horizontally (such as a column or line chart).

The selector has a dedicated row that allows it to move left and right and expand/contract to fit its contents without blocking underlying information.

It covers on-screen content
The selector’s connector line covers chart items as the user explores their data.
It compresses chart items
If the selector is given a dedicated space to the right of the chart, the plot itself gets squished.

This in turn makes it harder to compare the lengths of the bars.

We’d been tasked with finding a solution that would scale across a variety of chart types.

While it works well for column and line charts, Apple’s value selector wouldn’t hold up for horizontal bar charts – not to mention the complexity of applying it to scatter, bubble, pie, or other more complicated chart types.

We needed to find yet another direction.

Our approach: Adding a dedicated summary section above the chart

After much exploration, we created a dedicated summary section above the chart plot.
Content
This section displays the values of items selected by the user, as well as a default value set by the app team (here, average sales per month) and trend details for 2-series charts.
Interaction
When an item is selected (June in this example), the user can tap its title to drill in for more detailed information.

Benefits: Consistent placement, ease of comparison, larger text

Placement
Chart details are presented in a consistent location regardless of chart type
Comparison
Users can quickly compare selected data points with a default value in one compact location
Text size
Displayed values are much larger* than in apps using popovers

* In SAP Fiori for iOS, we avoid using text smaller than 12pt; the selected values are 17pt, with the trend and series labels at 13pt

Drawbacks: It adds distance to the data

Dedicating space at the top of the screen can create perceived distance between where the user taps and where the data appears.

The greater the distance, the higher the possibility of the user experiencing a disconnect between action and result.

Scalability was a key consideration to our design direction

We are not just designing one app; instead, we are creating a system that must support a host of business use cases.
‍
End users may have small or large data sets, may need to display one or multiple series at once, and may have a range of visual accessibility needs.

We felt the strengths outweighed any limitations

In the end, we judged that the flexibility provided by the summary section supersedes its limitations, and it became our solution for how to surface detailed information on data for the larger two chart formats.
Back to top
4

UX challenge 2: Designing for flexible content

How can we ensure our components are flexible enough to handle a range of content types for users around the world?

We considered two key attributes of users' content

Our charts will be consumed by users who speak different languages and have different levels of visual perception.
We thus had to keep in mind:
•
Different languages on users’ devices
•
Different text sizes for accessibility
In this section, I explore the impact of these topics and show how our designs address them.

Our charts needed to work, irrespective of the user’s language

As an example, take the Settings app from iOS 11.
‍
When the user changes the device's language from English to German, there is a clear difference in the length of content on screen.

Even for a component as straightforward as a table view cell, we can see how the spacing in the German version is much tighter than that of the English version.

Settings in English

Settings in German

Our components also needed to support large text

Returning to the Settings app, when the user increases their device’s text size from Large (Default) to xxxLarge, the English version of the table view cell remains readable.
‍
However, in the German version, the cell contents run off the edge of the screen, forcing the user to drill in to read them.

Settings in English with larger text

Settings in German with larger text

Our solution: Ensure the content container was flexible

In order to support long text labels and numerical values, our Summary Section:
•
extends the full width of the screen
•
allows content to flow off the right side of the screen, accessible by horizontal scroll

Summary section before scrolling

Summary section after scrolling

We tested whether our component met accessibility standards

Once they were built, we tested our charts with large text turned on.
‍
We were able to confirm that most content scales appropriately and remains readable even at the max size.

However, in some cases content became hidden when large text was enabled.

Testing helps us to detect these flaws and ultimately learn from and fix our designs, to ensure our components are accessible to as many users as possible.
Back to top
5

UX challenge 3: Encouraging best practices

How can we guide app teams to consume our components in ways that will best support their end users?

We shared guidance with external teams on how to use our components via in-person and online methods

Creating flexible components and testing them are only two pieces of the puzzle of ensuring a quality user experience.
Implementation of the designs is outside our control, but we can guide app teams on the ideal use of components during the design process.
We've done so by providing:
•
Detailed online design guidelines
•
In-person partner design trainings

Our online guidelines offered a detailed and persistent source of learning

One way we support app teams is via our guidelines website. I have written multiple articles that:
•
Describe when to use the chart types
•
Provide in-context charts examples
•
Flag issues to watch out for
•
Encourage best practices
In addition to writing my own content, I have also been responsible for editing articles written by the team.

https://experience.sap.com/fiori-design-ios/article/chart-types/

Our in-person training workshops provided hands-on, intensive coaching

We have also led design training workshops in California and Germany.
At these events, UX designers from partner companies spend several days learning about our design process and how to use SAP Fiori for iOS in their work.
For these workshops, I have:
•
Prepared and presented content to participants
•
Been a team mentor during design exercises
Back to top
6

Looking ahead

The team continues to refine our product vision

Now that the first release of our charts is public, we need to build on what we’ve created and re-examine what has or has not worked well thus far.
With this in mind, we are working more closely with a user researcher to expand our knowledge of how users rely on charts in their daily work.
The design process doesn’t stop at one release – instead, it just picks up where it left off and keeps driving towards a better user experience.
Back to top