During the last half of my tenure at Vertafore I was the lead designer for the enterprise content management and workflow application called ImageRight. My final project for this team was to design a tool that utilizes optical character recognition (OCR) capabilities to capture information from forms that are scanned into a user's system, or that come in via an email receiver, and assign them to the appropriate workflow and team based on form type. Insurance agencies and carriers still receive enormous amounts of paper mail that need to be cataloged by a human. This tool, targeted to our larger customers, provides a streamlined flow for getting documents into the system and automatically assigned to appropriate workgroups and tasks, which is typically a manual process. The result was a deal with United Health, and it became a key selling point for this product. I also discovered my passion for designing productivity tools.
My role: User research, wireframes, interaction design, prototypes
Shown above is the first step in the process, which is to teach the software the form type, where the data is on the form, and to identify certain key fields such as name and address. Additionally, it allows for keywords to be indexed that can later be searched on, making content much easier to find.
GETTING STARTED - USER STORIES INFORM FLOWS
The first step was to sit down with the product manager and lead developer, our "team of three," to understand the basic requirements of the project and set scope. OCR tools like this exist, but our requirement was to integrate the output with our content management software. Therefore, understanding where those intersections are was key to understanding where this feature would add value. We began by recruiting a core group of our customers who were interested in this technology to be part of our design partner program. We interviewed them to understand where their current bottlenecks were in getting content into the system and assigned to workflows. Next, I researched competitive products to see what capabilities they had and identified areas where integration would cut down on manual processes.
With input from PM, I developed a set of user stories and requirements that I used to create flows and rough wireframes in order to start planning out initial interactions. We held several meetings with our design partners to validate our understanding and requirements, and took them through these initial interactions. With some solid feedback, I was able to more fully work out the interactions and develop an initial set of wireframes that my dev team was able to use to begin their work. We met regularly with our design partner group throughout this project, getting solid feedback we could incorporate and unearthing new points to consider.
A CHALLENGE - SELECTION STATES
Selection and focus states turned out to be one of my bigger decisions on this project. Users click the appropriate tool icon in order to draw a map over a field on the form in view. After drawing the map, should the tool remain selected or should focus move to the first required field to begin typing? Because most of our design partners hadn't ever used a form mapping tool, they were understandably unsure exactly how they would want to work. I spent time researching various programs with drawing tools, both desktop and online applications, to better understand what was common and what different interactions felt like in regards to keeping or losing selection. I also requested a variety of forms from our design partners and studied them to see what categories of fields would be mapped and what the density would be like. I discovered one case where there were 50 checkboxes, representing 50 states, all in one area. I thought it might be easier to just draw 50 maps, and then enter their corresponding parameters. However, cases like that were rare. It was more common to have different field types requiring different mapping tools, often spread out over multiple pages. In that case, forgetting to set parameters would be more likely, requiring error states and potentially tricky error handling.
I ultimately went with the decision I felt would be best for the majority use case - after drawing the map, selection moves to the first required field for data entry. I understood that our first year of feedback might steer us to different conclusions. And the 50 checkboxes? I convinced the team to implement multi-select and copy/paste functionality to make that as easy and quick as possible. After all, no one wants to draw the same thing 50 times.
THE IMPORTANCE OF USER FEEDBACK - ADDITIONAL FEATURES REQUIRED
While on a design partner call, I was showing an early version of how form mapping would work. One of our participants asked, "So what happens if Tom and I are working on this form at the same time?" Excellent question! Up until then, we'd been hearing that teams would be electing one individual to be the point person for mapping. Turns out this team was planning to designate 2-3 people for this task. We talked through some options, including merging changes, and ultimately decided it would be best to only allow one person to edit at a time. In order to make this happen, I added a step that requires the user to first put the form in edit mode, which then locks it so no one else can make changes. Additional customer input around editing also led us to design version tracking, which would be included in a later release.
THE OTHER CONSIDERATIONS
A feature this large has more components than can be easily covered in a case study. I show a selection above to illustrate the scope of this project.
1. Some forms had fields containing personally protected information (PPI), such as social security numbers or contact info. Not everyone at a company should be able to view all information on a form. Therefore, admins could designate PPI fields for encryption. Non-permissioned users would be able to view the form, but the encrypted info would be hidden.
2. Naturally, there were lots of places where things could go wrong for the user. I identified 15 error and warning scenarios at the outset and paid careful attention to the text I wrote so that it would help the user know what to do next.
3. Forms can be in the system but not yet ready to be in use. Therefore, I needed to design a way to make them "live" or "not live." I wrote some details to help my engineers understand the states.
4. I had already created a robust set of keyboard shortcuts for the app this functionality lives in. When the user enters this feature area, the keyboard shortcuts adjust to represent the actions power users can take while using this functionality. The end-users who will do the mapping will have hundreds of forms to teach the system, and I wanted to make it as fast and easy for them as possible.
Overall, this was a very detailed, multi-layered, and meaty feature to design - my favorite kind of work. It released in Q2 2018 (after my departure) and has been a key selling point, allowing Vertafore to secure deals with large companies such as United Healthcare.