Cisco Spark Care: Cloud-based work management software
Cisco Spark Care with Context Service is an application for contact center agents to quickly understand the context of a customer call by reviewing a timeline of their interaction history.
DATE
Fall 2017
ROLE
UX designer focusing on the timeline feature, collaborating with designers responsible for other parts of the application UI
COMPANY
Cisco Systems
EXECUTIVE SUMMARY
I expanded the Cisco Spark Care software to include a new case history and work order feature, saving support agents time.
-
I worked with a product team to deliver a new feature for B2B contact center software by designing, user testing, and breaking down the UI for an agile development team to build.
-
This feature would be used by several different user types and would appear differently for each of them.
-
Throughout this project, I collaborated closely with another designer that was focusing on another section of the same product UI to maintain consistency of the product experience.
NEW FEATURE REQUEST
Take an existing product, and enhance the features to meet user needs
My work on this project involved updating an existing UI to add a new feature requested by the business. In the original product, a user could chat with a customer in the center of the screen and view information about the interaction history on the right. To see those details they would first select an item from the list of historical interactions.
Selecting an interaction from the list to see details in the original UI
The business requirements I started from were:
-
Add the ability to group related interactions in this list and give them a case name so multiple team members could understand which interactions were related and to collaborate on resolving the issue.
-
Maintain visibility into the list of interactions while viewing the details of a single interaction or case, currently the list is hidden when a selection is made.
PROCESS: DISCOVERY RESEARCH
Understanding the different types of customer support agents
Early in this project, I found it challenging to get time with a user type such as contact center agents since their work is precisely timed and in demand. To quickly learn about all users in customer support roles, I leveraged internal stakeholders and subject matter experts by hosting contextual inquiries.
Building user personas
Since this project required a large number of stakeholders and team members, I established several personas to aid in the design and discussion of this new feature based on what I learned in my research. This also helped me to better understand how to build new features that benefitted each user type.
Mapping personas into a journey
The scenario I was designing a new feature for was complicated and required information transfers to several different user types. In order to get alignment and to ensure all the user needs were considered, I created a user journey with a story of a motorcycle being repaired to illustrate the scenario.
Journey map of personas working together to resolve a customer issue
PROCESS: WIREFRAME DESIGN
Initial iteration of the feature design
This is the first version of the designs I created for this feature. I worked only within this right panel as to not disrupt the work being done by other designers on the rest of the UI. I was also mindful about making major changes to the interaction flows since this product was currently being used and that would require training for users.
PROCESS: SYSTEM STATES
Automated task groupings and state control
Rather than having an agent create groups of interactions manually, my team wanted to have the system automatically create groups of related interactions. In order to achieve this, rules had to be set around when the system would automatically group together activities and when it would decide to start a new group based on the state of the group or support case.
I created these diagrams to explain when those requests would be considered closed and what the system would do with new interactions based on the states of the requests. These artifacts became references for the architects and development teams.
State change diagram for individual tasks and customer interactions
State change diagram for groups of tasks and customer interactions called requests
PROCESS: USER TESTING
Initial designs were tested with 5 support agents
I held a series of 60-minute video calls with support agents to test out my new designs. I printed pages of the UI and annotated the moments where insights occurred in the sessions.
Research findings
I compiled the findings using affinity diagramming to identify trends in responses as well as additional comments from users. I focused on the identified trends and used the feedback to improve the next iteration of the product.
From this research I learned:
-
Visual design improvements were needed to be for clarity of how to use the feature
-
Users wanted the timeline moved to the center of the screen since that is where the majority of their work was taking place.
-
This was a new concept for these users and some instruction would help orient them initially.
PROCESS: VISUAL DESIGN
Final product design delivered
This is the resulting visual design after making changes to the UI and applying the company brand style. The event timeline has been relocated on the page with the new grouping structure to make this flow better for an agent’s typical workflow.
Final UI design after changes from research findings
CONCLUSION
Key learnings
What was different about this work from all my other projects is that this product had already existed for a while before I began working on it, so I was coming into an architecture that had already been created for a product with a specific purpose.
Much of the work I was doing required changing the structure of the content which had a lot of dependencies and limitations. I spent a lot of time working closely with an architect and a product owner trying to find solutions between what was needed and what we could achieve given the existing architecture.
