Katamari App

Memes Aren't User Research

"how do i read a recipe online without reading the author's life story first"

"Recipe bloggers like to write their entire life story before the recipe"

"Imagine a world where you click on a recipe page and it’s just the ingredients and instructions and not someone’s life story"

If you're on Twitter, you've probably read thousands of variants of this meme. Riding this wave of anti-blog sentiment, a team was formed to create a platform called Recipeasly for finding recipes stripped of stories and ads. Based on all the above tweets, this idea was a slam dunk.

Of course, it wasn’t. By basing their project on memes and not consulting the food bloggers doing the work, this team missed the trade-offs that bloggers had made to grow a loyal audience and earn a profit.

This example is about as macro as you can get (even gaining some national attention), but this meme-guided go-it-alone phenomenon can occur at any level; within your company, or even just within your team.

For instance, consider the decision to build a monolithic app instead of a collection of microservices. All new services and feature requests make their way into this app. Think Katamari Damacy, but an app. One could envision a food blog-like situation happening here. Similar to the recipe meme,

  • Trade-offs are made. Developers decide that the cost of building a monolithic app is worth not having to repeatedly solve networking, architecture, and deployment issues.
  • People are separated from the trade-off decision. Time passes, turnover occurs, and eventually, the developers working on the app aren't the same developers who made the original trade-off.
  • Memes catch fire. Most complaints are expressions of frustration with little in the way of solutions, “KatamariApp is a black hole!” The memes focus on the disadvantages so much that the advantages are ignored or forgotten.
  • Someone takes action. Thanks to the popularity of the meme and lack of context around the trade-off, someone gets it in their head that building the next feature or service outside of the monolith will be a good and popular decision.
  • Blowback! Despite the frustration developers have with KatamariApp, it was still better than maintaining a separate service AND the monolith in tandem.

Memes are catchy and often entertaining, but infrequently (if ever) capture the full scope of the problem at hand. Memes are not user research.

It’s important to learn the history and context around the domain one is working within. It’s also important to collaborate with (or at least consult) those who might be affected by your work.

It would’ve saved the Recipeasly team a lot of trouble to interview some food bloggers, the backbone of the service they were pitching, to learn why they’d made the decisions they’d made. Food bloggers aren’t dumb and very consciously made trade-offs in the best interest of their businesses.

We also need to know about the trade-off decisions in the case of KatamariApp. Teams must be proactive by creating a decision log outlining why the app was built a certain way so that future maintainers can reference it and have a meme counterweight.