Analytraxx

This design is a data visualization application. Essentially, for ever purchase, you type in the amount spet, and the phone will automatically record the current time and location. A map will be shown, together with the current time, to let the user know where the app thinks he is and what time it is. By clicking on the map, the the user can override the apps location-guess if it is incorrect, inaccurate or outdated.

Jaden navigates to this page whenever he makes a purchase


This is the initial landing page. The purpose of this page is for a user to enter his expenditure, for tracking.

In order for encourage compliance, the page is as simple as possible, with only one input for the user to key in the expenditure. This also helps increase efficiency by reducing as much as possible the friction involved in entering the expenditure.

The map itself serves to help both learnability and safety. Learnability because it tells the user that the current location is part of the record, and safety because it allows the user to correct the system i case the device’s location service is wrong, makng it difficult to inadvertently enter incorrect data.

He confirms that the map puts him where he thinks he is, types in the amount he spent, and presses “enter”. The app records his purchase details (amount/location/time) and exits.

Later on Jaden wants to go back over his previous spending. He does not have anything particular he is looking for, but simply wants to see what he can find out. He navigates immediately to the page showing his recent expenditures:


This page is a simple time-series graph showing how the users spending varies across time. On its own the data the graph presents is self-explanatory, and should not be confusing to a user.

The actions that a user can perform on the graph are also relatively simple: pinch to zoom will allow the user to see more or less of the graph, while the user can also drag the graph from side to side to view different sections.

These actions may be somewhat obscure, an may require some sort of new-user popup to tell the users how to manipulate the graph. Once the user has been shown, the actions should be intuitive enough to remember, and fast enough to aid efficiency. Safety is inherent since the user cannot do anything destructive on this page.

And he sees that three days ago, his expenditure spiked, likely because of the start of the weekend. Wondering if this is a recurring trend, Jaden goes on to view the aggregate weekly trends of his expenditure:


These weekly trends display aggregate data on the various days of the week aggregated over several weeks. Otherwise, the operation of this view, as well as its usability characteristics, is identical to that of the recent expenditures view.

And he sees that, in fact, he spends more than ¾ of his money on the friday-saturday-sunday that comprises the weekend. Now that’s a surprise! Perhaps Jaden will later want to consciously cut down on his weekend expenditure. However, he also wants more detail: exactly when is he spending his money? Is it on the Saturday night dinner parties? The Sunday afternoon shopping? He simply uses two-finger zoom on the graph and it adjusts to his new viewport:


Pinching and zooming on the graph does what you would expect: it resizes the graph according to the action, allowing the user to see more or less of it at one glance.

Clearly it’s Jaden’sdinner outings which are making up most of his spending, given the huge peaks on Satuday night and Sunday nights! Also suddenly apparent is the spending peak that happens every saturday night past midnight, obviously all the nightclubs that he has been going to have been a drain on his pocket!

With that information in mind, Jaden wants to know which clubs he is spending all his money in on saturday nights (he goes to several). He right pinches to zoom in on the time period he wants (12mn -> 6am Sunday morning) and selects the [Map] from the android menu. This brings up a map of his spending hotspots for that time period, with expenditure automatically consolidated based on physics proximity:


The map view is meant to display to the user the hot spots of his expenditure. Thus it displays a Google Map of the area which any transactions within a stipulated time period (generally the period that is visible on the time-series view from which the map view originated).

The size of the spot representing each cluster of expenditure represents the net expenditure at that location. Clicking on a spot will bring up the detailed history view for that location.

In terms of learnability, the size-represents-expense relationship should be relatively simple for users to understand, given that such visualizations are often seen elsewhere in infographics.

Efficiency is also maintained by the fact that the user can at a glance see qualitatively all the information he needs, and can easily drill down into more detail if necessary by tapping an inividual hotspot.

Clearly his major expenditure is at the Miracle of Science Bar, up near the MIT Museum. How much has he been spending, though, the last few times he went there? He taps on the large circle representing the spending concentrated at the Miracle of Science, which brings him to the location spending-history page:


The map at the top of the screen reminds a user and makes it explicitly clear what cluster of expenditure he is looking at, all without the user needing to specifically go through and categorize/name the various clusters. This improves both learnability and efficiency.

Which brings up a historical listing of all the spending Jaden has made in this position. Pretty handy!

Analysis

Overall, the learnability of this design is excellent. This is not because of special cues or metaphors that it is using, but is simply from using familiar metaphors (maps, time-series, dragging, zooming) in a new context. The purpose of this is to allow the user to

1. Efficiently record data on his expenditure
2. Efficiently view and visualize the data in interesting ways

And it succeeds on both these fronts. On the first point, having the application automatically fill in data on location and time based on its own internal sensors greatly streamlines the user experience, making it much faster to work with.

On the second point, being able to quickly navigate a whole flood of recorded data allows the user to slice and analyze the data in a variety of ways, which allows the to spot trends and draw conclusions far faster than they could by manually going through the data in excel, greatly increasing the efficiency of a users personal financial analytics.

Lastly, in terms of safety, the only thing that can go “wrong” is for a user to input incorrect data into the database, thus messing up all their time-series graphs and map views. However, the home view where the user enters expenditure data makes it abundantly clear what the user is entering, and prevents GPS screwups or time misconfigurations from polluting the database. The rest of the views are essentially immutable, not allowing the user to make any errors (or edit anything at all!) and are hence inherently safe.

The main usability downside of this design is the sparseness of the interface, which means that a first time user viewing the page will have absolutely no idea what options are available for him. Some views, e.g. the map view, he would have seen before and would be familiar with, but others e.g. the time-series view are entirely novel and hence unfamiliar. This is a tradeoff, as chrome would reduce the information content of the screen and hence reduce efficiency for long-time users. We would need to make a special effort in terms of NUX (New User Experience) to make sure that they can learn the various gestures and actions they will need to utilize the app to its full potential.

  • No labels