Posts tagged interaction design
ATM Observations
Dec 22nd
I’m writing to share a couple of observations about ATM machines. As long as they’ve been part of our lives, it’s only in the last few years as a Bank of America customer that I’ve seen those products evolve. Today, I observed a truly revolutionary modification that saves two steps in every cash withdrawl:
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?
Internal systems
Aug 30th
One of the takeaways I’m finding in Bill Jensen’s book Simplicity is a reaction to the effect that information overload has on company productivity. As there is more and more information to process to do one’s job, it becomes ever more important for a company to provide tools that not only provide access to information, but which help interpret the information in the sense of analytics. So how does this manifest for a large company aiming to produce streamlined products for the marketplace, that will address (and solve well) a specific problem?
As a product manager with a multinational corporation, I find that (at least at my company in my specific division/subsidiary) there’s a contrast between the streamlined solutions we’re being asked to produce, and the cumbersome internal systems we use to collect and analyze the information we use to design such products. The systems we’re building are “push,” but the systems we use internally are “pull.” Some of this may be due to our company’s implementation of off-the-shelf requirements management and project management tools, but the net result is that the company does not make it easier to easily understand the decisions we need to make, much less make them.
I suspect we are not nearly the only ones.
One of the products I’m developing now is a service which can run client-server or on the web, in order to maximize the base of customers to whom we can provide a solution. I’m finding that questions about–and design of–the internal management components to be used by company support representatives are getting short-changed due to the pressure to meet release targets. This is certainly not unique to this one product, and the support angle hasn’t been ignored, but at the same time the support team’s “use cases” have not been considered with nearly as much diligence and interaction design as the product itself. So in one sense, the sub-optimal experience product managers have with requirements tools is being propagated to the experience support reps will have with service management.
Something I need to reiterate within my organization.