Summary
I teamed up with an emergency room doctor for my final group project at Le Wagon’s nine-week bootcamp to design an app to facilitate communication between paramedics and emergency rooms. Astonishingly, in the year 2020, the two parties communicate over noisy radio walkie-talkies, and it leads to all kinds of tragic miscommunications once patients roll in for care. We sought something that would let paramedics quickly send in relevant info along with GPS-enabled ETAs that could be visible to emergency room staff on an airport terminal-style dashboards. This case study uses low-fidelity mockups as a means of illustrating how I tried to tackle creating a digital product from scratch, as opposed to a redesign of something badly in need of it.
I’ve attempted to learn to code numerous times since high school without much success. Not wanting to end up a forty year-old tour guide, I enrolled Le Wagon’s nine-week coding bootcamp in Mexico City from January to March 2020. I did not expect the primary outcome of the class to be a rekindling of my love for design.
I should put this another way: I was the only student with any design experience in our class, and up until that point, I took my propensity to engage with design problems for granted. Let me put that yet another way: I was surprised, for the first time in my entire life, that a design problem could hold my undivided attention for hours on end only after I saw my classmates routinely move on after five or ten minutes. Perhaps the biggest surprise of the whole endeavor was seeing how little patience or interest my fellow students had in design thinking, particularly with regard to everything that precedes the UI stage. In other words, even my diehard backend programming-oriented classmates were relatively keen and opinionated on the sexy stuff in design— looking for “inspo” on Dribble and Pinterest, bookmarking animated button styles, dreaming up logos, finding stock video loops for the backgrounds of login pages — but had little patience for, say, wire-framing, type legibility, or form design. This, after years out of the graphic design game, is what made me start to seriously consider firing up my rusty old pen tool and really learning UX. By the end of bootcamp, I was hardly writing any code — most of my classmates needed design help, and I cannot resist being useful.
The last two weeks of bootcamp were spent on final group projects. During week one we all made variations of Airbnb (mine was for nursing homes), and for week two, we pitched our own projects. I was on a team led by Joe, whose story is worth recounting. He grew up not too far from me in Columbus, Ohio, and spent his teenage years dealing drugs. A brush with the law sent him abruptly in the opposite direction and he joined the military, then got out. Then he went to Nepal to become a monk (!), quit that after a year or two, enrolled in Cornell Medical School, became an ER doctor, and finally ran an ER in Taji, one of the most dangerous places in Iraq (!!!). Besides his Hollywood backstory, working with Joe was like hitting the jackpot as far as the last part of bootcamp was concerned — his concept was by far the best of our entire cohort (the rest were further variations on Airbnb, Uber, and the like).
Joseph shocked everyone by explaining the process by which patients make it from the site of a medical emergency to the nearest hospital. Across the United States, ambulances and emergency rooms communicate via circa-WWII radio technology using walkie-talkies, through which the audio quality is mediocre at best. Sirens are wailing in the background, and the calls are made by EMTs who are multitasking in situations that are stressful to say the least. The consequences are often dire: on the ER side, Joseph said he’s had two year old girl die on his watch because his ER was expecting a twenty-two year old girl, and they couldn’t mobilize and recalibrate soon enough to save her life. It’s a bit of a cliche, but seconds really do matter.
Often, emergency rooms often have no idea what kind of patient is coming in until they literally burst through the door. The walkie talkie radio systems currently in use are essentially two-way, so if another ambulance happens to be calling in on your ER’s radio channel, you more or less hit an old-fashioned busy signal and have to call back. Sometimes, when EMTs can’t get through on radio, they resort to using their phones to call the ER desk, then get put on hold with someone’s life literally in their hands.
So, Joseph proposed designing an app that, in his words, could “save lives by saving time.” He called the project Code 3, which is the call code for “use lights and sirens.” Paramedics would use our app to send information about their patients’ conditions, GPS would provide the hospital an ETA, and the doctors, nurses, and receptionists in the ER could monitor everything on something like an airport terminal arrivals dashboard.
Joseph himself could have been plucked out of central casting as “no nonsense guy.” He stressed that the app and its design should be simple, but wanted no stake in the design process beyond pen-on-napkin mockups. In lieu of users to test, we repeatedly called on his friend Pam, a semi-retired and even more no-nonsense ER receptionist back in Ohio, who emphatically confirmed all of Joseph’s ambulance-to-ER communication horror stories from a different perspective.
In our four-person team’s short development timeframe, Joseph made the executive decisions, with an extra blessing from Pam when needed. I mention this before we get into nuts and bolts because it led to us to make an “executive” design decision that seemed off to me, and still does: we designed the app principally for use on the mounted laptops that come standard in ambulances. From my removed perspective, it’s awkward enough to type on a laptop on an airplane tray table; doing the same in an ambulance careening around street corners and hurtling through red lights seemed even worse. To me it made the most sense to design for mobile first, scale up to larger viewports from there, and give paramedics the option to use whatever’s most expedient. We found another company, Twiage, who had already made a souped-up version of the exact product we were prototyping, and their version was indeed mobile-centric. But in the absence of any users to test, my own lack of expertise in the field, and most of all the clock ticking, Joe made the final call, and we designed for laptops.
Designing for Paramedics
In any case, the first steps were as simple as Joseph said they would be:
1: Log In / Sign Up:
2: Choose your hospital (and set it as default, if need be). Once logged in, an avatar link appears at the top right for account settings, preferences, etc.
3: Select one of the four universal medical categories for ER calls:
4: …and a condition.
Here’s where things get more complicated. At this stage, paramedics typically log vital signs and a cornucopia of condition-specific details. This is where we realized that the app we were designing was essentially just an elaborate, life-or-death, need-for-speed form wizard, and I proceeded to spend an entire day-plus in a form design rabbit hole. There’s a shocking quantity of books about the subject of form design in UX, most dated to varying degree, but none were available to me in Mexico on short notice. I absorbed general best practices via Google within an hour or two — the most useful of which for me was Miller’s Law, which holds that returns diminish in human memory at seven items, plus or minus two (as in the seven digits used in phone numbers). But beyond this, 80%-plus of the reading material on form design online comes from a marketing perspective — and 80%-plus of that is related to either mailing list opt-ins and shopping carts, where the economics of attention are paramount. The intended users for this app are paramedics who are used to filling out byzantine paper forms (like this, for example) many times a day as a matter of routine. The primary consideration here, rather than attention, is pure speed. The “ideal” EMT radio report clocks in around fifty seconds. Our app would have to meet that at the very least.
So, first, it was natural to give the vital signs their own screen, below. All the numerical entry, especially with regards to blood pressure, would be somewhat challenging for an EMT on a phone or tablet, but considerably less so on a mounted laptop with a keyboard.
And now the real pickle in laying this thing out: most medical conditions have their own unique and daunting list of particularities form-wise — a significant challenge for mobile design. For our demo day prototype, we only had time to develop something that would work with one or two such conditions (we ran with “burn victim” and “heart attack”). A laptop, mercifully, is a large enough canvas to use a 16-point paragraph font. Rather than putting each subsequent question on its own screen, which might make sense on mobile, it seemed fastest to allow paramedics to quickly click through all of the relevant boxes with a mouse, touchpad, or using the tab key. The information entered on the previous screen is reiterated in the two horizontal blocks towards the top to cut down on typos. Is this the best solution? I doubt it. Have I thought of anything better in the absence of people to test? Nope.
The last step — submitting the “form” — is comparatively simple, and contains everyone’s favorite feature: the “OH SHIT” button. So, unfortunately, patients will sometimes go from bad to worse on their rides to the hospital, and the walkie talkie method of ambulance to ER communication doesn’t really cut it when the shit is really hitting the proverbial fan. So we added a big red button at the end of the process that paramedics could press if a situation had suddenly become so FUBAR that they didn’t have the time or ability to update it in detail on the app, which you can see below.
In this last step, “update” goes back to step one with the same patient, “finish” starts the process over with a new patient, and “oh shit” we’ll address momentarily.
I should note that, crucially, after the first screen, no fields are required. This is so busy EMTs can fill out only what they consider relevant and have time for. Progressing to each new screen in this process sends a new round of data to the hospital immediately. The EMT could select “Medical” as a category, then “Chest Pain” as a condition, wave off the more complicated next steps, and return to treating their patient if necessary. In this case, at least the hospital will know that someone with a heart attack is arriving in five minutes. Joe and Pam both confirmed that knowing that a burn victim, in general, was en route — details notwithstanding — would be enormously valuable and a vast improvement on the current situation in most ERs.
Designing for Hospital Staff
Below is the view at the other end of the pipeline, the emergency room. Here we have a rolling, color-coded, descending display of incoming patients with their conditions, categories, and ETAs. The red outlines designate those unfortunate “Oh Shit” patients. The newest cases appear at top left, and the older ones move on down the line.
And that’s it. At this juncture, the urge to add new features is irresistible: ER-to-ambulance chat, audio, photos and video, case prioritization…the mind reels. But, for Joseph, this is where our main known competitor, Twiage, goes astray — their app has many of these features and more, but we’re focusing on getting the paramedics in and out in record time. Beyond Twiage, other companies have developed extremely sophisticated equipment that communicates this kind of information more or less automatically to ERs via sensors and the like, but they cost tens or even hundreds of thousands of dollars. If this simple app could cut call time in half and convey information more clearly, that’s all we’d initially try to market. New feature ideas can come democratically, directly from the paramedics and the ERs they serve.
We were in such a time crunch that we went straight from these low-fi mockups straight to development, and the busywork of coding out all of the form info required all-hands-on-deck, so this was as much design as I had time to do. The “final” working prototype for our demo day didn’t change much from the mockups. We used fonts that are uglier but more legible/readable (Montserrat and Roboto), and added the official color codes for different medical categories:
…applied both of those on both ends of the chain of communication:
…and added commonsensical, traffic-light style colors to the final screen. The red outline on the “Oh Shit” button denotes that it’s been toggled.
I would have loved to continue developing this project with our proudly half-Mexican, half-gringo team, but Covid hit in a major way the very week we were working on this, and the bootcamp ended early and abruptly. Everyone in our group scattered to the winds — none of us more than Joseph, who, of all things, is now running the only ER in the Marshall Islands, where his ER is still communicating via walkie talkie.
