Bank of America’s contact center agents use web softphone technology to interact with clients who call the toll-free hotline for support. A softphone is a piece of software that allows users to receive and place telephone calls over the internet via a computer or smartphone. It behaves like a traditional telephone but offers a wider range of features and can integrate with various platforms.
Customer service agents wear headsets that sync with the softphone on their computer and receive or place calls based on information that is sent to the softphone from other applications. The backend technologies can verify client information and send the call to receiving agents who are skilled to service specific queries. Global HR, Loan Servicing, Consumer and Small Business Client Services, and Collections departments are some of the lines of business that utilize softphone technology.
Bank of America’s contact centers utilize three different legacy web softphone applications across eighteen lines of business:
Each version has its own UI and backend mechanisms that are built into a DF framework and require separate management.
With the technical migration to a new container level, browser-based framework, there was an opportunity to simplify the desktop experience and consolidate all applications into one interface styled to the bank’s new design system.
Our task was to create one universal softphone application while ensuring no loss of existing functionality for any of the teams currently using it.
Web Softphone provides one flexible solution that is configurable to each user’s preference. Within the settings menu of the application, users can decide their preferred mode (light or dark), layout direction of the softphone (horizontal/vertical), and window configuration (docked to softphone or detached). This helps users customize the softphone to support their individual workflows. It also supports backend mapping for different roles and entitlements.
Under contract with Bank of America’s Enterprise XD team, I was assigned to the portfolio that supported Contact and Financial Center associates. I was brought into this project while it was still in a proof-of-concept phase and delivered design for the first three releases once funded. The first release took 4 months to handoff.
As the Experience Owner for this project, I oversaw UX strategy and delivered the visual design.
*Proprietary information is concealed and artwork has been modified per client NDA.
As I gathered information and started to map out the features for the universal version, I needed a better understanding of what a softphone is and how it operates. I conducted an industry leader study of top cloud-based softphone applications to gain more clarity on the assignment.
We did not have a budget or capacity for research. Therefore, I relied on historical documents and input from project stakeholders to gain a better understanding of project history, and to map the user flows for each respective softphone.
The product team had decided that the Integrated UUSP would serve as the template for the universal solution since it was the most recently developed and contained most of the features required by all three versions. Stakeholders were in the process of writing their requirements and UX was expected to work off of these specifications and start converting this UI to align with Helix, the bank's new design system. Helix had just started being implemented on the enterprise side of the business.
I requested product demos of all three softphones and wanted to understand the key differences between them. I created a features map to identify any overlapping features and gaps between each design. This project was driven by the tech team, so I wanted to make sure that we were addressing all of the business needs since we had to support eighteen lines of business.
Product demos revealed that the experiences and UI configurations between all three softphone versions varied greatly.
I learned that the Standalone version was the original softphone that everyone used until Synergy Web evolved. It ran on every desktop in the consumer space and still supports Global HR and Home Loans lines of business. The UI was very dated and looked like a throwback design from the late 90's.
The ML version also had an antiquated interface with misaligned UI components. It integrates with a workforce management system through an event call action and identifies keywords in the user’s profile that qualify them for the call. These skills are present on the softphone UI and have an indicator so that when a call comes in that matches a particular skill, it is displayed to the agent.
75% of the lines of business that use softphones were still using the Standalone and ML versions.
Standalone was the most different from the other two versions in terms of user flows and configuration and the ML version had additional requirements for what should appear on the UI based on user entitlements.
In our weekly working sessions, stakeholder engagement was low, and I wasn’t convinced that all business partners were 100% behind the Integrated UUSP as the final solution.
I wondered what impact the migration to the Integrated design would have on the workflow of users who were still using the other two versions.
Smaller, focused sessions with the lines of business helped me capture the user flows and gain a better understanding of how different user groups interact with the softphone. For example, Standalone users who work on the side of HR or loan servicing tend to place more outbound calls that last at least 20 minutes. They rely on the system to feed data into a collapsible window within the UI that they can move around their screens. The Standalone softphone is a vertical layout which makes it easy to scan information from top to bottom.
Integrated and ML softphone users tend to receive more inbound calls and keep their softphones pinned to the top or bottom of their screens. Agents have time restraints of 8 minutes to help resolve customer issues. When they transfer a call, a detached call transfer window opens and can be moved around their screen.
I also worked off the features roadmap to categorize features so that I could identify the information hierarchy for the phone interface.
As I learned how agents interacted with each softphone, I was concerned with the variation in configurations that users were adapting into their workflows and started to think about how we might make the application settings configurable.
If we empowered agents to customize the configurations of their softphone to workflow preference, it might help them adapt easier to a universal solution.
Three key patterns emerged:
With these observations, I identified the main architectural components for the web softphone:
I also captured the major red routes for our workflows:
With the Integrated UUSP version as my guide, I focused on nailing down the horizontal layout and then built out from there. I also wanted to ensure that the softphone features were grouped appropriately so that the information hierarchy made sense to the user and was easy to navigate.
Consolidating features in a hidden settings menu initially received some pushback from the business and tech partners.
I felt that some of the user settings like availability status and login, did not need to be on the front end and proposed a profile avatar with flyout menus for features that were less frequently used. Initially stakeholders thought this would create extra clicks for the agents, but warmed to the idea since this UI pattern aligned with common mental models. The stakeholders preferred an icon over an avatar because they felt the image would be too distracting and didn't see the value in it.
Tech partners required that the softphone version be on the front end so that they could grab key troubleshooting information when an employee submits a screenshot to report an issue through Synergy Web. Since the softphone application would be independent from Synergy, I felt that it should have it's own reporting mechanism and pitched the idea of creating a link in the Settings window that would automatically capture user information and submit it to tech. This idea was well received, but they still wanted the version number on the front end.
One of the struggles I initially had with this project was in implementing the new Helix design patterns into the interface.
Helix components are very flat and minimalistic but they also take up a larger footprint in the design.
For example, in Helix, we can use circular buttons with labels. This seemed like the obvious choice for the controls design, but increased the height of the softphone container and seemed clunky as additional features were added. The Integrated softphone was a 56px height which was too small, so I was conscientious of keeping the container height to a minimum.
I started thinking about how I might focus on the atoms of the design system, rather than the molecules, to simplify the UI.
Another concern was how the UI would stand out when juxtaposed with Synergy Web, the employee application that it would sync with. Agents work between multiple applications and can have 7-13 different apps open at the same time.
We were in the process of converting Synergy Web to the Helix design system and I felt that the two UI’s needed to be complimentary, yet have the ability to contrast one another since the phone could be moved anywhere within the screen.
The Integrated UUSP version of the softphone used color to help different controls stand out but color alone would not pass ADA requirements for accessiblilty.
This is where I decided to implement a dark mode option.
Dark mode is something that had been in development for Enterprise XD but it hadn’t been finalized or utilized in a project. I felt that the web softphone was a perfect use case for dark mode as it would help the softphone stand out and proposed that it be customizable for both the softphone and the window.
Once I figured out the interactions and had a solid UI, I created the vertical version, then focused on the window and modal layouts.
As I started going down the rabbit hole of configurable options, my design decisions started to transcend beyond basic positioning.
I had to think about the interactions between the softphone and the window and where to place their launch points.
For example, did it make sense to place the dock/detach icon on the softphone or should that live within the window? Should the window contain a button to minimize it out of view, or did we just want the user to only be able to close it by clicking on the "X?"
We also had to think about applying smart logic to the backend so that docked windows would slide out from the appropriate side of the softphone based on its position on the screen.
The configurable layout concept added scope to the project, but it appeared to be the best overall solution so the stakeholders supported it.
As we started building out the design, the development team started getting overwhelmed with the amount of configurations so we decided to focus on the detached layout for our first release. There were other variables impacting the project too as Synergy Web was moved to a new framework and we had to roll out the softphone through the interim stage of that initiative too.
This caused delays and I was concerned about misalignment between stakeholder groups so I raised awareness of the issue and did a gut check on what was feasible and when. As we talked through some of the technical roadblocks, the team realigned on how we would move forward in building out the remaining configurations.
At the time of this writing, the product is pending deployment of the second release and will go into pilot with a restricted number of users. We are working through the design of the third release which will incorporate the additional entitlement features required for the ML version.
So far, I succeeded in challenging the status quo within an environment with low UX maturity to try to ensure a good user experience for all parties.
Since it was a tech-driven initiative, I took the opportunity to think outside the box of just reskinning the most recent softphone version and ensured that we were designing a product that worked for everyone.
I was also involved in an adjacent project where we were redesigning the call transfer window and I knew that the two projects would eventually converge. By level-setting expectations and aligning two very large stakeholder groups, we were prepared for impact once we hit that point and able to align everyone to the new design direction.
I feel that I missed opportunities to get ahead of the design with research.
This project was a proof-of-concept for a year before it was funded and we theoretically had plenty of time to test my hypothesis regarding configurable layouts with users. However, it was really difficult to get stakeholders to collaborate on pre-work without an actual budget and timeline behind the project.
Although my contract with the bank has come to an end, my team will pick up where I left off and align with the business on creating a usability test plan.
