SaaS for Financial Services redesign
Oracle's Case Management
Role:
Product Designer
Important note
All confidential information has been removed in accordance with the NDA. I designed a new UI as a representation of my design process and as an opportunity to showcase my visual design skills.
Overview
Initial statement
Case Management is a SaaS Customer Experience product for Financial Services Industry. Finance agents execute an action plan in a chronological order but may dynamically change based on user’s decisions.
Team
It was initially led by a design team that couldn't continue due to a difference in time zones.
My direct team holds biweekly meetings to share our designs and give each other feedback, so I was able to iterate and validate my designs.
Weekly scrum meetings with the Project Manager and our Development Team. During the ongoing sprints, I helped solve any questions regarding the user experience. Meanwhile, I worked on designing interactions for the next use cases.
Constraints
Oracle is changing to a design-driven culture, but there has been a lot of resistance from PMs and Development Teams.
I inherited the project in the middle of an active sprint, so my research was very limited and had to rely mostly on the existing documentation.
I was working with Oracle's new design system, which was not fully completed and developers were not allowed to hardcode anything. I had to rely on the existing components available to us.
Product handoff
Current build
The current build was using an old design system. Flows were very complex by using up to 3 levels of nesting plus pop-ups. It was an opportunity to improve the architecture by prioritizing content and hierarchy.
Requirements
- Landing page for all cases.
- Overview case with progress details and next tasks.
- Page for documents, notes, team members and contacts.
- Action plan page with tasks.
Task flow
- Create a case type.
- Activate process for case type.
- Execute action plan.
- Complete and close the case.
Testing
The PM held user testing sessions with other product owners within the organization and business partners to iterate the current build. These where the most useful insights:
- The progress indicators were very helpful.
- It was very important to be able to select the case type.
- The action plan page was very unclear.
- Completing tasks was complicated.
Moving forward
In the first two months, I was assigned as the point of contact for UX and suggested minor improvements.
I thought it would be a great opportunity to boost my career at Oracle, so after discussing it with my manager, I took full ownership and officially became the Product Designer assigned to the project.
What problem were we trying to solve?
Make a complex and tedious process as seamless as possible to financial agents.
Possible solution
Simplify and focus on the main task flow which was executing tasks. It was important to prioritize content and restructure information architecture so that the user can complete tasks in a hassle-free way.
Understanding our users
Finance Service Agents
- Use only one monitor.
- Work on multiple cases at the same time.
- Measured by time spent on a case.
User goals
- Execute tasks in chronological order.
- Upload documents to support the case.
- Add notes, team members and contacts.
- Close the case.
Design Process
User story (deceased estate)
- The customer passes away.
- The beneficiary notifies the bank to transfer asset ownership.
- The agent gathers information and submits for the manager's approval.
- Tasks are completed and ownership transfer is completed.
Breaking down the current architecture
Case Overview
- Sections 1 and 2 present the same information but different visualization. They should not be disconnected.
- Sections 3 and 4 both show a list of tasks, they should be grouped together.
Action Plan
- Navigating through the action plan is very complex due to a 3 level nesting. The top-level is the active stage, second is the task and third, we see the actions required to complete the task.
Documents and Notes
The layout is very similar, there's no reason to be on separate tabs.
Team and Contacts
The layout is very similar, there's no reason to be on separate tabs.
Paper first
My goal was to determine how to group similar objects and define a layout.
Grid system
I used two grid systems, one for the parent layout and a second for the child container.
Main task flow
Lorem ipsum
Restructuring architecture and navigation
I designed low fidelity wireframes to start defining the architecture and navigation. I used different colors to represent behavior.
Overview (action required)
- The left panel shows a summary of relevant case details for all team members to be on the same track.
- Tasks are completed sequentially, so there is no reason to display a full list.
- A notification at the top will let the agent know there's a task that requires attention.
- Progress is shown for both, the overall case and the active stage to give the agent more context.
- The latest documents/notes and team/contacts can be easily accessed from this screen.
Completing a task
- Agents should not have to drill into the Action Plan to complete a task. I designed a right panel so agents can complete sequential tasks or save and close, without navigating to another screen.
Overview (no action required)
- This would be the ideal Overview page for every agent, no actions required.
Action Plan
- Tasks are no longer nested on so many levels.
- There is no need to view all completed actions and having to scroll. Completed stages will not be visible unless the agent decides to filter.
- Upcoming stages are visible as part of the next actions so agents are well informed.
Documents/Notes and Team/Contacts
- Documents and Notes were similar child objects so they were merged together in a single tab, same for Team and Contacts.
- Agent still has the ability to filter between each of the child objects.
First design iteration
Conclusion
Current situation
Unfortunately, this product didn´t align with our leadership´s goals for 2020, so the project was put on hold on the UX side, but the rest of the team continues to work on the first development iteration.
Learnings
Trying to get PMs and Dev teams onboard with the UX Design process may be very challenging, but once they start seeing the results, solid arguments of your decisions, and most importantly, a lot of patience, they might start getting more excited about it and an amazing collaboration synergy will take place.
I´ve come to the understanding that getting clients onboard as stakeholders to do qualitative research or shadowing, can be very hard to conduct in such a large organization with so many products and teams. We have to rely on raw data, which is not bad, but both would be better.
To overcome the limitations of a design system that was still work in progress, I had to lose the fear of reaching out to the right people in search of answers. I became really close to the components team in Mexico, and they helped me validate my designs.
My direct team and I felt really disconnected from other projects within the same organization and were having a hard time following patterns already set by other teams. My manager was able to include us into multiple weekly meetings that other teams were hosting, so we could view their work, but also share ours. Kudos to my manager!
In retrospective
I would´ve liked to spend time myself with real users, rather than just relying on PM's requirements. Although I don´t question their hard work, interacting with real users is an essential part of a User Experience Designer role.