Data is plentiful - but it is the visual hypothesis' that can be drawn from it that makes it truly powerful.
In 2009, the charting infrastructure in Portfolio Analysis was enhanced to provide more charting capabilities than was previously offered however the usability of this product was not the main focus. In turn, while it served the purpose of aiding data visualization, the usage by users was very low. Instead, charts were largely generated and saved off by internal application specialists. With the HTML re-write in 2012, usability was the front end focus - with an emphasis to put our users back in the driver seat when it came to building reports and charts.
Illuminate Analysis with Charts
The challenge that comes with designing a charting component for any application is finding the balance between customization and usability. Charts are deceivingly simple from a front end perspective, but the underlying code has thousands of attributes that can be set for a given chart and it's a fact that users will want to have some level of control over this customization. In addition to formatting charts, certain chart types serve as better visual aids for different types of data so it's important to guide the user through building the best possible chart for the data available. In 2012 we were at a point where we had a robust charting platform available to integrate into any application but the user interactions had to be ironed out in a way that would make charting easy and fun to use.
Examine & Understand
We began our research by taking a hard look at why the design failed from a usability perspective in Portfolio Analysis 2.0. Jotting down the pros & cons list, we distilled that the user experience was most favorable once the chart had been built (interactions, formatting, etc.) but there was a list of fundamental intricacies that made chart creation less than desirable.
Insights & Interactions
Since the charting workflows in Portfolio Analysis 2.0 were seemingly difficult, we mapped out all existing interactions in order to bring to light new assumptions that could be made in order to improve the user experience. We soon realized that building a chart in PA2 was extremely tedious, proving to be the hurdle for user adoption of the charting tool. An idea that was generated from this exercise was if we could disconnect the chart data from the report data then this in turn would result in added charting flexibility. In addition, making some assumptions regarding the dates & frequency set on the chart could improve the user experience greatly.
Sketching User Flows
Next, we went to the whiteboard to sketch out ideas - good & bad - in order to push ourselves past the obvious or impossible. Final sketches were mocked up in Mockingbird software to help facilitate discussion and feedback from stakeholders. Ultimately, the team was split across two fundamental designs that were proposed via the sketches. Upon request, both proposals went to the wireframing stage to see if this would help with collecting more feedback prior to development from a wider audience.
When we embarked on the idea that charts and reports could be separate, there were two schools of thought.
1.) Disconnect chart data completely from the report for the most amount of flexibility.
2.) Disconnect key attributes of the report data from the chart data so that the two remain loosely tied to one another.
Both options were wireframed in order to better communicate the user workflows with a wider audience. Unfortunately, due to timeline restrictions, a decision was made prematurely to go with option one and disconnect charts from reports entirely in order to make charting extremely flexible. Had more time been allowed for prototyping and usability testing the two workflow proposals - we would have discovered the wrong decision had been made.
After 4 months of development time, Portfolio Analysis 3.0 - Beta application showcased the new charting workflow where charts and reports were disconnected and the feedback was dismal.
Usability testing was performed to help expose and validate the assumed pain points in the new charting workflow and we went back to the drawing board to see if improvements could be made upon the design. Unfortunately, the pain points stemmed from the fundamental design decision to disconnect charts from reports that ultimately led us back to a version of the second charting proposal.
We couldn't take charting offline in the application so it was an additional challenge to reconstruct charting without disrupting the user workflows in the beta application.
Back to the Drawing Board
Examine & Understand
The first attempt at charting in Portfolio Analysis 3.0 was not a complete failure. We did preserve behaviors from Portfolio Analysis 2.0 that have always been well received as well as introduce new charting logic.
- Changing the date on the chart did not update the report.
- Options as to where to place the chart tile were limited.
- Users did not like the full screen chart editor.
- Chart creation via right click is simple and intuitive.
- Frequency of the chart data could be different from the report data.
- Chart rendered instantly if it used the same data as the report.
The existing charting workflow let you right click on any column and build a chart for that column of data. This workflow was simple, straight forward and very well received.
As soon as the chart type was selected, this was the point of disconnect from the report and the user was placed into a full screen chart editor where they could interact with the chart and then choose to throw away the chart or add the chart as a new tile to the multi-tiled report.
After further deliberation, it was decided that instead of launching the chart into a full screen chart editor that served the purpose of exposing all chart options and guiding the user through adding the chart tile to their report, that we would simply flip the report tile over to expose the chart tile.
We preserved the concept of "throw away" charts where the application wouldn't prompt the user to save the chart upon toggling back to the report if no additional chart options were set on the chart.
Also, since reports and charts were contained in the same tile now, it became more obvious that settings would be shared between the two. Still, we were able to disconnect some settings where it made sense.
Adding the report/chart toggle workflow above addressed a lot of the fundamental concerns with the reports and charts not being intertwined.
A piece that still remained was the full screen chart editor that previously allowed users to interact with the chart and add the chart as a new tile to the multi-tiled report.
Since the creation of a chart just flipped over the report tile that the user was on previously, this full screen editor really became obsolete however it exposed all of the charting options.
The new direction for charting meant everything should be accomplished from the chart tile itself as users wanted to edit the chart within the constraints of the multi-tiled dashboard report they were trying to create.
A series of right click contextual panels were proposed to change series specific attributes while the main wrench icon would drive the chart type selection.
To ensure we got these interactions right, I used InVision to build out a prototype.
Once the prototype was complete, I worked with our User Research team to perform a formal usability test with the new proposed method for editing charts. Some improvements were made to the design based on the feedback and tool-tips were added to better guide the end user.
The Final Product
Charting in Portfolio Analysis 3.0
A year after development had first began on the charting feature in Portfolio Analysis 3.0, the improvements made to the fundamental design have shown a large spike in client usage. We are continuing to build out charting with more interactive features and chart types to keep up with the demands of our users.