Solution overview
Investigators working in the field of medicare fraud investigation need advanced AI tools to help them detect bad actors in a mountain of data. We added a major new toolset that had previously been holding 'Torch' back from a full launch.
Company21 CTYear2014Duration12 weeksRoleResearch, user stories, wireframes, prototypes, high-fidelity mock-ups, and testing with original team
Kickoff
(It starts with taking goods notes)
We started by speaking with users
I start projects in my journal. This involves taking detailed notes during meetings and user interviews. It also includes processing information by sketching, writing and more.
Over the years, my note-taking style has evolved. Since 2014, I’ve created a structured system of note-taking that helps my recall and aids in retrieving the info at a later date
* studies show that taking notes by hand improves recall and using a structure additionally helps.
Our user base presented some new challenges
The user base of Torch was unlike any I'd ever worked with. First, there were few users - probably 10-50 people would use the app in a given state (contracts for Torch were by state). Next, they had law enforcement backgrounds. While they were highly skilled investigations they were only average users of technology. We also learned that because of the large data sets and slow internet connections in the buildings where they worked, we had to be mindful of the speed of the system.
We documented the current state of the application
I felt a kinship with the investigators that we met. One of the exciting parts of user experience is taking an inherently chaotic reality and creating a framework around it, in the same way investigators find a narrative in a chaotic set of information.
When we started the project, Torch did have a way for users to save items they were working on - but it was not a visible process. Our goal was to keep the product functionally the same while adding the ability for users to flag various objects, and to be able to create new objects (like a file or an investigation) so they could save a collection of items that were all related.
We created a clickable prototype to test a new paradigm
After working on a new paradigm for saving files, I worked closely with the director of UX, and we developed a prototype that we could show to developers, stakeholders and end users.
We decided that saving should consist of making visible the system that was already in place for saving information. We made a few structural modifications and released a clickable prototype to test a hypothesis that users would be able to figure out the new system.
I narrated a video to help expand on the prototype
Making videos to help expand on mockups is a practice I’ve developed over the course of my career. I find that video is too powerful a medium to ignore – especially since details of an interaction design can be hard to capture in a clickable mockup alone, or in static documentation.
Videos can be viewed asynchronously, while still retaining their narrative and time-based power.
I created a style guide to give the developers a detailed reference for use during the sprint development cycle.
Working closely with the director of UX, we built a prototype we could show to developers, stakeholders and end users.
Column guidelines helped define common layout schemes for the application.
