Research

With group introductions completed, we began our project by choosing a user group. We all wanted a user group that was unique and had an unsaturated design space, and those qualifications landed us on firefighters.

Since we were all uninformed about the profession besides knowing that firefighters fought fires, we started with research. Although we compiled our research, conducting interviews was an individual assignment. My transcription is here. 

We compiled our research by way of affinity diagram to talk about what we learned, what surprised us, and what was similar across all interviews. Here were our takeaways:

Personas

We then made personas using common threads from our affinity diagram. To represent the demographics we found while conducting user research, we had one persona represent an experienced officer, and the other represent a new firefighter. Our hi-fidelity personas were referred to frequently throughout the design process, specifically while creating the User Journey Map and Design Requirements. 

The personas we made as a team. Click to enlarge.

User Journey Map

With Wallace as our inspiration, we created a User Journey Map to follow his emotions through a typical day with a low acuity run.  This map helped us emotionally connect with the firefighters and identify points of high frustration. Here were our takeaways: 

Our Uninspired Slump Followed by a Creative Breakthrough

After completing competitive analysis on a very unsaturated space, we knew whatever product we designed would have the potential for high impact. With that in mind, we each storyboarded ideas that ranged from patient reporting, firefighter response times, and a GPS system. 

Coming off a round of ideation, it was becoming clear that the reporting process was the biggest pain point the firefighters had because the application was not tailored specifically to firefighters and took up a large amount of time that they could be on service for. 

The form the firefighters currently use after every incident. Click to enlarge.

At this point, we were stuck. We recognized that designing the report would be the most beneficial for our user, but we found redesigning the report uninspiring. We talked to our professor, and he encouraged us to think beyond the immediate problem of the form. If there was no current way for firefighters to complete their reports and we were tasked with providing functionality for them to do so, how would we do it? This made us realize that we were avoiding the real pain point by redesigning the form. Thus, our new design question became: How might we re-imagine the firefighter reporting process to reduce time, effort, and keep firefighters in service after a run? 

My team and I, inspired by our talk with our professor, brainstormed new how might we’s.

This breakthrough gave us a burst of energy and made us feel more confident in our project going forward.  We went into yet another brainstorming session, this time playing with different form factors for the reporting system. Our interface sketches ranged from combinations of AR, a system embedded in clothing, and varying inputs. Mine are below. 

My interface sketches in which I played with voice, AR, and firefighter collaboration.

Deciding our Form Factor

Now fully immersed in the design phase, we began working on the structure of our system. The discussions that arose from mapping out our Information Architecture cemented an AR form factor with voice and touch inputs. 

We based our system off Google Glass, which is a heads-up interactive display (HUD) that is implemented on smart glasses. We chose Google Glass because it can be implemented on the firefighter's safety glasses (which they wear for every run) and has voice functionality. Because of accessibility concerns and patient privacy, we wanted a touch option to be available. We also wanted a voice option because it was completely hands free.

The form factor we decided for our system, Google Glass.

Our Struggle with Paper Prototypes

After we had determined the flow of our system with Information Architecture, we moved on to making our paper prototypes.

Paper Prototypes was a challenging deliverable for us as a team. We were the only group not doing an app, so we were struggling to find a way to communicate our AR vision via paper. We had already scheduled our usability test for the only day that the firefighters would be able to do it, and we ran out of time to produce quality prototypes. Unfortunately, we had to test our vision via paper. 

Just as we found it hard to convey our AR vision, they found it hard to experience it. We tried to set the stage for the experience by explaining the context of our design up front, but quickly found out it was not enough.

Image from our experience eval with some of the firefighters we interviewed.

Although the evaluation started off differently than we hoped, it quickly got back on track and was the single most helpful thing to refine our design. Here were our takeaways: 

Wireframing

Using the feedback from the usability test to guide our wireframing, we produced a full set of wireframes with complete flows. Shown below is our key transition diagram. Inputting vitals was going to be one of our most used task flows, so we created a key transition diagram to call attention to how our product would support that task. 

A diagram on how our system supports the key task of inputting vitals. Click to enlarge.

Hi-Fidelity Mockups

Nearing the end of our project, we made hi-fidelity mockups to illustrate our idea. It was at this time that our AR vision came to life and our product was finalized. 

Implemented on firefighter safety glasses, Active Sight is a comprehensive reporting system that is hands free, efficient, and still allows for situational awareness. By utilizing AR and a combination of voice and touch inputs, Active Sight allows firefighters to quickly complete the report and spend more time doing the job they were trained to do. 

With an interface background that adapts to the light around you, Active Sight can be used regardless of time or place. Minimal interface text allows for situational awareness, complimenting the firefighter's response and not hindering it. Active Sight's ability to use voice or touch allows for flexibility in interaction methods making the product adapt to a firefighter's needs, not the other way around. 

Hi-fidelity mockups of Active Sight.

Next Steps

My group and I believe that Active Sight achieved our goal of re-imagining the firefighter reporting process and provided a much-needed response to the inefficient and demanding report system that is in use now. However, we recognize that our design is not perfect and wanted to address the things we believe would have made our product more successful.

What We Learned

All of us were experiencing the whole User Centered Design process for the first time, and to explain what we learned would be to outline the whole class. However, these were our big takeaways:

Personal Growth

This class was extremely challenging and pushed my thinking skills beyond what I expected. I remember explaining to my friends that "I reached so many levels of thinking and asking 'why' that I forgot where I started".  Not only did I learn what a User Journey Map was, or how to storyboard, etc., I learned about how I interact in groups.

We had three anonymous team evaluations from our teammates throughout the quarter. I received majority positive feedback which was encouraging, but I did receive some constructive criticism that was really beneficial for me to hear. No one is a perfect group member, but because of those evaluations I am more thoughtful about how my personality meshes with others in the group.

My team and I!