I recently worked on a discovery project at Cookpad. Product discovery is essentially the process uncovering what the customers, confirming there enough of them have the same problem and coming up with a solution that works for both the customers and the business.

As part of this process, I’ve been working with building user prototypes called live-data prototypes. In a live-data prototype, we don’t address performance or scalability, even automated tests are out of scope and for sure you can’t run a business on it. Instead, we are focused on providing the minimum measurable framework that shows evidence that the idea really works, or at least there’s enough value which could lead us to another idea or to continue iterating over the initial hypothesis.

The Prototype Goal

Make a user feel they are part of the recipe authors and cookers community. Finding meaningful connections with other users in the process. Make them know people do care.

The Prototype Idea

The idea that we want to implement as a prototype is the Top Fans List. Your top fans is a list of users that have an important affinity level with your recipes — usually, a top fan, likes, save, cooks and visits your recipes regularly.

Prototype Implementation

Rather of creating complicated structures in relational databases that may prevent me from doing quick iterations over it, I decided to go with a more flexible data store. In the past, I had the chance to work a couple of NoSQLs databases, like MongoDB — I even wrote my own MongoDB ODM(mini_mongo) — though the issue with Mongo is that we are not using mongo in Cookpad and since this was a quick prototype I didn’t want to invest DevOps time on it. The next option on the plate was Redis that I’ve used many times in the past building services and tools, such as leaderboards and prototyping a collaborative recommendation engine, using libraries like Ohm and redis-objects. Plus in Cookpad it’s already used and beyond simple cache or queue storage systems.

Redis is an open-source, in-memory key-value data structure store supporting powerful data types like Strings, Hashes, Lists, Sets, Sorted Sets, Bitmaps, and HyperLogLogs. In fact, we were using it already consequently didn’t require any infrastructure set up for it.

First Iteration: Strings

Initially what I did was declare a task for building and storing the top fan id list by user, so later on, it would be the matter of a simple SQL query by primary key likeUser#top_fans_ids and User#top_fans. Redis provides the SET command for storing a string specifying with a given key and GET retrieve the value of the key.

Note: Strings are really good for cache mechanisms. It’s possible to cache text or binary data in Redis, which could be anything from HTML pages and API responses [1]

Second Iteration:

After a few user interviews, we came up with the idea of highlighting the fan on the recipe activities feed, making easier to identify their fan while navigating over the recipe activities. For this, I decided to switch the data structure from String to Set to make the operations. Set by definition is a collection of distinct objects, the new commands here are:

• SADD: adds new members to the set skipping the duplicates
• SMEMBERS: returns the list of the Set elements by the key is given
• SISMEMBER: Returns true if a member is a member of the set at key. Otherwise, it returns false

Note: Sets are good for data filtering, data grouping, and membership checking.

Last Iteration

Finally, we came up with the idea of listing the fans in the most relevant way from the user’s perspective. Based on some data-analysis we gave each event weight or score and then we combined them by summing to know who was the most relevant fan. In this case, the most suitable data structure was Sorted sets. Redis Sorted Sets are, similar to Redis Sets, non-repeating collections of Strings. The difference is that every member of a Sorted Set is associated with score/weight. The new commands to use here are:

• ZADD: adds all the specified members with the specified scores/weight to the sorted set stored at a key
• ZRANK: Returns the rank of a member in the sorted set stored at a key. If a member does not exist in the sorted set or key does not exists reply with nil
• ZREVRANGEBYSCORE: Returns all the elements in the sorted set at a key with a score between max and min, ordered by score.

After many quick iterations with our live-data prototype and Redis, we were able to identify that most users didn’t realise that someone had interacted with their recipes a lot, even with the users who have a direct relationship or who were previously known. It was really good to explore if the data could be interesting or not, which is hard to get a sense of using other prototyping tools. Another interesting fact was that the user’s reaction could be different depending on the content itself. Our live-data prototype enabled us to validate the value separate to usability.

The prototype 🎉

Conclusion

Having Redis as part of our prototyping tool was a win, iterating so quickly and changing our hypothesis radically in most of the cases impacted our implementation, but with Redis, changing or adopting new structures was a very quick and painless job. Redis now has become one of the tricks up my sleeve when I need to rapidly prototype.

Special thanks to Sebastian Sogamoso, Miles, Guillermo Iguaran and Laura for the feedback!

References

[1] https://redisessentials.com/

[2] Book INSPIRED, How to Create Tech Products Customers Love