During the second Explore phase of this project, I focused on developing a fully-featured electronic prototype that I could use for smoother and farther-reaching user testing, as well getting started with the Flutter framework to actually develop a little bit of my app. Throughout the process, I learned a lot — from designing with Invision Studio (my prototyping design software) and Flutter to getting valuable feedback from my target users.
I have the full details of the Explore phase in a different post. In the Agile process, the Adapt phase is devoted to reflecting on the previous sprint, including how the feedback process went, lessons learned, what worked and didn’t work, and a business or technical review to evaluate how technically feasible and viable one’s product is from a business standpoint.
User Feedback
As with any creative process, a huge component of developing a successful product involves the ability to get useful feedback from others, especially your target users. Reviewing this feedback will be critical for moving forward in the most productive way possible and making sure my app is going to be intuitive and useful.
In-Class Feedback Session
Directly after completing the Explore phase, we had another in-class feedback session, where me and all of my peers were able to present our work to the class for initial feedback on what we’ve developed so far. I showed my electronic prototype and had a peer click through it, while everyone else watched, asked questions, and suggested ideas.
Here is some of the most useful feedback from this in-class session:
- Health/Mission tracking feature: For design consistency, it could be good to have the “Customize” button somewhere else on the “Add Mission/Health Log” page, replacing it with the action button for submitting your health or mission log ( and titling it “Add”, “Submit” or “Save”).
- Assess feature: One problem might be that users have to click into the area for the stress continuum they most identify with before being able to select and save that one (see below image: users have to click into the subsection of “Mission-Ready” from the main page before submitting that as their current stress state). This could get tiresome, especially after users are comfortable with the criteria for each level of the stress continuum. One solution could be to add a “+” icon in the top right, which is consistent with the appearance of the Tracking feature page. The “+” icon would bring users to a page that just has a picker for each stress state and a submit button, for quick and simple submission. Since the “+” icon would be taking the place of the “History” button, that could switch over to the top left corner of the screen, and the info button would simply appear in the onboarding instead of being a clickable option in the main part of the app.
- Learn feature: While not a huge priority for this development timeline, it could be cool later on (read: when this class is over) to actually categorize the education modules according to topic. One of my peers suggested the app Headspace as a good example of this: the different meditation modules are divided up by topics that users can click into, for better organization and clarity (see screenshot below).
Feedback from Target Users: Search and Rescue/Medical Workers
Since this app is actually being designed for first responders (especially people in the search and rescue field, for this development period), I knew it was also important (and probably more so) to also test my prototype with my target users.
Luckily, in addition to testing my prototype with a few of my rescuer friends one-on-one, I got the chance to test with quite a few people at a meeting for my rescue team. The purpose of the meeting was to kick-start a Resilience Team, or a group of people who would be actively working to make our rescue group more resilient to stress injuries through awareness, prevention and treatment. Laura McGladrey, the woman who has been supporting me through the development process and helping to spearhead a lot of the app’s exposure, was also at the meeting, and I spent a lot of time with her to make sure we both thought the app was going in a good direction.
Encouragingly, I got overwhelmingly positive reactions from everyone at the Resilience Team meeting! A few people even offered their engineering/usability skills if I needed their support later in the process. Overall, people seemed very excited to have a concrete tool that people can use to keep tabs on their mental health, and have more resources for making informed decisions about their responses to stressful situations.
Below is some specific feedback that I wrote down after getting people to click through the app:
- It would be great if there was an option for adding in how often you’re doing things you enjoy, exercising, etc., somewhere in the health tracking section
- People liked the education modules that are in the prototype, but I also received a lot of suggestions for other types of educational resources, such as links to podcasts or even short meditations (audio files) within the app
- McGladrey suggested implementing the concept of assessing your “battery’s charge” along with the stress continuum, since “feeling drained” is often a metaphor that people easily connect with. Could just be another piece of criteria in each stress category!
- Being able to put in your own criteria for the stress continuum, or getting a suggested placement from a short quiz would be helpful. These are features that I definitely want to develop at some point, but might not have time for during this development period.
- Teams could get subscriptions to the app, and leadership could view aggregated and anonymous results of where their team is at in terms of health indicators, stress continuum selections, etc.
- There could also be a feature where users can “1-click” to send a previously-chosen contact a little notification, telling them that they might be in need of help and support
Moving forward, I want to keep gathering as much feedback from first responders as possible, and Laura is going to be a huge help in that area. She is getting started on sending out my prototype to her own connections, including SAR people, medical professionals, etc. Since I have everything for my prototype on the web now, it is pretty simple to send my link out and allow people to either comment directly on the prototype or send me feedback via email. I’m excited to see what people on different teams and in different regions have to say about the app!
Lessons Learned
While I was creating my prototype, I learned a few things about developing prototypes and developing with Invision Studio that will certainly speed up my process next time I have to make a prototype and improve my efficiency.
- Using pre-designed UI elements (from iOS and Material kits designed specifically for Studio) are a great way to jump-start the prototyping process, because you can drag-and-drop components like tab bars, navigation bars, switches, etc. to give your app a native, realistic look-and-feel right away. I started out trying to create my own elements from scratch, meaning that creating even the most simple of elements took forever and was highly inefficient.
- The “Components” feature of Studio is incredibly useful because it allows you to create one “master” component and replicate that component through your work, so that if you change the master, it updates all of your instances of that component. However, in order, to make this work, you must use components consistently. There were a few times when I thought I was using components in my various screens, but instead, I had accidentally been duplicating an edited version of the master. Therefore I had to go back into the master and update that one to have my changes carry over to the rest of the components.
- If you are going to have pages with strong consistency in design layout and components, it is best to really refine your overall design and create essential components (such as navigation connections! In Studio, these are lines you connect between elements and pages to program interactions) before duplicating them and editing each new page. During my prototyping process, I duplicated some screens after thinking my design was working well, and then realized I had to make a major change in the layout and had to go back into each screen to edit it.
Once I had finally created my electronic prototype, I was able to enjoy the many benefits of using a Studio prototype with my users. Electronic prototypes are so much easier to test with and deploy for user testing. For one, you can simply send a link with your prototype out to people, so that they can click around on it and leave comments on the prototype itself. Of course, doing user testing in-person is almost always more productive because you can watch how someone interacts with your product in real-time, but having the ability to just send a link allows you to send your prototype to a much wider range of people.
I learned a lot about coding in Flutter over the course of the Explore phase as I tried to build some simple screens, but one of the most useful lessons I learned was to compartmentalize my code for better organization. Examples of this are to break up pages of the app into different files and have separate widgets for different objects. That way, you avoid having huge blocks of code and can make things a little more legible, as well as editing individual elements without worrying about messing up anything else on the page.
As I learned the hard way, even if you think you know what your timeline is, it is never a bad idea to double check your due date :). Failing to do this, and being convinced that we had three weeks for this Explore phase instead of two, caused me to not manage my time very well during this sprint and instigated a hacking marathon right before the sprint’s due date.
Overall, though, the biggest lesson that I learned during this sprint and while collecting user feedback was that I am definitely going to have to scale back my app for this development timeline (the class deadline at the beginning of May). Since I am just learning how to develop mobile apps and code with Flutter/Dart, things are already taking way longer than I thought they would. Thus, I am quickly realizing that I need to make my goals a bit less ambitious for this last sprint, in order to actually make my development goals manageable and maintain a healthy life balance :). Right now, I am thinking to scrap the health indicator tracking, focusing on only inputting missions for the tracking feature. When I have more time (hopefully over the summer), I’d still like to develop the health tracking feature, but I don’t think it’s feasible for me to develop it during this class, based on the rest of my planned workload for the sprint. I’ll revisit this change in my next Speculate phase.
What Worked
My user testing was a huge success! As I wrote above, I got lots of people to try out the app in a short amount of time at the Resilience Team meeting, and got great feedback in addition to a few people offering their skills for anything I might need in the future. The electronic prototype proved to be great for clicking through, and my user testing — with both target users and others — went much more smoothly than in the first Explore phase.
I learned a ton about how to design layouts with Flutter after much trial and error, and eventually built the main home page for my learn feature as well as the main three-page tab navigation. In trying to figure out how to design basic layouts, I found a very useful webpage on the Flutter documentation called “Flutter for web developers,” (https://flutter.dev/docs/get-started/flutter-for/web-devs) that helped translate the CSS rules I’m more familiar with into the Dart language. I also used a few Youtube videos and plenty of online articles to find my way around the Flutter framework. Though my coding was certainly inefficient at first, I’m confident that I will be able to develop faster during the third Explore phase, using my newfound knowledge.
Using a special pack of UI elements called the Cupertino library definitely made my app look more native for iOS. These elements included navigation bars and tab bars, as well as the iOS standard font (SF Display). It seems that Flutter has the potential to make apps that look extremely native, having options for Material and Cupertino components.
Throughout the process, I got very comfortable in the Studio environment, using components and pre-designed UI elements for iOS/Material design schemes. I know that in the future, my prototyping development will go much faster.
What Didn’t Work
I realized that in future user testing sessions, I really have to make sure I don’t explain the app to my users, instead just letting them click through it. Although I tried to be mindful of letting my users figure out the app on their own, I think I often jumped in too quickly to help them discover various features.
While the Cupertino design components definitely helped the app look more native to the iOS operating system, I’m a little concerned that the iOS-heavy design won’t look as native on Android. Everything will still be functional, but if I eventually want to make the app more compatible for Android users, I will probably have to spend some time tweaking elements to be more in line with the Material design system.
While my prototype worked well for my testing, the only thing to improve the user experience would be having the prototype on a physical device, to give an even higher-fidelity experience. However, due to the specificity of device screen sizes when developing on Studio, I would have to load my prototype on a specific device (iPhone XS) for my users to play with it. If I had more time, it would be great to work on making my prototype responsive so that I could load it on different physical devices.
It would be nice to have the onboarding process as part of my prototype — something that quickly explains how to add tracking logs, etc. — because that’s what users would actually see to help them when they first open the app. With the onboarding component, I think some of the things that my users were confused about (like how to add a new log) would be explained.
Technical/Business Review
I am still very confident in my app concept from a business perspective. Mental health for first responders is a very hot topic nationwide right now, and I think my app would offer teams a good option for building self-awareness, raising self-awareness of stress injuries, and generally promoting a greater understanding of the unique challenges first responders face from a pyschological perspective. Especially for search and rescue teams, there is nothing really like my app on the market right now, so I’m hopeful that people would find it useful as an option for improving mental health team-wide. Everyone on my rescue team has been extremely supportive of building the app, and there is a potential for me to keep developing the app over the summer, possibly presenting it at a national mountain rescue conference in June. Additionally, very simple changes (the types of calls the users are responding to, subtle changes in language, etc.) could be implemented to make the app usable for a wide range of first responders — medical, firefighters, police, search and rescue and military personell.
From a technical standpoint, as I mentioned above, I’m confident that I have the technical ability to develop the entire vision for my app, but I’m not confident that I have the time to figure everything out and implement it well when considering the timeline of this class (having a minimum viable product by early May). I’ve realized that don’t have the resources to build the health tracking/charts feature for this first development period, especially since I am trying to figure out Flutter as I go. Therefore, I am scaling back my development goals to make things more feasible from a technical perspective, and postponing the development of health tracking (and charts) until the summer, after this class has ended. However, I still plan to develop this feature in the future!
Conclusion
Overall, despite the fact that I had one less week for this Explore phase than I had previously thought, I still definitely consider this phase a success. I built a fully-featured prototype that I am very proud of, and it has already provided improved testing experiences for my users. I also developed the first main page for the “Learn” feature of my app and completed the main navigation. Along the way, I learned much about Flutter that I know will continue to help me in the next Explore phase of this project.
nate bennett 