I worked on this app as a proof of concept while studying UX at General Assembly ATL in 2015. My original concept was to redesign a mobile banking application, but I quickly realized that there was a disparity among my interviewees when it came to the problems they had with mobile banking. Many issues were systemic of banking as a whole, and could not be resolved by a simple app redesign.
Instead, I shifted gears to address a pain point that I heard in all of my interviews; being on hold. Everyone I talked to cited it as something they hated, so I directed my efforts on lessening that strain and/or eliminating the need to be on hold entirely.
Problem Statement: People hate talking to their banks
Being On Hold
Specifically unknown or very long hold times. Interviewees cited not knowing how long their call would take as a primary reason not to call.
As outsourcing increases, so does the chance that you will have a conversation with someone who is not a native speaker of your language. Add on the issue that a non-digital signal can cause poor sound quality, and you're asking for user confusion.
Outdated methods of communication
I interviewed a few millennials who stated that they'd prefer texting based methods of communication over voice. With banking, though, sensitive and numerical information does not lend itself well to mediums such as twitter or texting.
A Visual IVR (Interactive Voice Responce)
Whenever you call into a contact center, your call is routed through an IVR. It's the "Press #1 for english" system. My proposed solution was not to supplant the current systems that are in place in contact centers, but to give the users better control over it though a visual instead of auditory interface.
Visibility of hold time and support information
The only information that current systems expose while a user on hold is (sometimes) the estimated wait time. My solution would be just to show the user that information. Expose how long the hold will be, and when it is known, show the user who they'll be talking to.
A way for the user to get off of hold. There are systems that do this today, but all of those, again, are accessed through an auditory interface.
Hold Music Control
This one was one of the most well-liked features by those that I've shown the app to. It's just the ability for the user to choose their own hold music. I speculated that music streaming services like Spotify would offer up a select few stations for the user to listen to, being paid for by the company that housed the support call. Based off of the feedback that I heard, people must really hate hold music.
I conducted around 8 interviews to create these personas. Not an exhaustive study, I know, but with limited time and a $0 budget, one must do what one can. They did all cite being on hold as a pain point which caused me to switch directions completely. I wasn't able to do any prototype validation with these users, and would have liked to interview a new group with more specificity about the being on hold problem, but my time limitations didn't allow for it.
I do the majority of my sketching on whiteboards. Luckily, General Assembly has rooms filled with them and an endless supply of dry-erase markers. I was attempting here to identify a user flow, which was eventually trimmed down to it's bare necessities; identifying the components of a dialer application that could be used for my interfaces; and trying to limit how many interactions would be necessary for the user to initiate a support call.
I wanted the UI to appear like a vertical timeline of events. At first I tried to show too much information, but these sketches helped me to determine the appropriate hierarchy and embrace a card layout for clear separation of different elements.
I really wanted the immediate purpose of this app to be obvious, which is why I emulated a dialer as much as possible. Every key would show the action that the IVR would offer, and allow the user to not have to wait for them to be read aloud. Only after interacting with the keypad would the application show new controls, but if the user wanted to, they could interact with it exactly as they would a traditional call.
These mockups show a progression of the app. The first screens look like a normal dialer pad, with just some small changes, and the following screens show what it looks like when the user is on hold, with music control, estimated wait time, information about who will be helping them, and even some details about the customer support tech's hobbies in an attempt to find commonality or make the person seem more, well, human.
I feel that this app has a potential, but knowing what I know about the contact center industry, it would be a very difficult product to get into production. I believe that if implemented properly, it would enhance customer experiences, but would need more user testing and validation to see if some of my hypothesis are correct. Because this was a proof-of-concept, I had to rely too much on my own experiences and large parts of the app would most likely change with exposure to actual use.