The entry of PIN number and selection of fast-cash amount were on the same screen.

In every previous interaction with an ATM, after inserting my card, I’ve been conditioned to (1) enter my PIN number, (2) click a button, (3) click a button for “Fast Cash,” and then (4) select an amount.  In today’s interaction, some significant experience design had been applied.  Though a single example does not demonstrate a pattern, I’d be willing to bet that my experience is not unusual: 99% of my transactions are fast-cash.  So today’s interaction was much much simpler: (1) enter PIN, (2) select fast-cash amount.  Choosing the fast-cash amount triggered the ATM to validate my PIN and dispense the cash.  That saved 2 steps, or 50% of the work required of the user.  Nice!

The only question I’m left with is: Why did this take until the year 2009?

Further, possibly because I was distracted by the unusually efficient interaction, I do not recall being forced to request a receipt.  In previous interactions I’ve been annoyed with BoA ATM machines that display a message “Retrieving preferences,” and then immediately ask if I want a receipt.  My receipt preference doesn’t change: I want one.  I realize the bank would prefer I do not, but their opinion is irrelevant.  If you’re going to store my preferences, and you insist upon asking me that question each time, the profile you’ve assembled is incomplete.  But as distracted as I was, I cannot swear that I did not have to answer that prompt: and believing I didn’t would be too impressive of an example of interaction redesign for me to handle.

How many more everyday interactions can be made dramatically better?

I’m currently running a large development project which is transitioning at the 2/3 mark from waterfall to agile.

Now that I have that out of the way, a little background.  The project was defined in terms of discrete requirements, originally tied together with a few key workflows and wireframes, and involves an n-tier architecture with a number of moving parts.  Though much of the underlying architecture was completed, we weren’t clear enough about the workflows and stories and the project was not producing tangible results fast enough.  So, while we recognize we should have started with agile, the company hadn’t adopted the agile methodology at inception.  To achieve our goal of better predictability and periodic peer review of the software, after it became possible in the corporate environment, we moved to agile.

Note that in the first half of the project, we erred on the side of providing requirements that stopped at the “what,” rather than providing the team enough about the “how.”  The move to agile has exposed that we weren’t providing enough context around each requirement (story) to enable the development team to build the product.  In this case, the complexity of the project and an unfortunate number of unknowns has made it useful for product management to collaborate with user experience well before presenting user stories to the development team, as advocated by others, rather than attempting to involve UX on an “as-needed” basis for each story.  In prior attempts to provide only the agile user story in “As a ___, I need ___ so ____” format, it quickly became apparent that the story wasn’t nearly enough.  We had to deliver the agile user story with the workflow steps (including interaction design) — only that seemed to eliminate enough uncertainty to proceed.

From a higher level, there’s another lesson here that operating under both paradigms has exposed.  It was quickly clear that for a complex system, providing the complete user stories and supporting material (including workflow steps, interaction design and wireframes) enables undesrstanding and fast action.   Though it was in some ways coincidental that we had wireframes before our sprints kicked off, it already appears to have sped things up significantly.

Hopefully the ramp-up will expand as we continue down this path, and we’ll reach the finish line quicker than we might have otherwise.