About
Thoughtful provides Digital Workers (also known as bots) to mid-size customers in the Healthcare, HR, and Accounting industries to complete repetitive tasks such as paying insurance claims or HR new employee onboarding. We were creating a Digital Workforce Management tool to enable customer to run, schedule and see the output of their Digital Worker.
The goals of the platform was to give customers and a view of what was occurring behind the scenes and enable them to troubleshoot user entry related errors.
The problems
Only 30% of customers were using our platform. Most customers had the digital worker run their processes and would merely find out manually if there were any issues the following day.
100% of customers would call/email support with DW issues
Primary users were having difficulty convincing stakeholders to expand with us, despite their success with Thoughtful
The opportunity
How can we get more users to tackle issues on their own while demonstrating the value of the Digital Workers to close more business and increase expansion?
Project goals
To create a platfrom that enablse users to understand what their digital worker is doing and be empowered to self-service user related error. Long term, we’d be able to use this information to start to recognize patterns that our end users could to optimize their process and prevent common errors.
To get over 80% of customers using the platform
To enable users to help themselves alleviating pressure on the automation ops managers by 50% fewer inbound calls/emails
Where things started
When I first started they had automation engineers who both built and troubleshot the digital workers. For support issues, customers would talk to their dedicated CS manager, who would then document and share with the engineer. CS had no way of troubleshooting unless they tried to make sense of the code, which was not a scalable option
Here is what the system looked like when I joined:
Basic information about the digital worker along with some artifacts only useful to engineers
The log or report of the digital worker
Research
Talking to customers and internal employees
High touch customers, SMEs, and customer facing employees all echoed the sentiment that the product didn’t provide much value
Embedding Heap Analytics
Users were spending very little time on our platform and often coming to it when something failed only to realize they couldn’t troubleshoot
RPA research by UI Path
Existing research showed people were afraid of automation taking their jobs and a general lack on understanding
Mapping the customer journey
There were bottlenecks before users engaged with the platform and there was improvement needed in how Digital Workers were built
It was evident there was frustration during the process of design the digital workers for both customer and internal teams. Upon digging deeper, I learned that this was due do a lot of back and forth between our customers and our CS team and automation engineers, because engineering was not on any of the initial calls. Also a result of engineering brought in late, there were often issues with the digital worker that could have been prevented had an engineer helped with design. I also conducted a simple rose, thorn, bud exercise with CS to understand this better and lend a hand with a little design thinking.
I raised the areas of opportunity in the customer journey to leadership and worked with the head of CS and head of automation engineering to get engineers involved in design. 3 months after this change, there was a 20% reduction in tickets for new digital workers and a 30% shorter testing period.
Solutions to explore
Redesign UX+ UI
Create an easy to use tool that looks clean and simple
Generate a DW Work Report
Help users understand what exactly the Digital Worker did
Design principles
Create Transparency
Users can understand what the Digital Worker is actually doing
Build Trust
We want our users to feel like the Digital Workers are there to help
Empower Users
Users can spot when something didn’t go right and understand why
Design ideation
As we were rebuilding the tool, I was working on the design system. The one ask from leadership was to keep the elements from the branding gradient
Digital worker report inspiration
First iteration
Upon reviewing inspiration with product and engineering, we made a quick decision to start with simple nested tables given their ease and simplicity as our main goal was to capture feedback.
Feedback
“Wow I can actually see what the digital worker did! But wait, what about XYZ use case?”
What this meant: This design did not do a good job of accounting for scenarios where a digital worker was processing many of the same type of action like multiple insurance claims or onboarding many new employees. This design would leave large chunks of information nested with many child layers.
More research
Realizing this was more complex than I initially understood it to be, I took a step back and worked with CS and automation engineering to understand the type of digital workers we were building.
What this meant for the designs - two types of processes
In the current state we we were treating everything as it occurred and using time as marker to sort, which did not work with the users mental model. This approach often left a large listed that was difficult to parse for our customer, defeating the purpose of troubleshooting.
Back to the drawing board, I started to look at how else we could visualize the above groupings and used this information to work with engineering how the code would need to be altered to account for this.
Second iteration
Taking into account what I had learned, I distilled the designs into what I’ve come to learn is an ETL method of extracting (capture any necessary documents), transfer (process all relevant documents) and load (export documents with the addition of an initiation in order to have access to systems in a separate buckets for easier troubleshooting internally and externally.
Design system
With a new view of the work report, I worked closely with our front end engineer to define our design system. Give we were an early stage startup and had limited resources, I opted to customize MUI react component to match the styles.
Report processing
Testing
Input real data to Stress Test
Using the most data intensives of multiple digital workers
Qualitative think alouds
Using these insured usability
Feedback from high-touch customers
Pushed to production for 3 customers
Outcome
Increased customer platform usage from 30% to 50% in 4 months
Visual elements helped upsell 50% customers to expand
Once customers saw the information we could provide, 90% asked to have it sent to them
However the success did not lie in the platform alone, but rather the feature of sending notifications which would not have been possible without all this work.
Ultimately we needed to meet the user where they were at by recognizing we could have happy customers who were capable of self service without logging in.
Reflection
Building software from 0 to 1 while growing and shaping a design practice is hard. Like really hard.
Although when I started I believed we had establish product market fit and what we were trying to build was innovative and interesting, as I did my research I started to see that might not be the case. It’s difficult being in a position where the primary deliverable is a great solution but where the problem is not well understood. As a leader, I’ve learned this is why it’s important for design to be part of strategic conversations. We can often see things from a different yet equally important vantage point.
