Cincom Eloquence is a B2B enterprise-level customer communications management (CCM) solution. It is used to design and deliver communications, either in bulk or on demand. Most of the customers are insurance and financial services orgs in the US and Europe. There are three main components of the application: Author, Administration, and Interactive.
Eloquence Administration
In the EA interface, technical users monitor and troubleshoot communication that was generated and sent through Eloquence. They also manage a repository of resources and configure channels for communication including Print, Email, Folders, and SMS.
My Role
Projects
Lead UX designer for the Eloquence product line.
I work on a team of 2-3 full-time UX designers and 1-2 interns. I collaborate with the Eloquence Product Manager, developers, and other stakeholders
I work on a team of 2-3 full-time UX designers and 1-2 interns. I collaborate with the Eloquence Product Manager, developers, and other stakeholders
Dashboard – designed, ready to implement
UI/UX redesign – in development
Import/Export workflow – implemented
Filter and toolbar enhancements – implemented
DASHBOARD CASE STUDY
Persona
Eloquence administrators are technical users responsible for monitoring communication that is generated and sent through the application. Every day, admins troubleshoot errors and handle technical requests from their users. They are also responsible for application configuration, which is managed less frequently.
Use Case
In Eloquence, our customers have highly complex channel configurations. For example: a billing letter is scheduled to be automatically mailed to thousands of home insurance policy-holders every month. Once each letter is populated with the policy-holder’s data, it goes to multiple channels:
1. The bill is sorted into a group by zip code and saved in a folder for the print vendor
2. A reminder email based on the printed bill is sent
3. Copies of the bill and email are saved to an archive folder
User Interviews
We conducted generative research including 60-minute open-ended interviews with 8 Eloquence administrators from 7 different companies. During our interviews, admins demonstrated how difficult it could be to navigate the interface and identify the source of an error, given the complexity of their configurations. It takes admins a long time to learn how to configure channels, and then peel back the layers of the onion to troubleshoot.
User Insights
1. 3/8 users said delivery channels can be difficult to configure because the workflow is unclear. 2/8 users had additional issues with configuring channels.
2. 7/8 users said it’s difficult to troubleshoot communication errors because the source may be buried in the navigation
3. 5/8 mentioned there’s no way to know if the system has thrown an error, unless you manually check or build a custom reporting and notification tool
Strategy
Given the user insights, UX and the product team prioritized these issues based on frequency, value, and feasibility. Addressing the second user insight would be very impactful:
FREQUENCY: admins check for errors daily
VALUE: If we could improve this experience, users could work much more efficiently, with less daily frustration
FEASIBILITY: extensive user research would be needed to ensure we understood the business needs of our diverse customers and present the information they want to see in an intuitive way. For engineering, it would be a significant effort but highly feasible.
We decided this is a very high impact, high priority problem to solve. The third user insight could be added later - robust alerts and reporting would also be valuable.
Problem Statement
How might we improve error management for Eloquence admins?
UX Analysis
On conducting an in-depth usability review of EAC, it became apparent how complex the application is. The way in which delivery channels are built in the app gives users flexibility but can be cumbersome.
Something else that was painfully obvious: data tables in EAC lacked basic functionality, like search, sort, filter, sticky lists… By implementing best practices, I guessed we could quickly improve the experience.
On reviewing the research and ideating with product management and Services, we felt if we could surface errors rather than requiring users to drill down in the navigation to locate errors, it would be more efficient. Several of our customers built custom dashboards to not only surface errors but monitor other operational metrics. We didn’t have any built-in dashboard functionality, but it was technically very feasible.
User Interviews Pt 2
In our second round of interviews, we talked to 2 customers with very high production volume who built custom dashboard/reporting tools. We also followed up with 5 of the admins we’d spoken with previously, and 1 member of our Services team who built custom reports for a customer. Our goal for this round of interviews was to understand what production metrics admins track, and how they measure success in the application. With the insights we gained, we were ready to design the first iteration of the dashboard.
Dashboard Design – Iterations
Display valuable production metrics on a customizable, interactive dashboard
Co-design with users
Once the initial design was complete, we conducted co-design sessions with 5 admins. With this round of research, our goal was to understand what widgets would be most valuable to users and get their reaction to the design. During the interviews, users completed a card sorting activity to articulate what would be most and least valuable on their dashboard. Then, they interacted with a prototype of the dashboard.
Insights
The card sort helped us determine what would be most valuable to the most people across organizations. We performed it first during the interviews, so we didn’t lead users’ answers with the prototype.
From these interviews, we compiled a list of the most valuable metrics to include in the dashboard. Some users asked for additional dashboard functionality as well, like the ability to set thresholds and save different dashboards.
Usability Testing
We wanted to know if our design was easily navigable and understood. With UserTesting, we designed an un-moderated task-based study and tested with 5 users who matched our target persona.
What we wanted to find out:
- Do users understand that the filters at the top control all widgets?
- Does the threshold workflow match users’ mental model?
- Can users figure out how to find details about errors?
Findings
Our 5 testers completed 7/10 tasks satisfactorily. They understood how filters applied to the widgets and were able to perform simple tasks with the dashboard. They struggled to set thresholds and drill down into errors. Based on users’ comments and interactions, the changes we needed to make were clear.
Wrap-up
After iterating on the dashboard design again, we presented it to Eloquence stakeholders for final feedback. Engineering selected an open source tool and laid the groundwork on the backend. Our design is fully researched and ready to develop.
Challenges
When we first considered adding a dashboard, I wanted to avoid doing it just to check a box. Dashboards I’ve used in the past look pretty, but don’t really add value. So we were careful and thorough with our research. With our wide variety of customers and business needs, the more customizable the dashboard could be, the better. But in the first release of the dashboard, we stopped short of full customizability – allowing users to build pivot-table style charts and graphs, for example. Some of our customers would appreciate that functionality, but we found that most were interested in basic metrics we could provide out of the box. Again, our strategy was to take it slow, enable analytics on the first release of the dashboard, and continue research and design for the second release.
