Saturday 1/12/2008
Design

Progress

I’ve recently spent some time using Wesabe , during which one Andre Arko implemented one of my wishes (“archive” an account), and mentioned that he’d be working on the transaction view in the near future. Excellent. Transaction view is where I spend the most time in Wesabe, having not yet dug in to the social components. Here’s a picture of the core of transaction view:

What are you looking at?

At first glance, transaction view seems pretty straightforward, but there’s a lot of power hidden there. And “hidden” is part of the difficulty. For example, there’s no outward sign in the above image that I’m looking at the “unedited” view of this account, a filter which shows only transactions whose payee names have not been edited to be more human-readable. Right away we need some differentiation in the links at the top right that control filtering. And if I am looking at a filtered view of the account, which ostensibly would not show all of the transactions, a running balance is unnecessary. Removing it would also help distinguish the filtered views from the “all” view. Perhaps like so:

There are more polished ways to achieve this effect, of course.

It isn’t apparent from the images above that they use some ajaxy goodness to update the individual transactions, but fail to update the filtered transaction count that appears in the upper right. I didn’t realize this until I absently clicked on “untagged (15)” in another account and was told that there weren’t any untagged transactions. That mistake shouldn’t be so easy for the user to make; it is completely preventable.

The banks aren’t helping

The merchants and banks are making life tough for Wesabe users. In some cases the payee name as it appears fresh from the bank is cryptic; in others the name is merely an address or even less informative. You don’t have much to go on if you are trying to apply meaningful names to these merchants. There may be an opportunity here to reorganize data a bit to make it easier for the user to figure out who the merchant is, though. I started finding merchant names by Googling addresses, but found that if I scrolled down and found the same address, the amounts and dates (if they were recent enough) were useful clues. Perhaps merchants could have their transactions grouped? If I saw a merchant with a string of $7.35 transactions occurring every few days, I’d recognize my post-workout meals at Baja Fresh and be able to act accordingly. Here’s an example:

Granted, I couldn’t tell from these (oldish) transactions that the merchant was Target; I had to go to my records for that info. But as Wesabe gets more users, and as more merchant names are edited, the likelihood that Wesabe will have seen a particular merchant name before will rise. Wesabe could suggest the most popular option, and make it available as a nearby link. There’s no need to say “Originally: 9100020206 North…” right below a text field saying the same thing (which currently happens on every unedited transaction).

I took some other liberties with this grouped transaction:

• There’s no need to repeat $ on every dollar amount (but it is nice to have on totals or current balances), nor is there much call for a negative on every debit. Distinguishing the (far less frequent) deposits should be sufficient.
• I re-explained “Tags that stick every time” by naming the field and changing its alignment. Suggestions based on the suggested merchant name immediately follow.
• Since the primary goal of this altered view is to name the merchant, I did away with the transaction-level tagging.

I’m not completely sure that this is the right way to group transactions, but it is definitely worth studying.

You got your social in my financial

Edited and tagged transactions pick up some social flavor in the Wesabe interface. Here’s a sample of the current “all transactions” view, with my little top-right change to make it obvious:

There’s a lot of repetition in this tight little display of transactions. We’re not seeing our transactions in a purely columnar ledger format, but dates are repeated as if we were. Tags and social content based on those tags obtrude on each other. A little reorganization is in order:

There are a thousand ways to go about this. I opted to group transactions by date, reduce the number of labels, treat Fan/User/Captive differently, and give social content its own flavor. (I also notice that I have a Starbucks payee and a Starbucks Coffee payee. A way to edit the list of payees, allowing consolidation, would be great.)

Could be great

As Wesabe gathers more data and more users, they’ll have even more opportunity to expand ease-of-use. But there are plenty of opportunities immediately apparent to keep them busy in the meantime. I am excited about using this product as it grows and changes.