In the age of data-based, web application products, the simple task of using a search function in an app can feel overwhelming. How do I narrow down my search? What if I only know one delimiter? What if, after I apply all my filters, there are still tons of options? Although there’s power in offering app users an abundance of data, the amount of data itself can actually get in the way of the app’s goal: simplifying the user experience.
So, how do we help a user make a choice without completely eliminating their options? During my eight- week fellowship with Code for Philly, one of my goals was to resolve this exact issue with the development team for the Choose Native Plant Application. The Choose Native Plant app is a web/mobile friendly application (set for launch in spring 2022) meant to help new gardeners in Pennsylvania identify native plant species they can select for their garden beds. More native plants means indigenous pollinators will frequently visit your garden, and more pollinators means more native birds too! All of this sums up to a healthier local ecosystem in which we can all thrive a little bit more.
The PA Choose Native Plant team aggregated about 1000 plant options from which users can currently select. But, if you’re anything like me, it can feel difficult to even identify a starting point. I know my plants will get good sunlight for a quarter of the day, but what if it needs more moisture than my area usually gets? Will the plant attract bees (which is a good thing by the way)? So, with this in mind, I developed a scoring system for all of the plants in the database to help our users make a choice.
The scoring system is comprised of six total categories including but not limited to “drought tolerance,” “attraction to the monarch butterfly,” and “pollinator attraction.” Each individual category has its own spectrum of scoring with a maximum score ranging anywhere from 1.5 to 3. A category can be binary where it receives either a 1 or 0 (or in the case of the monarch butterfly a 0 or 2), arithmetic where it could receive a range of scores from 0 to 3 in increments of 1, or it could be categorical where qualities such as very good, good, or bad translate to values of 3, 1.5, or 0, respectively. Generally speaking for the arithmetic and categorical options, the increment size is the fraction resulting from 1/(total number of options). Below you can see a representation of how these scores are broken down. For reference, “local count” accounts for how many local nurseries sell the plant.
Each of these individual category scores are then summed together to result in the final recommendation score. The maximum score a plant can receive is a 15/15. Below is an example list of some of the categories and their associated maximum scores.
It goes without saying that there is a lot of subjectivity to this process. I selected high possible scores for drought tolerance due to the impending impacts of climate change. I gave the monarch butterfly option a big individual score of 2 since I was informed from our team’s resident plant fanatic that it’s a big deal in the PA plant community. I gave local nurseries a whopping maximum of 3 since we could help create traction at local business and connect local amateurs with plant experts (community building is always a win).
This post should act as a starting point to help you think about how to develop recommendation logic for your user-selected data/product. I myself am not a mathematics expert, but I wanted to pass along my amateur approach. Hope it helped!