CONCEPT
1. Use Case
Many people experience stress and time pressure around birthdays, holidays, and other gift-giving occasions. This often happens because they lack a central place to collect gift ideas, struggle to remember previous ideas, or simply do not have enough time to plan ahead. As a result, last-minute purchases are common, and gifts can feel generic or impersonal.
GIFTLY aims to solve this problem by providing users with a dedicated space to store, organize, and track gift ideas over time. Users can categorize ideas by recipient, occasion, and priority, allowing them to plan ahead efficiently. By offering reminders and easy access to saved ideas, the app reduces stress, prevents forgotten occasions, and increases the likelihood of meaningful, well-planned gifts.
2. Target User
The target users are busy students and young professionals with active social lives who regularly buy gifts for birthdays, holidays, and other occasions. These users often feel pressure due to limited time and competing responsibilities, making gift planning challenging.
Users are typically comfortable with mobile apps for organizing everyday tasks and value simple, intuitive tools that streamline planning and reduce mental load. They appreciate features that save time, provide helpful reminders, and allow for quick addition or adjustment of gift ideas. GIFTLY is designed to support these users in maintaining thoughtful and organized gift-giving habits.
3. Prototype
The prototype was developed in Figma to visualize the initial app concept and to support early usability testing.
This high-fidelity prototype demonstrates the core functionality of GIFTLY, including creating and organizing gift
ideas, tracking occasions, and navigating between screens. Insights from testing this version informed design
improvements and helped shape the final app interface.
View in Figma
4. Database
The Giftly app uses a SQLite database with Room ORM to manage and persist data locally on the device. The database architecture consists of three main entities that work together to provide the app's core functionality.
4.1 Overview
- Database Engine: SQLite with Room persistence library
- Database Version: 2
- Database Name: giftly_database
- Primary Key Generation: Auto-increment integers for all entities
- Date Storage: Unix timestamps (Long type) for birthDate and event dates
4.2 Entities
4.2.1 PersonEntity
Stores information about individuals for whom gifts are being tracked. This is the central entity that connects gifts and calendar events to specific people.
| Field Name | Data Type | Constraints |
|---|---|---|
| id | Integer | PRIMARY KEY, AUTO_INCREMENT |
| firstName | String | NOT NULL |
| lastName | String | NULLABLE |
| birthDate | Long | NULLABLE (timestamp) |
| notes | String | NULLABLE |
| photoUri | String | NULLABLE (file path) |
4.2.2 GiftEntity
Stores gift ideas and details associated with specific people. Each gift must be linked to a person, allowing users to organize their gift ideas by recipient.
| Field Name | Data Type | Constraints |
|---|---|---|
| id | Integer | PRIMARY KEY, AUTO_INCREMENT |
| personId | Integer | FOREIGN KEY → people(id), NOT NULL |
| name | String | NOT NULL |
| price | Double | NULLABLE |
| link | String | NULLABLE (URL) |
| notes | String | NULLABLE |
| isGifted | Boolean | DEFAULT FALSE |
| hashtags | String | NULLABLE |
4.2.3 CalendarEventEntity
Stores important dates and events, which can optionally be linked to specific people. This flexibility allows for both person-specific events (like birthdays) and general calendar events.
| Field Name | Data Type | Constraints |
|---|---|---|
| id | Integer | PRIMARY KEY, AUTO_INCREMENT |
| title | String | NOT NULL |
| date | Long | NOT NULL (timestamp) |
| personId | Integer | FOREIGN KEY → people(id), NULLABLE |
| notes | String | NULLABLE |
4.3 Entity Relationships
The database implements two main relationships that define how the entities interact:
PersonEntity → GiftEntity (One-to-Many)
One person can have multiple gifts associated with them. Each gift must be associated with exactly one person, as the personId field is required (NOT NULL). This ensures that every gift idea is organized under a specific recipient.
PersonEntity → CalendarEventEntity (One-to-Many, Optional)
One person can have multiple calendar events. However, calendar events can also exist independently without being linked to a person, as the personId field is nullable. This allows for flexibility in tracking both person-specific occasions and general calendar events.
4.4 Entity Relationship Diagram
