Please note: This is only available to Shelter Insurance employees and I can’t post the wireframes, design, or any documentation publicly.
I worked with the underwriting department at Shelter Insurance to complete a massive content migration from files in Word, PDF or Excel format stored in folders on a Windows Server to a content management system or Confluence.
Goal: To find the best application to host underwriting content then prioritize and organize content in an appealing and meaningful way for Underwriting employees.
Duration: The research aspect of this project took about a year and a half. Underwriting is a very large department and there were a lot of schedules and priorities to juggle.
Team: I worked with five Underwriting business analysts along with a committee of about 25 or 30 underwriting employees
My Role: UX Architect and Tech Consultant
Phases: This project consisted of two phases.
The first phase was helping underwriting to determine the best application to manage their content. I started with talking to the business analyst team about what they were hoping to achieve, why they were looking for a new solution, what their feature and functionality requests were, etc. I knew the most about Shelter’s customer facing website’s content management system (CMS) so I started off talking to them about the pros and cons of that CMS in comparison to their requirements. I then learned what the other options for hosting content were within the company and discovered there were four alternatives to the CMS I worked with. I set up demo meetings with the admins of each application to talk with the team of analysts. After the demos I created a spreadsheet of their requirements and marked off which applications met which requirements. This lead them to landing on two solutions to make up for weaknesses within each: A CMS paired with Confluence.
The second phase was the traditional UX research phase. This, of course, consisted of multiple steps.
First, I worked with the team of analysts to start in on a massive content audit. They put out the word to the department looking for volunteers to help with this. They ended up with a committee of about 25 to 30 people. I created multiple spreadsheets in Smartsheets with various columns for file name, location, and whether or not to Keep, Delete or Review. I then created a report to list the documents to keep, delete, or review. Once the audit was over, a few people went back and deleted the items marked for deletion and then the analysts reviewed the content that needed it and marked it to keep or delete. They got rid of over half their content – something like 25GB. It was awesome. I may have been even more excited about that than they were.
While the content audit was underway I created a survey for underwriting employees so I could learn about their frustrations with the current content storage system and also what worked about it.
I also started watching various underwriting employees. There are several roles within the underwriting department so I tried to watch at least one person in each role for half a day. I know watching more people for longer would have been better but I was working within the given limitations. I also recruited the front-end developer who would be building the site to observe as well so he could identify with the people he was building the site for a little more. This helped to build pretty good personas as well.
After this, the content audit had wrapped up (it took months) and I pulled in participants for card sorts. There was still a ton of content so I was working with representative content.
Once that was done and the sections and sub sections had been built I did a tree test study to make sure underwriting employees would be able to get to the information easily.
After the sections were established I started working with them on the design. I had them look at websites that they liked and explain why they liked them and then took the features that had the best justification and implemented them if they worked for their site. I created wireframes off of this and talked with the front-end developer throughout the process to get his feedback. I then demoed to the analyst team along with upper management to make sure everyone was happy with the direction of the site. After a few tweaks it was ready for testing. I pulled in a few underwriting employees to test the wireframe and after a few tweaks it was ready for development.
The front end developer started working on the project from there. I took on more of the project lead role at that time and kept in communication with the team of analysts while he worked. Asking them questions and getting clarification where we needed it.
Sadly, I ended up leaving Shelter before the site launched, but this was a fun project.