Fraud investigation app

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 weeksMy workResearch, user stories, wireframes, prototypes, high-fidelity mock-ups, and testing with original team

Problem

21CT was helping fraud investigators work to detect Medicare fraud.  The team had built an impressive system that used AI to find networks of bad actors. What was missing was a way for investigators to save progress in an investigation inside the system.

Brief

In the world of medical fraud investigation, there were many entities that could be saved. Individual providers, clinics, bank accounts and other objects were items that could be flagged for later retrieval. Entire networks, or parts of networks were also of interest to investigators. Investigations were also a ‘thing’ that investigators wanted to save.

All of the data inside the system was protected HIPAA data, which added an additional layer of consideration – not just for the design of the system, but also for being able to realistically prototype and run user tests that would yield useful insights.

Users

While the client was the state of Texas, our user base was comprised of investigators working to uncover fraud in the Medicare space.

Working in this space posed a few challenges

  • HIPAA data added privacy and legal concerns
  • Law enforcement officials were busy and could be difficult to access
  • The number of users was very small, less than 100 – forcing our usability tests to be qualitative in nature

Heuristics

  • Visibility of system status – Given the large datasets being searched, it was important to let users know when the system was thinking and what they could expect from a search or a save
  • Meet users where they are – The Medicare fraud space had a particular set of terminology
  • Help and documentation – Terminology needed precise definitions readily available to the investigative team
  • Recognition rather than recall – We wanted to lower the amount of information that investigators needed to keep in their head (or on separate notes outside of the system)
  • Aesthetic and minimalist design – We wanted to present information without noise to aid recall and understanding

Solution overview

Meet users where they are

One of the biggest challenges with Torch was mixing the existing terminology of fraud investigators with the introduction of new concepts. We wanted investigators to feel instantly familiar and comfortable. Feeling a sense of mastery would help them explore the deeper features of Torch.

Visibility of system status

We were cognizant that Torch was built on multiple layers of datasets. This meant that relevant information from compiled data needed to be surfaced. We had to balance visibility with noise in the system. Torch encouraged fast dives from all areas, including a user’s main dashabord.

Aesthetic and minimalist design

Working closely with users, we imagined a system that removed unnecessary information. With large datasets, progressive disclosure was key to helping investigators focus on the right information at the right time.

My process

Formation

  • Create a problem statement
  • Define the project scope
  • Gather the team
  • Understand the true goals of the project

Research + Definition

  • Speak to end users
  • Map the current state
  • Ideation sessions with users, stakeholders and contributors
  • Initial sketches and paper-style prototypes

Iterate and make

  • Validate initial prototypes with end users and stakeholders
  • Evaluate scope and goals taking into account learning
  • Adjust prototypes
  • Reviews with developers as direction solidifies

Launch

  • Design screens with dev specs
  • Create design system
  • Spend time in development environment
  • Design QA as developers complete work
  • Monitor metrics and adjust post launch

Where I started the process

(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.

Given the complex mapping of data sources, I spoke with data engineers and began mapping the information architecture, relating data to parts of the existing UI

I enjoy the challenge of a complex system – often it seems that engineers intuitively understand the system, but no one has taken the time to visually diagram the relationships between the various pieces. Making these diagrams help learn an intuitive knowledge of the system – and come in handy for talking to stakeholders

With some sketching and system diagrams complete, I used the Torch wireframe kit to jump into building a 30-screen clickable prototype

Working closely with the director of UX, we built a prototype we could show to developers, stakeholders and end users.

With interviews complete and a vision for the feature in hand, I used video to  communicate requirements to a remote team.

With any complex flow, it's important to ensure that the vision of the interaction design was well-communicated

I created a style guide to give the developers a detailed reference for use during the sprint development cycle.

Column guidelines helped define common layout schemes for the application.