FINEOS is a Platform for our customers; Insurance Carriers to service employers. This feature is related to correspondence sent out to claimants, for example an email or letter to approve an insurance claim. They use a third party system for managing correspondence templates with data generated by FINEOS. But there was quite a bit of manual work involved to customize templates per employer, and also in managing recipients and channels (Email, Letter, SMS)
- Competitive analysis, User Interviews, Stakeholder Interviews
- Journey Maps, Whiteboarding
- Wireframes, Prototyping
- Low and High Fidelity
Fineos is a platform that Insurance Carriers (our customers) use to manage Health Insurance and Medical Leave for their customers (hundreds of different employers).
This involves the management of a lot of different correspondence for example a medical claim approval letter or a leave approval email.
Here on the right is one of the scenarios we worked with. Alice Moore works for the Great Cookie Company. She had requested medical leave for an operation, that was postponed because of Covid. And she has requested to cancel the leave.
Ruth is the HR representative for the Great Cookie Company. When she cancels the leave request in the Fineos system, Alice will get an email to confirm the cancelation.
The insurance carrier uses a third party system to manage the templates that produce these pieces of correspondence (email, letter, or sms). And they pull data from our system using various variables and if statements. This is an example of a Cancellation Template. It also contains some static text.
And this is the rendered version of this piece of correspondence.
One of the main PROBLEMS is that this template is used by hundreds of different employers and sometimes they want to add extra pieces of content specific to their preferences, which also sometimes varies by state and/or varies by the department that the employee is a member of (e.g. C-suite, Adminstrative, Restaurant workers ).
Currently the only way to add that extra content is to have different templates for every employer, which is very inefficient to manage, create or update templates. There are about 50 different basic templates.
The carriers also have to manually add extra recipients. In this scenario, Ruth wants to be CC’d.
And they also have to manage channels manually (Email, Letter or SMS.)
- Creating and updating templates per employer is too time consuming. We need a way to create, store, edit and content (text, images, attachments). And a way for our templates to call that content depending on employer, location, and event.
- Manually forwarding emails to extra recipients is too time consuming. Need to automate.
- Managing channel preferences (email, letter, SMS) is currently too manual and also very time consuming
- Build a mini content management system for text, images and attachments with subsections: general, location & event
- A feature to add extra recipients at an employer level, location based, or event based. (e.g. CC hr on absence requests)
- Add channel preferences for main recipient and extra recipients
We have a number of personas already created. The Client Setup person who will mostly be working with templates. But this task is not a full time role. And is sometimes carried out by other people. So although we kept this persona in mind, we also created a persona that we called the Template Manager. And that is who we created a User Journey for….
We used a User Journey Map to capture the key steps, goals, needs, and pain points of the Template Manager. And considered some outcomes and opportunities. Although it’s very light on content it was very useful.
We went through this in a workshop and got a lot of very useful feedback. We had made a few incorrect assumptions. This is one of the artefacts that I would work on a lot with the product owner.
My mini whiteboard is my favorite UX Design tool. It’s by far the quickest way to sketch out ideas whether wireframes, flows, or wireflows before going to a screen.
This is a rough outline of the pages and navigation using tabs and a sidebar. It pretty much stayed like except some pages were dropped.
I always go as far as possible with low-fidelity prototypes for as long as possible. I increase the complexity and detail of the interactions through iterations. And hold out on high fidelity for as long as possible.
I reviewed the first few iterations with internal stakeholders (Project Manager, Product Owner, Architect and Engineer). And then we had bi-weekly feedback sessions with our customers and kept tweaking until we got closer to the solution. With a complex product like Fineos, this iterative process is necessary before getting ready for user testing.
It was only after several feedback sessions that we felt confident to progress to user testing. In the context of this project that meant sharing the prototype with stakeholders and customers with the request for them to go through the prototype in their own time with real world scenarios in mind. They were guided by several prompts about various and checklists.
What did we learn from our users?
- We learned that we didn’t need a section for paragraphs and keywords, we just needed a single Text Content section.
- In initial designs, extra recipients were only added manually but after a few iterations we realised it would be easier to leverage groups that are already in the system
- We realised that we had to segment recipients by member group OR structure group, not both. We added this option to the initial set up screen.
- Between the architect and our customers, that adding an option to always include the manager was a requirement and also easy to achieve.
- Many other details
- Iterations are quicker in low fidelity
- I can focus on one job at a time: interaction design, then visual design much later
- User feedback is focused on interactions and problem solving
- People aren't afraid to give feedback on an ugly design
High Fidelity Prototypes
I didn’t move onto the high fidelity stage until everyone was happy with all the interactions, user flow, usability and buildability. After this phase we had a final round of user testing by letting stakeholders and go through the prototype on their own and kick the tires. There weren’t many actual changes here, just a lot of finetuning.
- Polished pixel perfect visuals
- Adding final interactions
- Full alignment with design system
- Populating tooltips and micro content
At this stage I also incorporated some Scenarios into the prototype. This was very useful and it actually produced a missed requirement. (Channel settings for the main recipient based on location). But a big lesson learned on this feature is that this was not the place to flesh out user scenarios. It’s too time consuming to add to high-fidelity prototypes. Much better to do earlier with wire flows at an earlier stage.
Note: fullscreen option on top right
The image below is from an internal press release for this feature where we attempted to measure success. In general there was a vast reduction in the templates necessary to carry out the same task, which removed a lot of laborious repetitive work. Time spent on template management was also greatly reduced. So we removed some frustrating pain points and freed up a lot of time for one user.
What challenges did we have?
The customers working on this were incredibly busy and didn’t always have time to get back to us with some resources. We really needed to see some real world content and scenarios. There were a few user requirements that weren’t fully clear until we got these resources. And had to push hard for this. This is the reality of UX sometimes. When we finally got these resources we had much better clarity and were able to finalise the requirements and solution before moving onto high fidelity.
- 80% Less effort to configure large groups of templates
- 75% Less templates needed to complete the same tasks
- 80% Less effort to configure templates
- Smooth build phases