One of my first projects at Zions was the software branch tellers use to conduct their day to day transactions. Around eighty percent of the BaNCS application use comes from these teller transactions. As such, a well designed and thouroughly tested teller application will have the highest benefit to the bank's effeciency as a whole.

The BaNCS application did not come with a Teller module, so this part of the project was starting from the ground floor. Initial discussions with the Teller stakeholders discovered that the number one metric monitored in a teller transaction is accuracy followed closely by time to complete.

The Teller module is integral to the success of the BaNCS application. If tellers are slowed by even twenty seconds per transaction, it will erode the user's acceptance of the new software. Understanding the user and their perceived pain points was the first step in delivering an improved teller experience.

I heard a quote years ago that was "If I had an hour to solve a problem, I would spend fifty minutes defining the problem and ten minutes solving it." I believe this philosophy holds true for product design as well. If you don't truly understand the problem, you have little chance of finding a solution.

In order to truly empathise with the tellers, I needed to understand their current workflow, pain points, and daily activities. Luckily, our users are all employees and the bank keeps a vast amount of data regarding their branch applications. I also had easy access to tellers and their current branch application. Sending out surveys and questionnaires yeilded a good amount of user data, but actually observing tellers in action yeilded some surprising insights.

I started noticing that data from the surveys and questionnaires didn't fully line up with what I saw when observing the users in action. The users had built work-arounds into their daily workflow and forgot that these were indeed work-arounds. Most of these small pain points were forgotten when answering questions and were only discovered by observing the user. These small forgotten pain points add up to an unpleasant user experience that is hard to pinpoint without direct observation.

Once I answered all of my questions, I had enough data to refine those questions and get more specific in my research.

Using the refined solutions from the brainstorming sessions, I created multiple low fidelity wireframes. Utilizing A/B Testing, click tests, and various other methodologies, the designs were sent to users and stakeholders for testing. The designs were iterated upon until the they felt solid or I ran out of time.

It was now time to create a functional prototype to find any remaining pain points in the design. These tests were structured as five to ten minute unmoderated studies. These studies were then sent out to various tellers in the bank. Any assumptions made during the design phase were validated during this process. Each element of the prototype now had data to back up the design decisions.

At the end of each sprint, the prototypes were used to create a Functional Specification detailing the layout and functionality of the screen. These FS documents were then sent offshore for development. During the development process, multiple meetings were held with the developers and stakeholders to ensure a shared understanding of the solution provided.

Once the completed code was delivered, it was time for a review. Although the code had been thouroughly tested by the QA department, I still like to run through some testing of my own to make sure each aspect of the design was properly understoon and delivered.

Any small UI issues were quickly remedied and larger issues were discussed and categorized by severity. These issues were then added to the developer's backlog and delivered in future code drops.

Branch tellers, stakeholders, and Product Owners were then brought in to review the live solution. Most of the time we had reviewed and iterated through the designs enough that these were quick and easy. There were a few occations where the design wasn't fully understood by one or more parties and required further explanation or revision. These instances were generally small and happened less and less as the project went on.

This part of the project was extremely challenging and rewarding. My initial assessment of the project left me a bit shaken by the scope and importance. In the end, however, it ended up being a major confidence boost that helped me through a few of the more difficult modules that followed.

This project is not only consolidating multiple different applications, it is also consolidating multiple different affiliates under the Zions Bancorporation umbrella. Each of these have their own goals and pain points. They also have vastly different opinions on the design direction for the teller application. Creating a solution that not only appeased them but also made them happy with the upgrade was quite a challenge.

In the end, we created a teller application that requires much less training for the user. This reduction in training was a major win as the turnaround for branch tellers is quite high. The new teller application is also easier to use than the current state and the time to complete a transaction dropped by an average of two minutes.