In March 2015, I founded a startup called Nomster. I was inspired about the power of gamification and how gamification could change habits, retain engagements and improve experience. Nomster started out as a mobile app that engages users to eat healthier through gamification. Think ‘Tamagotchi’ (the digital pet that grows/dies based on how good you take care of it) meets healthy Yelp. Serendipitously, I pitched to Singapore’s largest broadcast centre Mediacorp and was so fortunate to receive their investment and incubation. This began my amazing journey that taught me more than I could ask for. To run a startup, however, was not as easy as I thought.
Having little technical understanding of software development at that time was a huge challenge in itself. Who do I need to build the application? What are my technical needs? How do I optimise my timeline, developing the MVP? How… do I go about managing the development, business and users? Managing my first technology startup during college was demanding. While I was trying to find co-founders, I consulted several product managers and mapped out my team needs.
Software developers in Singapore are scarce and costly. I could outsource all my development and focus on user experience and the business side, but starting this venture was more than a learning experience for me than anything else. I knew I know too little to begin with, but at that time, I wanted to learn and challenge myself as much as I could so I decided to find and manage my own team. I went to Ho Chi Minh City, Vietnam and talked to dozens and dozens of software developers. Finally, I built my team of 5 – a Unity developer, PHP developer, designer, project manager and marketing.
Conceptualising the story
We defined the general direction of the application and interface, and wireframed the user flow. The more a user discover and enjoy healthy food around their vicinity, the more progress they can make in the captivating game and characters.
As we start to prototype, we focused on the ‘Tamagotchi’ monster – that was central to creating the concept of ‘feeding’ healthy food to your monster. You could interact with your monster – in our case Nom-ster – by tapping, swiping or moving it. Our initial response to the interaction with the nomsters were amazing, it was akin to taking care of a pet.
The Nomster character (akin to ‘Tamagotchi’)
Alpha version interface
Alpha testing user flow
On clicking ‘Nom’, users could see discounted food and eateries around their vicinity. To verify that the user visited and purchased at the merchant’s outlet, the merchant will enter a unique 4-pin code and the user’s nomster will be fed (it will be regained back to 5 lives!). If you fail to feed your nomster long enough, it will get upset or sick along the way. With full lives, you can play more mini games, rake up points and level up.
At the start of prototyping, there were many considerations that we struggled: What constitutes healthy food? Macdonald could be serving salad and that dish could be considered healthy too. Would the interaction between user and merchant (or the restaurant’s server) be awkward since there is a quick exchange of phone to enter the 4-pin code? How about QR scanning or beacon technology? Eventually, we decided to reach out to accessible (regardless of how ‘healthy’ they are) merchants to onboard them to the app and 4-pin code seems to be the familiar mode of verification with our users. We wanted to get started to test the interaction first.
As a startup with limited budget and time, it was challenging to conduct in-depth focus groups and interviews with potential users. Through convenience sampling, we gathered some initial qualitative feedbacks after the first usable prototype was developed. Many of the users loved the interface, the graphics and most importantly, the mini games – it was short, addictive and easy-to-learn (similar to ‘Doodle Jump’ or ‘Flappy Bird’). However, most of the users had lackluster responses to redeeming discounts and visiting merchants around the vicinity. Many users said “I would (redeem) if the discounts are enticing enough.”, “Maybe.. if the restaurants around my vicinity suits my appetite at that moment, but I will play the games – its super addictive!”.
That said, what were we missing here?
Plenty. Was convenience sampling the right way? Probably not. We were asking users who were in our age range (18, 19) and they were at the very end of the ‘young adults’ spectrum. It was not a representative sample of our target audience. Secondly, the mobile app was a ‘jack of all trades, master of none’. There was no focus for the user – is it a food app, or a game app? The interface seems to be more like a game, but the food discovery element is mandatory for monetization. Back then, measuring what was healthy (without knowing what users ordered) was unmeasurable. But testing the prototype without the ‘healthy’ element to it, almost defeats the purpose.
We were trying to do too many things, all at the same time. We wanted users to be able to have fun, enjoy deals around their vicinity, check out different restaurants, interact with their nomster, and worse of all – know and learn that they could do all of that! Trying to display and show everything were at the expense of everything. It diluted the focus of the application and made the team worked on everything (web portal to manage all the deals, the mini games, browsing through the list of merchants, the map function and the list goes on).
Our attempt to monetize
We realized that the mini games were stealing a huge spotlight from the food discovery element of Nomster (our monetization channel). What was interesting was our users were spending alot of time playing the games, trying to beat the high score and they love it. But, they only visited the merchants if they won a free meal (yes! you can win a free meal by just playing our games) or a highly discounted meal (e.g. 1 for 1 deals for a high value meal, not just a drink). That was a problem – to sustain, we need to start monetizing well.
Apart from having native advertisements through mini games and avatars, we also updated the interface to improve on the redemption process. After a couple of times ‘mystery shopping’ and redeeming deals at random restuarants, we realized a couple things with the 4-pin code feature (though some other food application still uses it):
- It’s hard for service crews to remember 4-pin codes to so many different food app
- F&B has a high turnover rates for service crew, that meant training and retraining staff to remember how to handle redemption methods across different mobile application
- Easy to abuse the system. Once a user sees what the 4-pin code was, he could type it by himself the next time without spending.
Leave a Reply