spark
project overview
details
Scope — Assist the Spark team with their UX design needs in preparation for Minimum Viable Product (MVP) launch
My Roles — UX Research Lead, Usability Testing Lead, Ideation
Team Size — 4
Duration — 3 weeks
tl;dr
Upon starting this project with Spark, my team was provided with an existing prototype and asked to compile research to evaluate the current design and inform the direction of the next few iterations. We discovered through early research that Spark has a few differentiators that caused users to hesitate when engaging with the app: 1) it doesn’t have a chat feature, 2) it uses geolocation services to find others in the same physical location, and 3) it has a long registration process that caused users to question how their personal data would be used.
Interestingly, our research also showed that users do want to meet like-minded individuals in real life based on their location. We therefore set out to find ways to promote–through strategic redesign–the purpose and value of using the Spark app. Through a redesigned registration process, we gave users more autonomy over the level of information provided and displayed on their profiles. Through an embedded onboarding process, we identified key moments to assure users of the value to be found in Spark’s differentiators. We also redesigned a handful of other features that caused confusion or friction along the way - read on to learn more!
After implementing our iterations, we saw a major mindset shift in users. There were no more concerns about registration, and users even began to see the lack of a chat feature as a benefit. With this shift, safety concerns became the most prevalent theme to emerge out of usability testing. For next steps, we would recommend focusing on features that enhance user safety, including reevaluating the matching process, designing an identity verification system, integrating additional safety tips and options, and/or introducing more robust reporting functionality.
research
what is spark?
Spark is a social connection app that aims to simplify the art of networking. Users connect with others in real time by checking into a location and sharing their “vibe,” a few words about what they’re looking for or how they’re feeling. Users send each other “sparks” to indicate they’re interested in meeting; if the interest is mutual, the app helps them choose a spot to meet and begin connecting.
spark’s standouts
So, what makes Spark stand out from other social connection apps? Ultimately, Spark intends to start connections in-app and continue them in the real world:
In support of this goal, Spark is the world’s first and only chatless social connection app. The app’s founders hypothesize that guiding users to begin a conversation in real life instead of the app will lead to more meaningful connections. Spark’s chatless and location-specific connection mechanisms are its key differentiators compared to other social connection apps currently on the market.
compare and compete
Speaking of other social connection apps, our earliest research consisted of evaluating potential opportunity areas in the comparative and competitive landscapes. We created a feature inventory–an audit that shows which features a company offers–for comparators (indirect competitors that have some overlap in features or solutions) and direct competitors.
For our comparative analysis, we looked at Twitter and Instagram for their social connection aspect and Uber for its real-time, on-location services. The biggest opportunity area we discovered was user safety:
Twitter and Instagram allow users to block and report content, which then disappears from view. We noted that there could be an opportunity to further explain how reporting works in the unique, real-life space in which Spark operates.
Uber immediately reviews reports of physical or verbal altercations. We noted that, while Spark does have reporting functionality, there is an opportunity to further help and advise users if they are in an extreme situation.
Uber has safety-driven verification systems in place that utilize color coding, license plate matching, and driver/passenger ratings. We noted an opportunity area for Spark to help ensure the correct users are connecting.
For our competitive analysis, we chose Bumble, Meetup, and LinkedIn for their respective networking capabilities that may result in real-life connections. The areas of opportunity that were most apparent were the ability to chat and the ability to display clear intentions for using the app:
All three competitors allow users to chat with each other in-app. However, we recognized that Spark’s chatless functionality is a key differentiator that supports the app’s purpose to get users chatting in real life, so we tabled the possibility of incorporating chat.
Bumble allows users to set explicit intentions for the type of connections they’re looking for, whether friendship, networking, or dating. LinkedIn is also explicitly geared toward professional networking. Spark is more fluid with users setting “vibes,” so we noted an opportunity area to be more explicit with intention-setting.
poll the audience
Next, we conducted a survey to discover trends in how users interact with current networking platforms and to gauge their initial reactions to Spark’s differentiators. We had 25 respondents and gained valuable data points in support of Spark’s concept:
From these data points, we gathered that there is definitely user need in the space Spark is joining, as well as demand for Spark’s specific project. However, we also uncovered a data point that illuminated one of the biggest hurdles we’d need to overcome through our design process:
Users cited convenience, personality vetting, and safety concerns as the primary reasons why they prefer to chat with a connection before meeting. This data point made it clear that we would need to find ways to advocate for the purpose and value of chatless functionality.
user interviews
The next step in our research was to conduct user interviews to gain deeper insights into users’ thoughts, behaviors, likes, and pain points when using networking apps. We had 5 participants and emerged with 4 major themes:
These themes signaled that any design decisions should remain true to the app’s central purpose–to connect like-minded individuals–while delivering a focused, reassuring, and authentic user experience.
initial usability testing
The last step in our research phase was to conduct usability testing on the existing prototype provided by the Spark team to get a sense of what was working well and what could be improved. We whittled down the prototype to focus on core functionality associated with the business-to-consumer (B2C) experience. Eventually, the app will have an additional business-to-business (B2B) user base and functions, but we prioritized the core user base and tasks due to time constraints.
We saw some quick wins: there was a 100% success rate for the core tasks we asked users to complete. Also, the average System Usability Scale (SUS) score across users was 83 (anything over 80 indicates excellent usability and learnability).
We also saw some clear opportunity areas:
With many potential design directions revealed by our research, it was time to synthesize our data and coordinate with our client to determine priorities.
synthesis
getting personal
In order to communicate our target user’s needs and goals, frustrations, and behaviors, we assembled a user persona. Especially when communicating data to a client for the first time, a persona is essential for developing empathy and ensuring a user-centered design approach.
Needs and Goals
Ability to engage with like-minded individuals based on interests or industry
Successful, lasting, meaningful connections
Reassurance and follow-through when using a networking tool to meet others in real life
Frustrations
Incomplete, inauthentic user profiles and spam
Weeding through content that seems irrelevant to her interests or to the purpose of a networking app (social feeds, viral posts, ads)
Receiving too many impersonal, generic, or spam messages and notifications
Next, we further explored Lauren’s thoughts and feelings by charting her experience using the current version of Spark. This type of retrospective journey map helps paint a picture of the user’s emotional state, both positive and negative, while interacting with an existing product.
What we wanted to highlight through the persona and journey map is the user’s curiosity and excitement about the app’s potential, but some hang-ups that could get in the way of a purely positive interaction: the need for reassurance when meeting other users, the long and confusing registration process, and safety concerns about rejecting a spark.
business goals
With our research data in tow, we met with Spark’s co-founders to discuss how our findings might intersect with their business goals. Spark was on the cusp of releasing their Minimum Viable Product (MVP) in a few weeks and, in addition to having the app run smoothly and enjoyably for users, they wanted to prioritize features that would help support user registration and retention rates:
what’s the problem & how might we solve it?
To fully define the problem we were setting out to solve, and to foster team and client alignment before moving into the ideation phase, we finalized our problem statement:
We then created a set of “how might we” questions to kickstart the process of converting our problem into potential solutions:
How might we better define and display Spark’s purpose and features?
How might we help users see Spark’s key differentiators as benefits rather than concerns?
How might we encourage users to complete registration and continue using the app?
proposed solutions
Together with the Spark team, we decided to focus on redesigning the registration process to encourage efficiency and autonomy, which we hypothesized would increase user registration rates. We also decided to design a new onboarding process to help users understand the purpose of the app and its functions, which we hypothesized would increase user retention rates.
ideation
sketching it out
To begin bringing our ideas to life, we held a design studio and created initial sketches of our design solutions. I divided my sketches based on our two main features: registration and onboarding. My personal process for sketching is to focus on demonstrating basic features and flow, but also documenting questions, considerations, and variations that arise along the way.
feature prioritization
From our pool of sketches and ideas, we decided upon reducing the number of registration screens, adding more registration progress markers, and aligning ethnicity and gender options to industry standards. We realized that many of the issues users had with the registration process had to do with the way the information was presented, i.e. small bits of information requested across many screens. It also wasn’t clear what information was required, and what would show up on a user’s public profile. Instead of focusing on the amount of information requested upon registration, we focused on designing the registration process to be more efficient and give users more clarity and autonomy over what will display on their profile.
Next, we decided to design an embedded onboarding experience to help users understand the purpose and intentions behind Spark’s features to assist with user retention. We thought that users would be less likely to overlook or dismiss onboarding messages if they appear organically as users encounter key features for the first time. We selected a slide-up pop-up style to capture users’ attention, but included an intuitive “X” to dismiss the messages so they are not persistent, as well as an option to toggle the messages on/off from the settings menu. Lastly, we added a personal “message from the founders” prior to registration to increase user interest, understanding, and registration rates.
bringing it all together
Since the Spark team provided a high-fidelity prototype of their previous product, we stripped it down to mid-fidelity to incorporate our designs. This would ensure the integrity of forthcoming usability testing, making sure users are focused on functionality rather than visual design.
The first highlight of our mid-fidelity wireframes is that we were able to condense the registration process from 10 screens to 3 (efficiency), as well as add a toggle feature for users to be able to choose what appears on their profile (autonomy):
The second highlight is our seven distinct embedded onboarding messages:
testing
success is sweet
Our next step was to test how users react to and interact with the redesigned product. After implementing iterations to the registration and onboarding processes, the average SUS score across users increased by 7.5 points from 83 to 90.5!
We also saw major shifts in user mindsets that demonstrated our changes were successful:
Initially, 100% of users were concerned about the registration process feeling too long or asking for too much personal information. After our iterations, 0% of users were concerned about the registration process.
Additionally, users reacted positively to the introduction of our embedded onboarding messages, with 40% explicitly commenting on their helpfulness.
Originally, 80% of users were concerned about Spark being chatless. After clarifying the purpose of chatless functionality via onboarding, we were able to reduce these concerns by 50%. The remaining concerns were about the app being entirely chatless, particularly if users need to troubleshoot while trying to meeting up, which we took separate steps to address (more on that shortly). Users even began to affirm the benefits of chatless functionality. One user shared:
“I think the chatless feature helps the app serve its purpose to initiate a meetup.”
Lastly, it’s worth mentioning that user perspectives on safety began to shift due to the previous iterations, helping them better understand the purpose of its app and features. 60% of users perceived no added risk from using the app compared to the baseline risk of meeting someone in a public space. As one user said:
“I feel fine using the app because I’m there in real life already; it’s not more unsafe than when you meet somebody and don’t know anything about them.”
additional insights and iterations
Outside of registration and onboarding, we also implemented several iterations based on direct user feedback from our second round of usability testing.
#1
Although users did affirm that the app doesn’t introduce any additional safety risks, 80% of users still expressed general safety concerns, so we introduced a rating system for users to provide feedback on the quality of interactions with others. This will allow users to make more informed decisions about whether or not to send or accept a spark.
#2
40% of users had concerns about rejecting a spark due to the possibility of negative reactions while sharing the same physical space. To relieve some of the pressure (since revising the entire matching mechanism was out of scope), we made it possible to dismiss spark notifications temporarily rather than needing to respond to them immediately. We accomplished this by changing the notification style from large, persistent pop-up windows to compact, floating banners that auto-dismiss after a time delay.
#3
As mentioned in the successes section, 40% of users had concerns about the app being entirely chatless, especially if they might have difficulty finding another user in a large or crowded space. The same percentage of users had concerns about determining where to meet based on a pre-set list of options, which they felt was limiting. To alleviate these concerns, we increased the prominence of the write-in option when selecting a meeting location:
We also designed a “quick chat” feature that allows users to select from prompts to help troubleshoot meet-up issues. This eliminates complications that might arise by previously only having one pathway through the app: a successful meetup. Users now have multiple pathways:
#4
20% of users wanted to be able to view a record of past interactions and connections. Previously, the notifications screen contained one long list of all notification types. We redesigned it so users can easily toggle between their Spark History (sparks received or sent) and their Connection History (mutual sparks).
delivery
next steps
While we were able to make great strides redesigning the registration and onboarding processes, plus additional iterations to make the app more comfortable and enjoyable to use, our timeline and scope limited our ability to fully address users’ safety concerns. For our next steps, we would go beyond having users feel “just as” safe using the app as they would connecting with strangers without it, designing and implementing a more robust set of safety features. Based on user feedback, we would recommend:
Providing more information to users about what happens when they report another user, such as how reports are reviewed and at what level action will be taken
Designing an identity verification process (e.g. government ID upload, face scanning/verification, or cross-verification with other social media apps)
Integrating safety tips or other safety options besides reporting in case of extreme security issues or situations where users feel unsafe (i.e. the Uber model)
Redesigning the matching process so users only receive notifications when there is a mutual spark (i.e. the Tinder model). This could help alleviate concerns about tension arising from dismissing or rejecting a spark.
latest prototype
Without further adieu, I am very pleased to present the latest version of the Spark prototype that features all of our design implementations:
many thanks
Thank you, reader, for spending some quality time with this case study! Eternal gratitude to the rest of the design team: Sarah Meltzer, Lucien Lewis, and Herbert Sutton. Last but not least, my deepest appreciation to Spark co-founders James Bender and Khalil Simmons for the opportunity to work together.