Wearer of many hats
Our first project was an exercise in rapid prototyping. Emphasis on the word rapid. While it might have sounded overwhelming at first, I took this as an opportunity to be my own boss and make all the tough decisions. Who wouldn’t want that kind of freedom? I played many roles (every role actually), taking the project from start to finish as a product designer. I was a UX researcher, writing interview scripts and conducting interviews, which later led to ideation and sketching, then prototyping and being a UI designer. I also documented and photographed my progress along the way. I wrapped it all up by pitching my app in a short and (kinda) sweet presentation. Even though I am *not* my user, I still of course played the role of tester, to make sure everything was in working order and tried to empathize with my users.

Tick-tock
This was a quick one. I had about 72 hours to get. it. done. And I did! This was an exercise in embracing ambiguity — this was my project brief: design a health app. That’s it. No details. Just design a health app. This app could have been anything related to health — diet, nutrition, exercise, or even something to do with medical records or doctors. It was up to me to figure it out. How was I going to do that? Through user research, naturally. More on that process later. I created my prototype with my own two hands using good old fashioned pen and paper since it’s so quick and easy to iterate on, which I then photographed and pulled into the easy-to-use prototyping tool, Marvel.

Identifying a problem that needed solving
Here’s the thing: I didn’t have an initial problem statement. As I mentioned earlier, the category of health is so broad. I decided to take an open-ended approach and conduct generative user interviews. That way, the users could tell me what their problems were and I could provide them with a solution to those problems.

User interviews
Since I was taking a generative approach, I wrote an interview script that covered general topics regarding diet/nutrition, exercise routine, and physical activities, hoping to identify common themes across the board.

I interviewed four people with my broad questions and then synthesized my findings. I was able to spot some similarities and trends among users and then I zeroed in on this specific problem:

In hindsight, I definitely would have liked to refine my script and really zero in on specific things about user’s workout habits around the city and their discovery process of activities, and their level of passion and interest in out of town excursions. If I had more time to research, I probably could have just honed in on the excursions part of it and fleshed that out into an app of it’s own. Here are a few quotations that led me to my problem statement:

Pen to paper
After completing my user research, I knew I wanted to design an app that would connect people that wanted to workout together in the city and also go out of town on adventurous excursions. I sat down and established the scope of the project — basically asking myself what screens and features would be necessary for users to complete these tasks.

Onboarding Screen & Home Screen

User Testing
I decided to open with a“Complete your profile” screen upon first opening the app. After all, the goal of this app is to connect users with similar interests, so we need to know a little information about this person before they get started. I was concerned that users wouldn’t want to fill this out, I know how annoying being forced to sign up for something can be. Later during user testing I found that 80% of my users would fill it out since it was so short and concise. I purposely made it short because I figured that would make them more inclined to complete their profile.

Once the user hits the home screen, I wanted multiple avenues for them to discover activities, excursions, and friends, so I made sure to include a search field as well as a browse section. There are also actionable buttons to plan one of these on your own. At the bottom, I designed a simple tab bar for easy access for the user to navigate to “My Activities” / “My Excursions” etc. However, I didn’t want these screens to be dead ends, so I made sure they were actionable and included Plan and Browse options on these screens as well.

no dead ends

Let’s go through some user tests and see a few more screens. One of my tasks I asked users to complete was to find and join a running group in Manhattan. All users were able to complete the task. Out of my 5 users I tested, 3 used the browse function and 2 used the search function. I was interested to see which one was the better route. Search is more direct, but browse is a good option too if the user wanted to see what else is out there.

TASK: Find and join a running club

You’ll also notice there’s a plan option on the Browse Activities page as well. So if the user doesn’t see what they’re looking for, they can plan something on their own and invite people.

Other tasks users completed were plan an excursion and start a conversation about yoga. Success on all fronts!

Plan an Excursion | Start a Conversation

While I focused heavily on the user flow and task completion, there were a few other issues I identified during user testing, which if time allowed, I definitely would like to have iterated on. There’s a profile icon in the top right corner which take you to your profile. When users navigated there, they had no way to edit their activities, so I added an Edit Profile option.

Another navigation issue came up when users were a few screens deep into the app. After my first few user tests, I realized that there was no direct route back to the home screen. The next user tests I did, I specifically asked the user to navigate back to the home screen. They had to tap the back button in the upper left corner multiple times. I definitely did not like that, so I added a home icon in the upper right next to the profile icon. I’m not totally sold on this solution yet; I don’t like seeing 2 icons up there because I already have 4 icons on the bottom tab bar. I don’t want 2 nav bars, but this was the best fix I could come up with on the spot. I’m still thinking about this solution.

There was also some confusion with the language within the app. Two users wondered what the differences between an activity and an excursion were. They’re essentially the same thing — group physical activities, activities being local and excursions being out of town. One solution is they could possibly be lumped together in one section, and from there the user can filter the listings based on time, location, duration, price, etc. One user was confused about the “social” aspect of the app. You can add friends, you can find people nearby, and there’s a community forum. They’re all essentially a social component of the app, but the language probably needs clarifying. Or the sitemap needs some rearranging. Or maybe we cut the social part out, as I don’t want FitFlock to suffer from featuritis.

See it in action

Reflection
This was fun! In hindsight, I definitely would have narrowed my script a little bit more. Starting with generative questions was great at first to get some momentum going, but I should have done another round of interviews to drill down further into this whole excursion thing. I probably tried to cram a little bit too much into FitFlock this first time around. I got a little hung up on the user flow and functionality. However, I do thing that’s a strength of mine — I care about the architecture of the app and I never want the user to get frustrated with navigation. I also love making things work. Marvel was so easy to use to bring my prototype to life. Looking forward to learning more about creating a holistic experience.