At SWARM, an app design and development company in New York, we love to run experiments and try new things. Some of our experiments like the SWARM Weather Watch Face have even been featured in app stores like Google Play.So when defining PartyUP Player (PUP) into an MVP (minimum viable product), we came across an interesting problem while streamlining this new app. The user base was strongly divided into multiple defined categories. Namely, “casual gamers” and “hardcore gamers”. But, we figured it’d be fun to run an experiment to test the hardcore gamer’s level of engagement. All this, in as little time as possible.

Problem: Build a product that engages the hardcore gamer to post a LFG (looking for group)?

First: Competitive Intel – We looked at services like “Destiny LFG” that try and help pair gamers with each other via a long form list and we sought to identify what they were doing to drive user engagement, and what made them successful.Fundamentally, these services had the user fill out mandatory form fields (walling) before letting them post a LFG request, whereas others were relatively easy to use (frictionless).Second: Keyword Research – Then, in order to make our experiment easily findable we did a keyword density and SEOT (Search Engine Optimization Traffic) competition search, narrowing the prospective url down to (Looking For GamER) for the product.

Once we had the domain, we threw up a quick landing page. Next, we went back to these services and identified those elements that the frictionless sites were doing best. We also analyzed each site’s architecture. As you would expect, each site relied on a database (db) to store and pull information. While db’s are great, their architecting can take considerable time so we decided to scrap that all together. Third: Hack and Build—We started looking into easily accessible services, that included the ability to store data. We also had an anonymous open source twitter app called SWARMsecret. Eureka!Send the form’s “POST” request to Twitter as a URL (see below).

How to Do It:

All the data needed to build this app was stored in the URL that Twitter shortened.Serendipitously, this created a benefit to the user that we hand’t initially explored. Each LFG request was turned into a tweet containing a hash tag #LFG and #gameName. Sweet – Network effect!We then defined six popular games for Steam, Playstation and XBOX and built individual pages for each game tied to it’s own twitter account as a “datastore”.We slapped on a design layer, made it responsive(ish) and wrapped the whole thing in a WebView for Android, and iOS (we’re probably not going to publish these as they just weren’t that good).Total effort by two team members to roll – about 20 hours total. 


Product wise, there are issues with LFGER. No information architecture (IA) led us to circle back time and again on decisions – adding and removing components.Starting this process with an IA and thinking through the product would have saved us hours in the end, meaning we could have rolled it quicker, it would have been more complete, and in all likelihood designed better.

Since there were no designers on this project, there was also no real UX or UI. This resulted in a product that felt sloppy and had no real or concise interaction feedback for the user. Because this is a web-app, it doesn’t have the same smoothness on mobile that there would be on native. Things like -webkit-overflow-scrolling and overflow-y:scroll were very buggy on iOS 8, but more on this later.The lack of IA fundamentally meant bugs upon bugs. Doing a proper IA workup in the beginning would have solved all this. The experiment shows just how important IA is.


Nothing about what we did is production ready, but we still want to see if people will use it. If they do and it gathers traction we can then build something more stable. Test quick, fail fast.You can use twitter as a data store (ha!) albeit only for 2400 pieces of data a day (although special resections apply).Even though publications like the FT have great HTML5 mobile apps, developing for an optimal mobile performance you should go native. It solves a lot of issues still present in mobile browsers. Most importantly, before you start a project, do the IA, always do the IA. We’ll update with results here a few months after the launch.