A look at the user experience visualizing historical data with varying levels of granularity.

Introduction
In the world of rich internet applications a very common goal is taking not easily accessible or multi-point data and outputting reports and visualizations. One thing that rich internet applications do very well is to display data across a period of time, and allowing the user to select ranges of time. Usually the output consists of a numerical report grid and some accompanying visualization. Most if not all, reporting applications focus around this capability.

Recently I had the opportunity to work on a Search Engine Optimization application that is designed to accept analytical and keyword data, then output reports and visualizations. In addition, the application will guide the user in creating keyword segments, and in turn produce personas. These activities will ease the management of campaign by managing segments and personas rather than the possible tens of thousands of keywords. At this time, let’s focus on the first phase of the reporting business process.

The user will upload data to the application and then the application will output reports and visualizations. As we dove deeper we discovered that the analytical SEO Data could be made available to the user on daily, weekly, or monthly basis depending on the client’s business objectives or processes. Thus, the user could upload daily data or summary data for weeks or months at a time. The Keyword data would remain largely unchanged, unless completely new campaigns were created, or drastic changes were made.
The client’s business requirement for this phase is to have a flexible application to allow the user to upload any range of data, at any time.

Design Approach
Keeping in mind the client’s business requirements for flexible data importing and reporting, our design focused around a date range slider to control this reporting interaction. Sliders are intuitive to use and we have successfully implemented them in many of our solutions. We coupled the slider with a report granularity selector for daily, weekly, and monthly reporting. The image below is an example of date range slider:

At first glance, it seemed like a straightforward objective and we did not see any issues with the process nor our approach, but the following is a narrative of the events that took place during 2 days of working through this business requirement, and the use scenarios that resulted from it.

Discovery
As I began to lay all this out, I started to see that the interaction between the data available and the date range slider would be critical. At first I saw two options:
The first option, the date range slider would drive how the data was to be reported, but the data available would drive what reporting options are available to the user. The user could only select by the period the data is available.
The second option was to have all reporting options available regardless of what data is available and normalize the data when applicable. For example, if the user selected to report by day, but the only data available is by week, the application would average the values by day.
To help us through this exercise, we developed a series of user scenarios to test both approaches and weigh the pros and cons of each.

We used this data import condition for all user scenarios:
The user will import 7 daily files, then 3 weekly files for the next 21 days for the first month, and a monthly file for the next.

Visually represented the data would look like this:

User Scenario 1:
The user wishes to view daily, weekly, and monthly data.
We set up this scenario as starting point based on a fairly complex data import. The objective here was to see how the slider would behave for simple reporting requests.

The Issue(s):
How should weekly and monthly reporting options be displayed, if the user selects report by day? The user knows daily, weekly, and monthly data are available.

Our Response – Limit the Reporting Granularity:
We responded to this issue by limiting the reporting granularity selector with daily, weekly, and monthly options based on the data available. Therefore if the user selected daily data only the purple 7 data points would be available as shown in the image below. The same would apply for weekly and monthly data.

We could play around with some visual elements to either ghost the remaining selections, to show the data’s availability but will not be displayed based on the reporting granularity selected. This corresponds to possibly large amounts of data not being available based on the user’s selection. We felt this was a very limiting experience, and not a viable option.

User Scenario 2:
The user selects a period from the middle of the first of the first week to the middle of the next week. There is a mix of daily and week data.

The Issue:
How does the application visualize data with different levels of data granularity?

Our Response – Normalization:
If the user selected a reporting granularity lower than what is included in the data set, the application will average, where applicable, to normalize the data for the block of less granular data.

The image below shows the normalization for the weekly data based on the selected range for by day reporting. A simplified view is available on the right. If the user selected to report by week, the values would be normalized across the entire reporting period and look like the red block of week data.

This would allow the user to see all data in all granularities over the entire reporting period. If we display the previous slider rule as mentioned in user scenario 1 with the normalization options outlined in user scenario 2, the image below displays all the reporting options with and without normalization, which we may allow the user to toggle on and off. The image below displays the possible options.

As a result some charting would require a good amount of normalization and mislead the user in their evaluation. If we refer back to the supporting image for user scenario 1, days 4 through 7 may not be an accurate representation of that period. We felt normalization is a transformation of data, and does not lend itself to good user experience.  We did not feel comfortable proceeding with this option, and dismissed it.

Final Solution and Lesson Learnt – Trade Flexibility for Data Integrity
We found that to deliver a consistent experience, we need to limit some of the options presented to the user. So much of the UI will be driven by the data, and that any amount of data could be available, at any granularity. The primary issue is not adjusting or implementing new user interactions, we needed to address the primary issue of “garbage in/garbage out”. We saw finally that by allowing the user to import inconsistent data, we were trying to control the user experience, rather than fix the root cause.

The Final Solution
We felt that an adjustment to the data import business rule would get the user in the right direction. We concluded by only allowing the user to import data in one granularity and for one calendar period at a time. This means the user has to find one granularity and stick to that. In addition, the user’s import would have to complete a calendar period. The sweet spot is probably a weekly import, but our user interview also points to monthly uploads being common place. By implementing this rule, we would certainly address all the issues listed above but at the price of flexibility and user experience. Sure our application would not be able to bend over backwards to allow all permutations of data and thus report that back out, but it would be consistent and deliver value.

Author Acknowledgments
I would like to acknowledge Gaurishankar Krishnanan and the SEO team for the time and effort during this exercise.

Build it and they will come? Build it and they will use it? How often do you go to a website and say I can’t figure out this thing or I can’t find what I need? Whether you are building a consumer or enterprise web application, you need it to be user friendly. In reality user friendliness is thought of as “pretty-ing it up”, something done after an application is already coded up. A wireframe or application skeleton gets thrown over to a graphic designer in hopes that they application will just work. However usability goes to the core of the product. It is how your users interact with your product.

The reason I love usability improvement is that often times a small change can have a tremendous impact on the bottom line. Often times, you do not even have to change the core features of your product to make something more usable. Something as trivial as color, size, position or verbage can often change and affect user behavior. As designers and developers of a product, we are often too close and too attached to what we make to see how something may not be obvious to an uninformed user.

“If only the user would do this.” “The user is doing it wrong.” “Why can’t they just see the button.” “It’s right in front of them.” These are the excuses we make to ourselves when first presented with the evidence that our product might not be all that user friendly. We write it off as the user’s fault. However the user is not at fault. Users are users. They will do what they do and you have no control over that. If users never read the directions and always start clicking around, then get rid of the directions and start offering in context help as they click around.

What happens when clients say I can’t afford usability design or research. I say you can’t afford not to have good usability on your website. What’s the point of having a nice looking website or application if people can’t figure it out and leave. The thing is, usability testing can be done on the cheap nowadays. If you have the stomach for it, just go to a coffee shop and ask people to try your software. You’ll be amazed and depressed to see all your design assumptions fall down like a house of straw. Very inexpensive software like Silverback lets you do usability testing on a budget. If you feel like outsourcing, check out UserTesting. You tell them what site to check out, pick out the number of testers, pick the demographics and they send you back a video file of the users screen as they go through your application, complete with a train of thought voice over from the user. Alternatively you can just try something like Amazon Mechanical Turk.

Taking a real world analogy, I often frequent this restaurant in downtown Chicago that has a great salad bar. The only problem is that they put the dressing in front of the actual salad. If you are in a line, you come to the salad bar and get your greens. Then you have to awkwardly ask the stranger behind you to move because you have to reach back to the dressing. I pointed this out to the manager that the flow of this was all wrong and it was a major inconvenience to his patrons. He looked at me as if I was some sort of crackhead telling him how to do his job. Now I like the place enough to come back, but this decision to place the salad dressing in front of the salad inconveniences all the patrons that go to the salad bar. People move forward and invariably all have to cut backwards in line. Now I’m sure many websites, including my own have problems very similar to these, but without usability studies or testing, we’d never uncover them. This is why I think Usability is important.

In June, I had the chance to speak at the annual meeting of the Usability Professionals’ Association in Baltimore. The topic was “The Brand vs. Usability Face-off.”

The premise of the presentation was that as companies extend their brands to the Web, they want to leverage brand elements that help make them successful in the offline world—and rightly so. But when we attempt to force traditional brand elements onto the structure, navigation, and function of a website, the user experience may suffer.

Conversely, brand can take a backseat to usability issues, and become diluted or even ignored.

Some of the tough questions that site owners have to tackle are:

·  Which traditional brand elements translate to the Web, and which do not?

·  Can a brand architecture work as an information architecture?

·  How do established brand elements and business practices need to adapt to work in this medium?

·  How do we distinguish ourselves from our competitors, even if we’re all trying to accomplish essentially the same thing online?

 The good news is that a site’s user experience design can be used strategically to enforce the brand—not just sit alongside it. Through the use of real-world examples (successful and not) my highly visual presentation looked at how companies can best communicate brand to the online audience.

The presentation was well-received by an audience of about 100 conference attendees. Included in that audience was Steve Krug, author of the landmark user experience book Don’t Make Me Think. Mr. Krug was even kind enough to come up after the presentation and offer some kind words.

Next up on my “world tour” will be a workshop on “Rich UX Documentation” at the Web 2.0 Expo in New York (www.web2expo.com).