Secret to RDC Success #2 – Remove Barriers to Adoption Part 3 – Poor Usability

Few would argue that the iPhone was a revolutionary technology when it was introduced.  Much copied now, at the time, it was almost foolishly simple and I believe its powerful hold on users stems from Apple’s stringent adherence to the concept of “Simpler is Better”.   I wistfully think about the iPhone a lot when I have the chance to review Remote Deposit Capture systems.  Most of what I see is not good, lots of “busyness” on the screens, too many options and not optimized for how businesses do their work.  Generally I think that bad usability as it relates to RDC falls into two categories – 1) systems that have too many options available to the user and 2) systems that were not created as a tool for businesses – that is to say they are systems originally created for back office check processing at a financial institution and have been “repurposed” for use at a business.  Let me examine these two issues more closely.

RDC systems with too many options – This is an issue with any system and is not unique to RDC but since we are scanning checks and have a lot of other things going on (CAR/LAR, retrieving related information, IQA, etc.) it is very common for the user to not be able to easily do the one thing that is at the core of RDC – make a deposit.  While there may be a need to access additional information, my preference is to allow the user to click an “Expand” or “More Options” button to expand the UI to view this information.  Most items will scan without error and then retrieve any information that had been previously saved as a part of the same customer account, making all of this data available to the resulting ICL file(s) and optionally, an export file suitable for posting to the customers account receivable system.  When rejects need to be repaired, I should be able to select an option to do that; if I want to see the whole deposit in a scroll, I should be able to easily access that view, but why do all of these options need to be on the screen at the same time?

Could it be that programmers familiar with how back office check processing works at a bank designed the RDC system?  Here’s an idea: the next time you are in a process of selecting a new RDC vendor, ask that company if they have product managers with banking backgrounds and experience working with business customers when designing their systems or if the design is handled by programmers and technicians.  The former will create a system that is usable by your business customers.  I am not dissing programmers (I started my professional career as one!) but if you were going to build a house, would you want the framing or cement subcontractor to do the design or an architect?  This issue of usability matters and few vendors take the time or money to get it right.  But some do.  Find them and buy their systems.  Simpler is better ….

Most FIs never use the systems they deploy.  No bank uses RDC to make deposits so it never has a true customer experience with the product.  Take the time to get out and talk with your customers.  Go to their offices and run the deposit yourself using your product.  Was it easy and intuitive?  If not, get rid of it (I’m serious!) and get one that truly works according to how your customers do their work.  And while you are at it, make sure the system you get has an option to export data to the popular accounting systems like Quickbooks, Peachtree, and Great Plains.  I will expound more on this point in a future blog, but most banks forget that making a remote deposit is only half of the job for a business.  

Focus on making your customer’s experience with your online systems a delight and you will keep more of your customer’s long term.   If I could figure out how to make RDC a game akin to Farmville, with customers just as interested in using it, I would buy a sailboat and float the Caribbean, occasionally blogging on RDC from port to port.  Hey, it could happen!

I’m just saying …..