Davis Triceratops

Fall 2022, Year-Long Spark Project

CodeLab UC Davis
10 min readDec 29, 2022


Davis Triceratops is a UC Davis community built around daily scavenger hunts for crochet triceratops in Davis, CA. With a dedicated team with 35 members, their active Discord server boasts over 5,300 members. In addition to their scavenger hunts, they host social events, giveaways, design and art contests, and much more for their dedicated members.

Using Discord as the source of communication makes it difficult to keep track of the drops and miss notifications of the drops.

The Team

Vincent Barletta (Project Manager)

Abhay Thacker (Project Mentor) (not pictured) 😢

Jennifer Kim (Designer)

Camille Nikaido (Designer)

Sanjana Pethe (Designer)

Vibha Raju (Developer)

Abhimanyu Warrier (Developer)

Jamie Wu (Developer)

Terrell Wrice (Developer)

Abhimanyu Warrier (Developer)


Oct 2022 — Jun 2023 | 22 weeks

Currently, we are six weeks into development. As we approach the end of the Fall Quarter development period, this write-up is meant to mark our progress thus far into the year (as the quarter-long projects finish up).

Designer Timeline:

  • User research (Week 1–2)
  • Ideation & synthesis + user flow (Week 2)
  • Low fidelity wireframes (Week 3)
  • Design system & mid fidelity wireframes (Week 4–5)
  • Presentation (Week 6)

Developer Timeline:

Complete the development of the backend components and API requests (Week 1–4)

  • Make the login page with google authentication
  • Setup MongoDB database
  • Make User and Drops schemas in MongoDB database
  • AsyncStorage for locally stored data
  • Seeders to populate database with mock data

Upload and display images with AWS S3 Bucket (Week 4–6)

  • Upload and retrieve images from the AWS database
  • Setup Express to connect AWS to MongoDB
  • Create upload image and delete image UI components

Skeleton user interface (Week 5–6)

  • Mod Drop Form
  • Profile Page
  • Login Page
  • Onboarding Swiper Page


Figma: wireframes and prototyping

MongoDB: a NoSQL database to store user and cow data

Amazon S3: store all photos for dinosaur locations

Express: our web server

JavaScript: our primary programming language

React Native: mobile development

Node.js: backend development

The Project

While we don’t have a cohesive working app or full demo to showcase, there are some general UI screens and GIFs that show some working integrations between frontend and backend.


With Davis Triceratops current system of using Discord as the source of communication, it is difficult for users to keep track of the drops and they often miss notifications of the drops. In order to guide all future design, we asked ourselves:

How might we create a system that effectively organizes all drops, and deliver clear notifications for all drops?


Our target user base is the current Davis Triceratops Discord users and other active UC Davis students that want to get involved with the game. Through user surveys, we deduced some typical Davis Triceratops user personas:

  • Users are animal lovers and busy students that often use the scavenger hunts as a quick and relaxing activity to blow off stress
  • In addition, current users like using Discord as a platform to socialize and share their own art.

The central question that we aimed to ask when approaching a solution

Using Discord as the source of communication makes it difficult to keep track of the drops and miss notifications of the drops.

Feature Prioritization

After polling both over 400 users and moderators for their most request features for the app, the designers accumulated a very large list of potential features to include in the app to improve user experience.

The overwhelming response provided a lot feedback to incorporate in our design. The largest takeaways from current Triceratops Hunters was:

  • More clear notifications of the drops
  • Easy access to hints and location of drops

For moderators that currently crochet and hide the dinosaurs, they requested:

  • Easy organization
  • A convenient method to drop dinos and verify found dinos

Beyond these central ideas, we received many, many more miscellaneous suggestions for various extra features in the app to improve user experience. From this exhaustive list, we determined that some of the highest priority extra features were:

  • Google Maps API Integration
  • Grid and List View for Drops Menu
  • Total Dinos Hidden UI Indicator
  • Customizable Notifications
  • Tutorial Page
  • Achievement System / Hunting Statistics
  • Discord Integration

These features are currently sitting on our future development timeline. After finishing competitive analysis, user research, feature ideation, and synthesis, our designers began fleshing out an early design for the app’s rudimentary appearance.

Some rudimentary initial mock-ups for potential screens for Hunters and Moderators. Notice some features that eventually were not implemented, such as messaging functionality.

User Flows

Central to our design philosophy was simplicity. The users were clearly struggling with the Discord’s cluttered notification system, and the mods had difficulty with general organization across all of the servers.

For users, the initial flow went as follows:

Mods have a very similar flow, with the addition of having a drop button in order to allow them to place a new drop in the location of their choosing.

Low-fidelity Wireframes

From the Moderator user flow, we developed some lo-fis to reflect some of the primary screens for moderators, including the Home screen and the New Drop form.

Eventually, we decided to reduce it down to just the Drop and Profile Screens, as we deemed the Home screen created in lo-fis to be redundant. Instead, the rules button would be placed at the top of the users screen in the form of a small question mark button and the achievements would be displayed on the User’s profile page. The Dinos hiding would be displayed centrally on the Drops page itself.

Below, the updated Hunter perspective’s low-fi is shown. It has a finalized Navigation bar, along with a stylistic and interactive drop page.

Design System

For a project as fun and vibrant as Davis Triceratops is, we needed a color scheme to reflect that!

We decided to go with a light and colorful theme that reflects the fun scavenger hunt experience. Using off-white cream for the background, green for the navigation bar, purple for primary action buttons, and red for secondary actions, the app is meant to look both playful and bombastic.

We decided to use Poppins as our sans serif alternative for our font typography. As a result, our mid-fidelity designs look much more lively!

Mid-Fidelity Designs

Moderator View:

The largest discernible difference between the moderator and user views is the large Purple (+) icon between the primary icons on the navigation bar. This button allows a moderator to create a new drop, prompting the Edit Drop screen (shown on the right). In addition, on the regular drop screen, they are able to edit currently posted drop’s information by clicking the small red (Edit) button.

User View:

Here, we can see that the Rules Page and # of Dinosaur indicators have been moved to the top of the screen as small, unobtrusive icons. Upon clicking on a drop, you receive hints for the location as well as the verification code section.

The User’s Profile page displays their personal information, as well as their notification settings and dinosaur’s found statistics, two popularly requested features.

Next Steps

For next term, we will continue to refine our currently existing mid-fi designs as we approach the high-fi threshold and develop mid-fi designs for intermediary screens that have not currently been designed yet.


The user interacts with pages on our front-end app which makes API requests to our backend server. The server holds some local data and also consumes data about users, dinosaur drops, and locations from our MongoDB database.

Stage 1: Backend

Building a database

The first stage of development involved building out the backend, which will be dealing with managing user and dino data. To give the data more structure, we created schemas indicating what information will be in each object. For instance, user objects will contain their name, email, collected dinosaurs, rank (Moderator vs. Hunter), and more. The MongoDB database is where we save most of the user and dino data.

In order to upload photos of the dinosaur’s location to the application, we needed to setup a separate AWS S3 database.

Saving images in AWS

With the goal of creating a way for moderators to upload map screenshots and dino images, we had two key features in mind: the ability for images uploaded by a moderator to be linked to the relevant drop information and for hunters to be able to view drop-related images at any time.

We began by creating an S3 bucket and set up some user policies to allow our Express server programmatic access to handle uploaded images. Then, we developed CRUD API routes to connect our Express server, the existing MongoDB drop data, and the new AWS images data.

Interfacing these three tools was the bulk of the development, as there was limited documentation on how uploaded images in S3 could be reaccessed as MongoDB objects. Then, to link our image functionality to the concept of a drop, we expanded our existing Drops API to include any new API routes we created.

Finally, we implemented Signed URLs so uploaded images are immediately available to other users.

The tools and APIs used to manage how data is stored and fetched, are listed below.

API Calls (fetching and storing data):

  • Users API
  • Drops/Dinos API

Data Storage:

  • MongoDB
  • AWS S3 Bucket for photo storage
  • AsyncStorage for local data storage

Server Communication:

  • Express.JS

As for retrieving data on the client side, the user has to log into a UC Davis Google account before the frontend queries for the user’s data. The user’s schema will have a part to identify which Google account is linked to which Davis Triceratops user. The next step was to implement Google Authentication to identify if the user is a UC Davis student.

Stage 2: Frontend

Google Authentication

The first step in setting up Google Auth was to create a Google Cloud project. Within the project, we created 3 OAuth 2.0 Client IDs — one for the Android app version, one for the iOS version, and one Web App version in order to use Expo along with our app. Following this, along with the help of a few tutorials and the Expo OAuth Documentation, we set up the Google Auth request using the three client IDs within our React Native code. To test whether the request went through and a user was able to successfully sign in, we included a function to get the user’s basic data (ie. name, email address, Google profile picture) and display it on the subsequent to login page.

Along the development process, we did run into a few challenges regarding the lack of documentation with React Native. We had first set up Google Auth with a basic React web app, so we needed to transition our code to React Native. Developing in React Native for different mobile operating systems brought with it some difficulties; for example, we were required to generate an Android fingerprint and include it in our Google Cloud Project for Google Auth to work with the Android version of the app.

Various UI pages:

  • Login / Account Creation Page: Utilizes Google Authentication API
  • Onboarding / Tutorial Pages
  • Profile Page
  • Mod Drop Form: Accesses AWS S3 for photo uploads

We are using:

  • JavaScript and React Native to display all the elements on the screen
  • Axios for Users and Dino API calls

Next Steps

With most of the backend fleshed out, our primary focus for the next quarter will be creating the rest of the primary UI screens and adequately linking the backend calls to frontend requests. In addition, we will work extensively with the Google Maps API to create an interactive and reliable mapping source for dinosaur hunters looking for drops.

Takeaways & Challenges

Designer Challenges:

  1. Design systems phase — trying to create an application that is fun and welcoming, without making it look to childish
  2. Designing with ambiguity — we were trying to design some features while they were still not clearly decided on (e.g. — maps of how the radius will be shown)

Designer Takeaways:

  1. Designing with the developers in mind definitely changed many approaches of how we designed some features; we would try to simplify our ideas as much as we can in order to make our ideas more realistic and approachable for the developers.
  2. Having a well-established problem statement and How Might We allowed me to retrieve back to the main goal of the project whenever I lost my way within so many features that we listed.

Developer Challenges:

  1. Lack of documentation/resources — a lot of the onboarding resources were centered around React, rather than React Native. This caused a lot of issues with setting up Google Auth on a mobile platform. In addition, the resources for setting up AWS S3 utilized a different tech stack than what we were using.
  2. Relative sizing and font configuration — frontend development comes with many small quirks and facets that we will need to learn over the next coming quarters.

Developer Takeaways:

  1. Mapping out the desired data flow between technologies is incredibly important to fully understand the behaviors and desired interactions between multiple technologies.
  • Ask lots of questions!
  • Cross-team collaboration is very helpful for building on others experiences. We don’t need to reinvent the wheel every step along the way.


Thank you CodeLab and Davis Triceratops for giving us such a fantastic opportunity to built out a fully fledged app! It is not very often that developers and designers are able to work with each other on a large scaled project in typical academic settings. We are all really excited to continue working next quarter as we aim to build a refined and user-friendly mobile app for our dedicated dino hunters.



CodeLab UC Davis

CodeLab is a student-run software development and UX design agency at UC Davis.