Prepping Foursquare Swarm for the next 12B check-ins
Building Swarm 5.0 through experimentation, prototyping, sprints and user research
Last week we unveiled Swarm 5.0 on iOS, and today, we’re celebrating two additional milestones: we’re launching Swarm 5.0 for Android and we’ve just hit 12 billion check-ins.
We’re really proud of the product we’ve built and our accomplishments, particularly on a day like today. We hope you’ll check it out if you haven’t already.
As the product manager on Swarm, my role is to identify the most important problems to solve, and then work with everyone from design to engineering to make great products come to life. Today, I want to peel back the layers a bit and give some insight into *how* we transformed Swarm from the product it was eight months ago into the product it is today, and some of the product goals and decisions behind this redesign. This post will share insights and key learnings from this exciting (and sometimes) challenging process.
Focusing on Lifelogging
In Swarm 5.0, we refocused the product around lifelogging. Yes, lifelogging was always part of Swarm, but it was never central to the user-experience — it was more like a byproduct of the games, social interactions and other elements. (For more background on our shift in perspective, read this post from our co-founder Dennis Crowley about *why* we made this change, and this post from our designer Greg Dougherty about some of the design changes we made to bring this use case front-and-center.)
This entire process began when we conducted a quantitative user research survey with over 1,000 users to help us understand the core motivations for using Swarm, and the features that our community was most passionate about. The results were definitive: Swarm users rely on the app to keep track of all the places they go, and easily look back on those places. It was our job to redesign the product around the core use case of lifelogging, while maintaining the fun elements and personality that delight our users.
The Big Experiment
We knew a critical part of this redesign was finding the best way to elevate the user’s personal check-in history so that it was easily accessible. The key challenge we faced was that a user’s social feed had always been front and center in Swarm. De-emphasizing the friend feed and replacing the home screen with a user’s own check-ins was a radical idea, and would represent a substantial shift in how a user would perceive and interact with the app.
To better understand how users might react to an elevated personal check-ins feed before spending months redesigning Swarm, we ran an experiment to validate this new direction. In just one week, we put together a version of Swarm that made the user’s personal check-in history the first thing they saw, and the social feed secondary, with no other changes made to the app.
We ran this experiment on 10% of global Swarm iOS users to help mitigate risk. The goals of this experiment were to:
- Validate macro changes in behavior and feedback
- Quantitatively observe smaller changes in behavior that we could use to inform the broader redesign
- Monitor differences between US and international user behavior and reactions
The experiment results came back very positively. We saw increased overall engagement with the app and saw an increase in check-ins, too.
Two key behaviors surfaced as a result of running this experiment. First, we noticed that users were searching through their check-in history more frequently. This led to us refreshing and enhancing the search experience in Swarm 5.0. Secondly, we observed that a vast majority of app sessions resulted in exclusive usage of the two check-in feeds in the experiment. This insight played a large role in helping us refine and simplify our UX hierarchy.
More broadly, running this experiment gave us the confidence to move forward with a more thorough redesign, knowing that we could deliver an even better lifelogging experience for our users if we designed the entire app around this core concept.
Prototyping & Weekly Sprints
At Foursquare, our corporate mission is to create delightful experiences in the real world. Foursquare co-founder Dennis Crowley talked about using tech to make cities easier to use as early as 2009. So it’s always been top of mind.
We believe that motivating users to go out and explore the real world is a central part of lifelogging. We want you to quickly check-in so you can remember the moment, and then put your phone away so you can actually *enjoy* the moment. We challenged ourselves to come up with an engaging way to motivate users to get out and explore, in a way that would be valuable to them over time.
Over the course of seven weeks, we rapidly prototyped a bunch of wild and crazy ideas: all were different ways to motivate a Swarm user to continue to check-in and explore. We utilized weekly sprints to do this.
The goal for each week was to have a hacky-but-functional version of an idea done by the end of the week. Then, that idea got pushed into internal builds that all employees at Foursquare could test. This was critical because it allowed us to get great feedback from our in-house team of passionate Swarm users. As each week passed, this feedback gave us a better and better sense of what was and wasn’t working.
One idea from all this prototyping that ended up in Swarm 5.0? 100 collectible categories (read more about that here).
Once we had our final roadmap of all the features and changes that would comprise Swarm 5.0, we put together an ambitious plan that would allow us to redesign and rebuild nearly every screen in the app in under four months.
We continued to utilize weekly sprints through this period for several reasons:
- With so many moving pieces in Swarm 5.0, utilizing weekly sprints provided a simple way to organize and sequence all the work that needed to be done across product, design, and engineering. It was critical that everyone had what they needed at the right time, and using weekly blocks of work time allowed us to modularly rearrange our schedule without impacting our overall timeline.
- Weekly sprints timeboxed work, and forced us to make hard decisions quickly. There are differing opinions about whether or not you should timebox design and development, but I’m a firm believer in the mentality of “done being better than perfect,” especially when working on a project as large Swarm 5.0. Without timeboxing, the timeline for this effort could have quickly ballooned out of control, and it afforded us the opportunity to revisit hard decisions and change our minds once we had time to test things out, rather than trying to get it perfect in the moment before moving on to the next thing.
- We held a demo day every Friday, which gave the team targets for having core parts of a feature or project done and pushed to internal builds. This helped motivate the team through a long, challenging project by providing frequent intermediate milestones, and also generated company-wide excitement because the team had new features to test each week.
The biggest challenge with weekly sprints is that not all work fits neatly into a one week timeline, so you need to be flexible and regularly gauge when it makes sense to add extra time for a particular project, or push to finish by the end of the sprint.
User Research
As we were prototyping, we wanted to ensure that the ideas we focusing on were not just appealing to other Foursquare employees, but also to external Swarm users and prospective Swarm users.
We did this through two rounds of in-person research studies:
- The first session utilized functional prototypes to get feedback on motivational mechanics and overall usability. We were particularly interested in what existing Swarm users thought about the overall shift towards lifelogging and how that was reflected in the UX.
- The second round leveraged Invision prototypes to test onboarding and storytelling with prospective users. This helped us solidify the best way to communicate the value of lifelogging, and why people should use Swarm.
User research proved to be an essential part of Swarm 5.0’s development process in three key ways: It helped us narrow in on which of our prototypes was resonating with users; it provided surprising, unexpected insights such as the appeal of the interactive check-in map; and it offered confirmation that our simplification and updated style were resonating.
One key insight we took away from user research was that participants were frequently tapping on collectible categories, expecting to see which places they had checked into within them. This led us to embed the search experience across the app in a number of different contexts. So whether you want to know about the 373 Mexican Restaurants you’ve been to, or are curious as to how that 52-week streak at bars snuck up on you, all of those browse and discovery scenarios ultimately lead to searches, without the user necessarily having initial explicit search intent. This regular engagement with history search means that users are frequently reminded of the value of lifelogging.
If you’re considering doing user research, here’s my advice:
- Just do it. You will *always* learn something by talking to your current users, and even more by talking to users who aren’t yet using your product. It will challenge you to think about your product in ways you haven’t before. User research is incredibly valuable for observing behavior, seeing live reactions and emotions, and digging into why users feel a certain way about your product. Swarm 5.0 wouldn’t be what it is today without what we saw and heard in user research.
- However, it’s critical that you don’t overreact to or course-correct based on every point of feedback. You’ll often hear research participants say they will behave one way, but when looking at data in aggregate across your user base, in reality they behave quite differently. Be selective about when to make changes to your product from user feedback, and remember to uncover problems not solutions from participant feedback. Sometimes, it’s a better bet to validate user behavior by running experiments throughout the product development lifecycle.
Conclusion
Great consumer products don’t just provide a collection of features that help users do something. Rather, great consumer products tell a simple, clear story to users about why they’re useful, and then let well-designed features guide the experience. A well-crafted product is what we set out to achieve when we started thinking about Swarm 5.0. Everything needed to be deeply connected, and we utilized experimentation, user research, prototyping and weekly sprints to do just that.
It was an enormous effort across the entire team involving over 20 people, and we’ve built something we’re really proud of.
We hope you love it as much as we do, and that you use Swarm to remember all the amazing places you’ll go.
