Designing for First Responders: Keyboard Usability & Outdated In-Vehicle Computers
First responders juggle a lot—staying constantly alert, watching out for the safety of both the public and their co-workers, managing their personal mental and physical health, remembering numerous situation-specific protocols, working long shifts, writing paperwork, and the list goes on. On top of all that, they deal with technology that is outdated and not user-friendly.
At Mark43, we build software to help first responders do their jobs more effectively and efficiently. To understand the needs of our users, we spend a lot of time learning about their work environments. This includes everything from department policy and state law to the type of computer they use.
Mobile Data Terminals (MDTs)
First responder vehicles are equipped with computers called mobile data terminals. MDTs are durable and portable, but their screens are small and they look like artifacts from the 90s-era shelf at the Computer History Museum. Few departments can afford to replace these computers, which cost thousands of dollars a piece, so most first responders will be stuck with them for some time.
Users on MDTs deal with a variety of usability challenges:
- Touchpad size and responsiveness: At only around 1.5 inches long by 2 inches wide, the touchpads require users to swipe across them several times to move the cursor from one side of the screen to the other. Responsiveness deteriorates over time.
- Screen resolution: It’s low, and visibility is made even worse by sun glares. Designers: should we use gray 1 or gray 2? MDT: you think either one will show up on my screen? 🙃
- Touch screen reliability: Many MDTs technically have a touch screen, but I’ve yet to encounter one that’s decently responsive. How it usually goes down: tap…tap…tap…press hardddd… give up and use the keyboard instead.
- Scrolling difficulty: The simple action of scrolling down the page is a pain when your only choices are 1) relying on the TAB key or 2) using the touchpad to very slowly navigate to the scroll bar.
- Positioning in the vehicle: What exacerbates all of the usability issues above even more is that MDTs are typically attached to the middle of the console (between the driver and front passenger), which forces an officer to twist their torso 45 degrees to the right to face the screen.
Mark43's Computer Aided Dispatch (CAD) and Records Management System (RMS) helps police officers respond to 911 calls and write reports. To support these critical workflows, we need to ensure the usability of our products despite the limitations of the MDT.
Responding to 911 calls
When an officer uses CAD in their car, they receive notifications about 911 calls they’re dispatched to, send messages to other officers and dispatchers, and query external databases. After responding, they return to their vehicle and clear the call, which notifies the dispatch center that they’re ready for another assignment.
The First Responder mode of CAD was designed to be simple and help officers stay focused while en route to the location of a call. There are few possible user actions. Text and buttons are large. Keyboard shortcuts are displayed on the UI and require only one hand, enabling an officer to use a shortcut with their right hand while driving with their left hand if necessary.
Report-writing
After responding to a call, police officers follow up by writing detailed reports to capture what happened in our RMS. The RMS interface is more complex than that of the CAD First Responder, with more functionality and more data entry.
Many department stations have report-writing rooms with large computer monitors and mice. These rooms provide a much more physically comfortable experience than using a MDT. However, even if the department has a report-writing room, there are other reasons why officers rely on MDTs to write reports.
On ride-alongs, I’ve observed that officers often barely have enough time between calls to take a bathroom break, let alone head back to the station to write up a report. Rather than finishing a long shift with a backlog of reports for dozens of calls, officers want to be able to write their reports in a timely manner while details are still fresh in their minds. Thus, they often use the few minutes of downtime in their vehicle between calls to make progress on reports.
Nothing tops spending time with users
I had the chance to go on a ride-along with a Seattle police officer named Josh earlier this summer. First, we worked on a report related to a harassment call he had responded to earlier that morning. He worked efficiently and confidently, tabbing through form fields and using arrow keys to make dropdown selections. When validation errors cropped up, he was able to resolve them quickly. I asked him what he thought about the product, and he said: “It’s user-friendly and just feels faster than our old system.” Shortly after Josh finished this report, he was dispatched to a new call and we started zipping across town.
As we drove, I reflected on what I’d just seen. Wow, that’s awesome, I thought to myself. Though he was still learning the system, he hadn’t experienced any hiccups while writing the report and seemed happy with the product overall.
As Josh responded to more calls, I observed closely while he wrote different types of reports. Though he was able to submit all of his reports with no huge blocking problems, he encountered some usability issues along the way that really stood out to me.
Examples of the issues I noticed:
- Instances where a new panel with a form opened, but the cursor wouldn’t automatically focus on the first field…and when the panel closed, the cursor wouldn’t re-focus back on the element where he left off.
- The cursor focus would unpredictably skip certain elements in the tab order.
- Sometimes he had to squint to make sure that the focus was on the right element because our blue primary buttons were hard to distinguish from the browser’s default focus state color.
- Several times, he had to use the touchpad to scroll as a last resort when tabbing through elements didn’t focus where he expected.
Over the course of the day, the combined impact of these seemingly small hiccups slowed him down unnecessarily. This insight sounds obvious, but watching a user struggle with your product for 3 hours while you’re sitting next to them really cements it on a new level.
Turning in-field observations to product improvements
Upon returning to New York, I was eager to share what I saw with my team so we could fix these issues ASAP. But first, I needed to get everyone else riled up about them too.
I picked up the old MDT that had been collecting dust in the corner of our office, brought it over to the team, and asked everyone to try navigating through a report using the keyboard only. Groans and jaw drops ensued.
To actually experience problems, even briefly, makes them feel more urgent, real, and personal.
Small paper cuts
Our team has long known the importance of keyboard usability, and that we could do better at it. We’ve heard from our customer teams, and seen the feature requests come in. However, in the hustle and bustle of being a small team responsible for a large platform, we made the mistake of de-prioritizing keyboard usability time and again.
Watching Josh and other users complete reports from start to finish helped us finally understand how these issues cumulatively had a big impact.
When using a product 24/7 for your job, each small usability issue is like a paper cut. Over time, the pain of all these paper cuts really adds up and eventually becomes insufferable.
A platform-wide effort
Since then, teams working on both RMS and CAD First Responder have been chipping away at keyboard usability problems. We started by addressing the most common user workflows. Platform-wide, we’re thinking holistically about usability, consistency, and refining our best practices.
Some of the steps we’ve taken so far:
- Audit existing UI, and document the issues we find
- Use one of our bi-monthly syncs (which involve designers, engineers, and product managers across the entire platform) to share findings and get aligned on best practices
- Incorporate keyboard usability testing into the design QA process when developing new features (for kicks, I bust out the office MDT for this)
- Implement more visible focus states on buttons and form fields
- Implement cursor autofocus on the first actionable element of user-triggered overlays (modals, panels, cards, popovers)
- Conduct user research on keyboard shortcuts for frequent report-writing actions (save, edit, entering common dates/times, etc.)
Long-term
Our ultimate goal is for every element on every screen of our products to have seamless keyboard interactions. We’re not fully there yet, but I’m glad to say that we’re making steady strides. 🎉
Keyboard Usability Resources
These resources were created by accessibility pros and have been tremendously helpful to us along the way:
Design at Mark43
One of the most special parts of working at Mark43 is the level of opportunity we have to engage with our users. All employees here — from designers to accountants — are encouraged to visit the agencies we work with and participate in user research. Designers frequently conduct usability testing and contextual inquiry research where we observe 911 dispatchers, firefighters, police officers, detectives, evidence technicians, and records administrators doing their jobs in order to understand how our technology can better serve them.
Want to learn more about our work? Let us know in the comments what topics you’d like us to write about next. Also, we’re hiring!
Many thanks to my amazing team members Liz Harman, Hannelore McElheny, Cassian Catanzaro, Stanley Joseph, Kristine Ortega, and Rachel Lorencz for their feedback on this piece. 💕
