Investment Firm: Picking Up Where Automation Failed
THE CLIENT'S INITIAL GOAL
To turn a limited, inefficient chatbot used by various teams to manage their details and automated workload into a user-friendly interface developed by Amazon Web Services (AWS).
WHAT MY RESEARCH REVEALED
The teams involved operated in silos, even though each played a crucial role in maintaining an effective, automated ecosystem. They needed a design that facilitated a shared understanding of connected, crucial data.
WHAT MY DESIGN ACCOMPLISHED
It introduced a streamlined, unified workflow that enabled efficient collaboration across all teams and stages of their automated workload. The clearer data structure laid a foundation for future automation.
MY ROLE
Lead UX/UI Designer
DURATION
Six months
DELIVERABLES
High-level wireframes to serve as a ‘proof of concept’
Disclaimer: Some artifacts, content, and wireframes have been modified or omitted to comply with client confidentiality agreements (NDAs). Further details can be shared in a confidential interview setting.
Chatting With the Bot
The immediate challenge was that there was little to no documentation for workflows supported by the chatbot. It had no defined script or associated training. I started by testing various scenarios and extracting the chatbot’s code as a way of documenting key points in the user journey and conducting a UX assessment.
Although this automated experience was a failure, the client still wanted to pursue several automated initiatives in the future. Having worked on several automation-driven experiences prior, I knew that the client did not just need better usability, but also more transparency and structured data to support future enhancements.
I learned that all tasks covered by the chatbot were tied to 'models', which the teams used to drive company initiatives, known as 'use cases' and 'projects'. A model's state and set up determined its success, something the chatbot did not account for.
Image is a high-level understanding of the hierarchy under the model umbrella.
The client did not have a true sense of the needs or routines of the teams prior to my involvement.
I facilitated those conversations and clearly documented their ‘jobs-to-be-done’ to get an initial sense of what was missing or could be simplified in the current workflow.
Models had to be made, approved/rejected, edited, and monitored to support the infrastructure. Model Developers created models based on project/task needs expressed by a division, subdivision, group, or team through an outside system.
Submitted models were approved or rejected by Model Governance. If rejected, they would either tweak the model or have the Model Developer do so. An approved model was monitored daily by Model Owners to ensure its efficacy.
Image shows high-level insights from my research period.
Cutting Through the Noise
This initial design pass would serve as a ‘proof-of-concept’ (POC) to secure funding for a larger system overhaul. To keep the client from hyper-focusing on minute details, I defined the key teams and routines that would demonstrate the most value for our POC. Model Governance, Model Developers, and Model Owners all needed some degree of visibility over owned projects, associated projects, and data permissions for all divisions, subdivisions, and teams:
-
Model Governance needed these details for all divisions, subdivisions, teams, and team members.
-
Model Developers needed these details for their division, subdivision, teams, and team members.
-
Model Owners needed these details for their team.
In the interest of time, the client trusted me to immediately create high-level wireframes based on what was defined above.
The biggest design challenge was making the necessary data digestible. I started with a more minimal, task-oriented approach, but user testing revealed their preference for “having all of the data right in front of [them] from the start.”
Image shows an overview of various screen versions that were tested.
Coming Back Stronger
My next iteration established stronger data categories, like ‘Team Details’, ‘Team Permissions’, and ‘Owned’ vs. ‘Associated’ projects as a way to break up the pages. This also gave me time to align terminology and cut out unnecessary data. I designed team-specific dashboards as the initial page for users to get a sense of ‘model health’ and quickly launch into their routines.
I oversaw the development of the final design. After a few weeks in the hands of actual users, the client was pleased to see:
-
The time for data gathering and task completion had reduced by over 30%.
-
That crucial data was easily accessible and digestible for additional subsystems within the model system.
-
The documented and implemented structured data provided actionable insights and supported future automation.
Wireframes show some of the final screens for Model Governance, Model Developers, and Model Owners.