Lessons Learned

Not long ago we built an enhancement for our web site. This is the story of a lesson learned.

The site we build is used by financial advisors to help view client accounts, perform maintenance on those accounts and link to information that would help them service or sell more accounts. These accounts consist primarily of mutual fund or brokerage accounts. The data comes from a third party we have contracted with to provide that data.

The enhancement we were building would let them deal with a couple of very specific issues with the account data. Simply put, we have accounts in the system that may have a zero balance, these are what we call No Position accounts. We also may receive from our data provider duplicate or erroneous accounts.

We wrote the requirements for a tool that would let the users assign accounts that were “No Position” with a No Position flag. The advantage of this would be that they would not see “No Position” and “Regular”accounts (accounts with a balance) mixed in together when looking at aggregates of accounts. They could still view them if the chose, for example if they were expecting their client to fund (add Positions to) that account. Those erroneous or duplicate accounts I mentioned earlier, would only be flagged as such (what we’re calling “Suppressed” ) by the back office.

Belatedly, (read: better late than never) we asked the users how they would prefer this tool to work, that they be in control of changing the status of the accounts or that we change the status for them automatically. (For example if an accounts balance falls to zero it would automatically change its state.) Surprisingly, to me anyways, they said we should make the status changes automatically.

The first lesson learned; users don’t necessarily want to be in total control of their data. As a person with an IT background, I found this eye-opening. After thinking about it, it makes perfect sense. They aren’t IT people, they’re salespeople. They want to use the tool to help them in their sales efforts. They don’t want to waste their time, time away from selling or servicing their clients, to manage their data. They don’t get paid for that activity, so why should they bother. Know you’re users.

We went ahead and set the system up to automatically make the changes for them. However, we left in the ability for them to make changes themselves. Seems like a good a idea letting them have the best of both worlds, but if they change the state of an account, (for example they know a zero balance/No Position account will soon have money deposited to it so they change it to an Active state) the system will override that change on the nightly refresh and change it back to what it was.

Remember earlier I said belatedly we asked the users. That also means it is too late to make any major changes, like recoding the refresh so it knows when a user has made or change, or taking away that ability altogether. We did the usability work too late in the software development process to have it shape the final tool. We’re stuck, at least for now.

Second lesson learned; persuade, argue, cajole, convince, negotiate, whatever it takes, to get usability testing into the software development lifecycle early.

Third lesson; when you have gotten that feedback, revisit the business requirements to make sure they still make sense based upon the feedback you received.