Posts

JustGo: Your personal fun planner

I love everything related to planning – whiteboards, to do lists, excel sheets and so on. I plan my weekdays for maximum productivity on work and personal aspects. But somehow, I really suck at planning for my spare time on weekends. Usually, making plans with friends or family is limited to fixing a time and a place to meet. But when we actually meet, we end up either going out to the usual places for drinks, food or a movie. And every time I ponder why aren’t we able to explore so many interesting places and things to do in my city?

On introspection and discussing with my friends and colleagues, I discovered the main reason was decision fatigue. Most of my friends including myself suffer from so much decision fatigue during our daily work and personal life that we are too exhausted to plan for fun. No doubt, we want to have fun, but planning for it becomes a chore.

Next, I tried to search for an app or a website that would help me solve this problem – A service that’ll curate a mini-itinerary based on my interests for spending my spare time during weekends or evenings. I explored multiple event discovery apps but with them I still had to take many decisions and do some form of research before finalizing what to do. What are the available options? When is the event happening? How far is it? How does the traffic look like?

Why can’t be there a service which does all this work for me? And if such a service would exist, what would it look like? Let’s have a look.

What would be required to create JustGo and how would it look like?

As you might have started guessing by now, success of such an app would depend on getting access to rich data on multiple aspects – users, potential activities, weather, traffic, etc. The quality of user profiling, availability of relevant data points about activities and accurate data on external factors like traffic, whether conditions, etc would be essential to come up with good enough recommendations to motivate users to outsource the decision making process to an app.

To understand how all the data would come together and help the user in having the best experience every time he goes out for fun, let’s split the entire design into four key modules – The user profiler, the activity curator, the concierge and the executor.

 

Just Go modules for personal time planner

P.S. If you wish to skip any design details and are interested to see how JustGo would look like to the end user, I would recommend skipping directly to the third module, The Concierge. (Click Here to skip to The Concierge)

Module 1: The User Profiler

This module would be responsible for collecting and collating the data on the user and then map the user into different categories. But to understand a human using data to the extent of being able to mimic decisions on his behalf is not a straight forward task. Some of the data points that every data scientist working on the algorithms of JustGo would love could include:

JustGo: User Data Attributes

While some of the data would be readily available with social media and search engines (..but why would Google or Facebook share this data with JustGo? Well, I’ll answer this question at the end of the article), there are many attributes that will need to be specifically asked from the user. But getting the user to fill so much data is a daunting task for an app. Any friction leads to a high drop-out. So maybe instead of being a full-on survey – the data gathering would need to be split into fun questions or games across a period of app usage.

One key point to note is that these data attributes mostly capture persistent attributes of a person i.e. they might not change for years for most people. The non-persistent personal attributes (mood, energy level, etc) would be handled by the third module, The Concierge.

To avoid getting too much technical, let’s say the module would then use the data and prepare micro personas (mostly numerical values and not any human understandable labels) with the help of machine learning algorithms which will then be consumed by the The Concierge module later on.

Module 2: The Activity Curator

Once we ‘know’ our user, we need to know the set of activities and experience that can be presented to him. The Activity Curator would work to create a database of activities – places, events and experiences that can be matched with the user’s taste and requirements. This list of would need to capture all the data attributes that humans either explicitly or implicitly use while deciding to participate in an activity. The following figure lists some of these attributes.

JustGo: Activity Data Attributes

Again, collating such detailed and accurate information for a large set of activities is a challenge. While we can design crawlers and invite users to act as contributors, it’ll take a lot of time and investment for a startup to come up with a usable build. But if talk about Google, it is one of the companies which have already managed to source quality data on businesses across all verticals. For them, it should be a straight forward task of identifying the missing pieces of data and then introducing simple touch points across their services to capture them.

Module 3: The Concierge

This module is going to be the face or the front-end of the service for the user. Whenever the user needs to look for recommendations on itineraries to go out, he just opens the app and punch in a few preferences – how much time does he have, how much money is he willing to spend and what kind of group is he planning the evening with. To stay true to its core value proposition, JustGo should only capture information which is more like facts at this point of time and shouldn’t force the user to make any kind of decision.

A rough wire-frame for the user could look something like the figure below:

JustGo: User Screen Wireframe

 

Once the user submits the information, machine learning algorithms will go to work to match the user profile and preferences with the available activity options, using the above inputs more as filters to come up with curated itineraries. After figuring out thousands of itineraries that fit in the above criteria, the user would be shown tinder like cards starting with itineraries that has the maximum expected experience score (the parameter that the machine learning algorithms would strive to most accurately predict). The algorithms to calculate the experience score would need to be designed to mimic human decision-making using aspects like:

  • Relevance to the user: Everyone might not enjoy an art exhibition and similarly everyone might not visiting loud pubs
  • Quality of the activity: Not everyone would like to visit a pub with a deteriorating ambiance even if it offers really cheap drinks
  • Experience of getting to the activity: There would users who would love to go on a long drive to a specialty diner but not when there are traffic jams on the way
  • Contextual decisions: Preferring indoor activities in case of rains or if it’s too hot, avoiding highly crowded places and so on.

Once the algorithms have completed their calculations, the user would be presented with tinder like cards, each containing one of the curated itinerary, in decreasing order of the expected experience score. Let’s have a look at the wire-frames of some of these cards, each representing the difference in outcomes basis the different parameters selected by the user at the first screen:

Module 4: The Executor

If the user accepts one of the recommended itineraries, the service would need to integrate with a host of third party services to offer a seamless experience to the user. Some of them would include:

  • Booking an Uber ride/ starting navigation through Google Maps
  • Make reservations for movies, theaters and book tables at restaurants, etc
  • Enabling payments

At the background, the module would also need to work on gathering information to measure how closely did the user stick to the recommended itinerary and guess or ask the experience feedback to help in improving results in the future.

How would JustGo make money?

Although, launching a service like this would involve a lot of investment in collecting the data and getting the users to trust the accuracy of the suggested recommendations, but once the critical mass of user base is reached, the revenue avenues are tremendous through streams like:

  • Commissions on any bookings done through the app
  • Collation of user data (which is the oil of the future)
  • Business services to help newer experiences and businesses get included in the suggested itineraries

But why am I not making this?

First of all let me answer the question: why would companies like Google or Facebook share data with a service like this? Well, they probably won’t or may not be legally allowed to do so. And maybe that is the biggest reason I have not quit my day job and started work on the idea.

While a startup can device mechanisms to collate some of the data, a new organization is no match with the absolute wealth of data available with Google across users and businesses alike. In fact, I am sure that we can see such highly specialized contextual recommendation use cases maybe built within the Google Assistant. So this is a big shout out to the product people @Google: Please make this a reality soon! (I would love to help).

Buying a car in an AI driven world

Meet John, a creative designer for a leading fashion brand. His home is driven by IoT, with all major functional aspects monitored and managed through a personal assistant, Eli residing on his smartphone and smartwatch. With accurate data on John’s movements and habits, Eli’s AI algorithms are working behind the scene to automate an ever increasing list of daily decisions and activities performed by John.

For instance, based on John’s movements tracked through sensors in his smart watch, Eli knows John’s normal morning routine. Eli knows that the first thing John does after waking up is to brush his teeth, followed by exercise, shower and finally food preparation. Eli can accurately predict when John will step out of his home for work and times the booking of an Uber so that it is waiting for him when he reaches the roadside curb.

Now John decides that he needs to buy a car to use on weekends and asks Eli what options he has. After John tells Eli to refine the options based on his preferences, Eli books the test drive for the selected models as per his availability. Once, he takes a car for a test drive, Eli can sense that he likes a particular model based on changes in his body vitals like blood pressure, heart beat, etc. Eli then calculates how much loan would John require and starts negotiation with multiple financial institutions represented by their smart-bots respectively and arrives at the best offers suited to John within milliseconds. As soon as John completes the test drive, the option to buy the car is presented on the screen of his smartwatch, followed by a prompt to choose among the financing offers shortlisted by Eli. Few-taps on his smartwatch and the new car is delivered to John’s doorstep.

In the background, ABC bank’s bot, Sam received a request for an auto loan from Eli with all the relevant details of John. Sam calculates the risk profile of John and provides a competitive offer to Eli and once John accepts the offer, a smart contract is created between John, ABC bank, the car dealer and the bank managing the salary account of John. Since, the ownership of the car is governed by the smart contract, physical hypothecation is not relevant anymore. A portion of John’s salary is automatically blocked for repayments towards the car loan as soon as it is credited to the salary account. To handle situations resulting in financial hardship, the smart contract already provides for a suitable mechanism to provide options for John to seek a repayment holiday and arrange funds. Any irresponsible behavior or deliberate actions to avoid the repayments would automatically lead to transfer of ownership of the car to ABC bank and penalty details & default alert broadcasted to all accounts linked with John to recover the loss incurred by ABC bank.