Context
Flox is an iOS app that aims to facilitate connections after parties. The premise is that when you go out, you check in to receive a Debrief the next day, which contains a list of everyone else who was there (including their socials for when you need to slide in their DMs), as well as photos from the party.
For this scope of work, I was the sole product designer working alongside the founder and CEO, Jamie Lee, to make product decisions.
Objective
Since Flox was a startup still in its early stages, it was imperative that we implemented growth loops that would ensure a continuous upward trend in users.
Insight
Our founder did extensive research on the history of Facebook and found that one of their biggest growth levers was the photo tagging feature, which allowed current users to tag those without a Facebook account.
The same strategy could be applied to Flox, since we had just launched a way for users to add photos to the Debrief. Photo tagging not only opens an avenue for new users to join the app, but also fosters more connection between existing users by introducing another entry point to others' profiles.
Considerations
Though this seems simple in terms of concept, many variables contributed to the complexity of implementing such a feature into our existing system:
• the need for two entry points to the flow
• two separate flows depending on if the tag is for a user already on Flox vs. not yet a user
• various states of the tag component
• including a way for users to receive and manage tags from notifications and their profile, respectively
• specifying how tags should be viewed in the Debrief
• accounting for extra development time due to the need for deep linking on the engineering side
A closer look
Our iterative process at Flox typically began with our founder drafting low fidelity mockups to give me an idea of her vision. I used those as a starting point to then create the following high fidelity screens:
Decisions, decisions
A few alternative iterations of the above feature were considered. My role entails both coming up with the best possible solution as well as explaining why this solution outweighs the others.
Component States
I ensured that our design elements changed states to give more context when applicable.
Dealing with edge cases
Just like designing for all possible scenarios when it comes to components, it's important for us to give developers further instructions on how to maintain a positive user experience when special cases arise.
Takeaways
Though this feature was never developed and tested like we had intended due to factors out of our control, I did learn a lot about the lifecycle of a product feature. There are a few things I'll do differently next time:
🥡 Even in a fast startup environment, it's important to set aside time for retrospectives to review how implemented designs are performing.
🥡 Specifying metrics for success and implementing ways to measure that are also vital.
🥡 Involving developers from the beginning helps to more clearly guide the design process and cut iteration time.
hey you made it this far, why not check out another project?: