Axon Records

Axon Records is a cloud-based records management system for law enforcement agencies. It offers a unified platform for an agency’s daily record-keeping, including incident reporting, investigations, property & evidence management, and more.

Company
Axon
Industry
Public safety
Involvement
2018–present
Design team
3–5 people

Save time, save lives

If I ask you to think of a police officer, what would you picture? I’d guess possibly someone in uniform, either on the streets or in a patrol car — but probably not someone sitting in a room in front of a computer.

Yet officers today regularly spend a quarter to a third of their shift doing precisely that: typing reports into a computer. The work is necessary but tedious, inefficient, and just not what they enjoy doing — you see, even we imagined them somewhere else.

That’s the mission of Axon Records: saving hours, reducing cost, and giving officers their time back to serve the community and protect lives.

My role on the team

My focus for this project is on the incident reporting experience, which includes:

Report forms. I designed the incident report and all its forms, including offenses, people, vehicles, property, etc. Additionally, I’ve documented my philosophy and recommendations in the Report Form Design Guidelines to help others build new forms.
Report UI. I worked on the user interface for the report composition & review experience. I’ve also been iterating the design to support new features (such as collaboration) and improve existing ones (such as narrative composition).
NIBRS support. I led the effort from the design side of making our system NIBRS-compliant and helped launch NIBRS support successfully before the FBI’s December 31, 2020 deadline.

Besides feature work, I’ve been hosting our weekly design critique sessions and contributing to the Axon Design System. I’m also leading the review and revision of our design principles.

Incident report

When officers respond to an incident, they often need to note down what happened, who they talked to, and what they did. The document they use to capture all these is the incident report.

As an officer would tell you, this report is not unlike a third-grade writing assignment: describe where, when, who, what, and how in a factual, accurate, and concise way. Creative storytelling is not a goal here.

In addition to the story, known as the narrative, the officer also needs to document details about each involved person, vehicle, property, etc. This documentation usually comes in the shape of forms — paper in the past, digital nowadays.

Assorted examples of paper report forms.

How do we help officers fill out the report faster?

One issue that slows the officers down is repetition: filling out the same information multiple times. It’s tedious and error-prone.

The repetition was a common problem among paper reports. Since most incidents are simple crimes — one victim, one suspect, one offense — the base report needs to be concise, usually a single sheet of paper. The side effect of this design is that every other activity requires an addendum:

an arrest form for documenting an arrest;
a domestic violence form for reporting domestic violence;
a tow form for towing a vehicle.

And so on. Because each of these forms enables a downstream workflow, they must also contain the necessary information to stand alone — which causes the repetition. For example:

the arrest form repeats the suspect (who is now the arrestee);
the domestic violence form repeats the victim and the suspect;
the tow form repeats the vehicle and its owner (which could be the victim, the suspect, or someone else involved).

All these practical limitations of paper forms should disappear when users switch to digital. However, some records management systems merely digitized the paper, and in doing so, they inherited the problem with them.

To solve this, we need to rethink how we organize the information on the incident report. Instead of scattering information across multiple “forms,” we can use the essential, unique elements of an incident — people, vehicles, property, etc. — to organize the rest.

For example, rather than adding arrest, domestic violence, and DUI forms to the report, we can start from the element that connects all of these — the person — and add the additional details. There’s no need to repeat the person’s information because they all stem from the same root.

Additional sections added on a person’s documentation.

For the elements themselves, we can let the user dynamically add them to the report as needed. Gone are the limitations imposed by the static prints. Now the user can start with a small set and keep it short for most incidents, but quickly and easily expand when the situation calls for it.

Finally, we designed and implemented the forms following industry standards & best practices to increase efficiency, reduce errors, and maintain accessibility.

1

Nailing the basics: labels above inputs; only ask for necessary information, when needed; ample touch target size; never use color alone to communicate meaning (e.g. statuses, errors).

2

Autofill where it’s appropriate. It saves time and reduces errors. When we have the data from another source (e.g. the dispatch system), and prefilling the data won’t create bias, we offer the user a headstart with autofill.

3

Reuse with ease. When it’s not appropriate to autofill, we offer an easy way to reuse previously entered information.

For example, if the user entered a person’s home address, we’ll display it as a suggestion when the user needs to enter an address again — this makes documenting members of the same household a breeze.

Narrative composition

The narrative is an officer’s account of an incident: what happened, where and when it happened, who they spoke with, and what they did to handle the situation. If a case goes to court, the narrative will be the basis of an officer’s testimony, shared with both prosecution and defense.

As a result, the narrative is usually where an officer spends most of their time writing a report. Factualness is paramount, but so is the presentation: a poorly formatted report filled with typos and grammatical errors makes an easy target for the defense attorneys.

The challenge I faced was: how do we help officers write correct, professional-looking narratives without sacrificing speed?

A lighter, better, faster (text) editor

Text editors run the gamut: on one end, we have Microsoft Word, the de facto standard word processor with millions of features; on the other end, we have Notepad, the default notetaking app built into every Windows operating system since 1.0.

Writing a narrative using Word is much like designing a user interface with Photoshop: not necessarily because it’s the best tool for the job, but because it’s the one given to you. Every feature not useful to the job at hand adds to the distraction and makes it harder to focus on your task.

So I decided to use an additive approach rather than a subtractive one: instead of taking a full-featured editor and try to remove the unnecessary parts, I started with an empty toolbar, looked into what features are essential to narrative writing, and added them to the editor piece by piece.

To identify which text editing features are most helpful to our users, I used a combination of qualitative and quantitative research.

First, I partnered with our UX researcher, and we interviewed officers and supervisors from several police agencies about what they used most often when writing narratives. The results were not surprising: font size, bold/italicize/underline, bulleted & numbered lists, etc. So far, it would seem conventional wisdom has a point.

Then, I went through every narrative template currently in use at one customer agency. I counted the usage frequency of each formatting feature and compared it against the interview results. There I found some discrepancies:

Although bold/italicized/underlined text showed up frequently, they were not for emphases; instead, they were merely used as a device to make headings, differentiating them from plain text.
Meanwhile, almost no template used more than one font size, despite being mentioned by nearly every interview participant.
Many templates used brackets — [ ] or ( ) — to create checklists, a feature never mentioned by participants in the interviews.

The difference between the qualitative and quantitative results made me realize that what the users think they do may not match their actual behavior; what they ask for is often biased by the status quo, hiding their real needs beneath.

From the research, I made a few adjustments to the design:

Prioritize headings. Add shortcuts for three levels of headings (title, heading, subheading) to the toolbar and promote their usage for fast, consistent heading creation.
Deprioritize bold/italicize/underline. Remove B/I/U shortcuts from the toolbar to discourage their usage for making headings. Keep supporting them (via hotkeys) to maintain compatibility.
Add checklists feature. Support checklists to help officialize their usage in narratives.

To make the transition easier, I also converted all existing narrative templates to the new format.

Collaborative reporting

When police officers respond to an incident, it is common to have one primary and several supporting officers dividing the work. Reasons for this include:

Distribute the workload: e.g. interviewing multiple witnesses separately at the same time;
Prioritize time-sensitive tasks: e.g. transporting and booking an arrestee.
“CBE” (can’t be everywhere): e.g. accompanying the victim to the hospital while others continue the investigation on scene.

As a result, the incident documentation is also divided; the primary officer usually composes the base report, then supporting officers will each add their contribution via a supplemental one.

There are a few drawbacks to this approach. First, contributors could duplicate their work unintentionally, wasting precious time. Second, if one contributor makes an update to the incident (e.g. an assault becomes a homicide), the change may not propagate to subsequent reports timely, creating documentation discrepancies.

Finally, when the reports are ready for approval, reviewers must piece together every document to get a whole picture of the incident, identifying the delta between each while looking for factual errors — a very time-consuming process.

The collaborative reporting experience offers a shared workspace for users to contribute to the same incident, see one another’s work in real-time, and make edits when necessary. Moreover, reviewers can now see the full incident without having to solve a mental jigsaw puzzle, and they can focus on the officers’ writing instead.

Understanding collaborative reporting workflows

Real-time collaboration is not a novel concept outside the realm of report writing: online documentation tools such as Google Docs popularized the idea; even some design tools (such as Figma) now support it.

To bring collaboration into incident reporting, we needed to identify the scenarios where multiple users need to collaborate on the same incident. My goal was to use a small set of examples based on real-world incidents to cover most use cases. To do that, I reached out to my colleagues who used to work in law enforcement for help.

From our conversations, I came up with the following scenarios.

1

Active burglary. A classic real-time collaboration scenario where two officers divided the work and needed to document their contributions individually.

2

Stolen & recovered vehicle. In this scenario, the collaboration happens asynchronously as one officer documents the theft first, the other adds the vehicle recovery days later.

3

Assault → homicide. A scenario where the nature of the crime changes as the investigation progresses.

Updating the report UI for collaboration

Next, we needed to revamp the report navigation UI to support the new collaboration experience. The goals were:

Add visual indicators for contributors of each section.
Display more content in the same vertical space.
Simplify UI elements without sacrificing the level of details.
Create a reusable design for displaying navigational content.

Besides the goals, there was also a non-goal: we do not need to show which collaborators are currently in the report. It is inessential and potentially distracting to the officers working on their narrative.

With these, I updated the navigation UI with the following changes.