Project Management Apps
By Airdev, creators of the Canvas building framework
Project management applications help teams coordinate their efforts to get more done together. The classic setup involves breaking projects into individual tasks, each of which has an owner and deadline. Team members can update and track task statuses as they work toward completing everything on time. More complex setups can involve goals, milestones, subtasks, and other more sophisticated structures. The category has proven to be a natural fit for a web application, since multiple team members need to access and update the same information. Popular examples include Asana, Monday, JIRA, Trello, Wrike, and ClickUp.
Though the content below focuses on the data structure that supports the application under the hood, the user experience for a project management app is generally meant to be less linear (e.g., like an ecommerce website) and more free-flowing as users toggle between projects and tasks to collaborate and get things done. The app may include some of the following pages:
A homepage and supporting marketing pages to entice and inform potential users
A login page where users can enter credentials to access their portal
A personal dashboard, where users can manage their profile, teams, and get an overview of the tasks they are assigned (i.e., their to-do list)
A team workspace, where users can manage a team’s settings, members, and projects
A project board, where users can manage the tasks under a project (usually as a list, board, or table)
An account settings page, where users can update their credentials and technical settings
An admin dashboard, where app owners can access key metrics, users, and other key data objects to manage their platform
Data types recommended
The primary data object in a project management tool is the Task, which is something that needs to be done by someone (i.e., a User) by a deadline. In order to help Users find, organize, and complete tasks on time, project management tools typically organize them into distinct Projects, each of which has a set of Tasks. Projects can also exist within Teams, each of which has a set of member Users and Projects. Thus each User can see their own Teams, the Projects within them, and the Tasks within those.
User
An individual team member who can login to access their projects and tasks.
Suggested fields on this type
Email (text): the email address the user signs up with
Name (text): alternatively, you can separate first and last into two fields, and have a third representing full name
Profile picture (image): a nice mugshot to be displayed with their profile
Role (Role, an option set): role within the application (member, admin)
Teams (list of Teams): a list of teams the user is a part of (i.e., who’s projects they can access)
Suggested privacy rules on this type
Users on the same team can access one another’s info
Admins can access any user’s info
Everyone else can’t find or access any user info (since each team is a closed system)
Team
A group of individual users who work together on a set of projects and tasks.
Suggested fields on this type
Name (text): each team can have a name (e.g., Dunder Mifflin)
Owner (User): the team member who can edit the team, add/remove team members (this might start with the team’s creator, but the distinction could be transferred to someone else)
[Projects (list of Projects)]: another optional linkage, since each project has a team
Suggested privacy rules on this type
Users can access teams they belong to
Admins can access any team’s info
Everyone else can’t find or access any team info (since each team is a closed system)
Project
A single initiative (represented by a collection of tasks) to be completed by a team.
Suggested fields on this type
Name (text): each project can have a name (e.g., Public Launch)
Team (Team): the team that is working on the project
Owner (User): this might be helpful for tracking (i.e., where do Michael Scott’s projects stand?)
[Tasks (list of Tasks)]: this is an optional linkage, since each task has a project
[Completed tasks (number)]: sometimes it’s helpful to pre-calculate a count of tasks for the project to make it easier to download project data and display metrics without lots of search expressions
[Total tasks (number)]: see explanation above – completed / total allow you to calculate percent completed
Suggested privacy rules on this type
Users can access projects within teams they are a part of
Admins can access any project’s info
Everyone else can’t find or access any project info (since each team is a closed system)
Task
A single action item within a project, assigned to someone from the team, with a deadline and status that can be tracked to completion.
Suggested fields on this type
Title (text): the high-level name of the task (e.g., “Purchase party hats”)
Description (text): a long-form description of the work to be done
Attachments (list of files): any images or files relevant to the task
Assignee (User): the team member responsible for the task
Deadline (date): when the task is due
Status (Status, an option set): the current stage in the process the task is in
Project (Project): the initiative the task is a part of
[Team (Team)]: this is an optional linkage because the task’s project will be associated with a team, but sometimes it’s easier to create the direct link to make privacy rules easier
Watchers (list of Users): any team members who want to be notified of changes to the task (e.g., the assignee’s manager)
Tags (list of Tags, an option set): any labels the task fits into (makes filtering tasks easier)
Suggested privacy rules on this type
Users can access tasks within teams they are a part of
Admins can access any task’s info
Everyone else can’t find or access any task info (since each team is a closed system)
Option sets recommended
Role (users)
Member
Admin
Having an option set for high-level application roles is useful for any application. In this case, it helps to separate standard users from administrators. This will affect what data the user has access to, and whether they work within their team workspace or an admin dashboard. Note: this is different than team-based roles or project-based roles. In this MVP setup, we’ve assumed each has a single owner, but you could use a separate option set to define roles at those levels.
Status (tasks)
New
To do
Doing
Done
Assuming you want to use the same set of task statuses across the application, it will be easiest to use an option set. This makes it easier to adjust the list later without disrupting existing data. Note: if you want to allow for custom statuses by team or project, you would move these to a data object so they can be edited on the fly from within the app.
Tag (tasks)
Urgent
Bug
Feature
etc.
Assuming you want to set the tags that tasks can be labeled with across the application, it will be easiest to use an option set. Note: if you want to allow for custom tags by team or project, you would move these to a data object, for the same reason as for statuses above.
Example uses in your app
On the personal dashboard, searches may include:
My tasks: Search for Tasks where Assignee = Current User and Status <> Done, Sorted by Due Date (ascending). This will start with overdue tasks (i.e., with due dates in the past) and proceed to nearest upcoming tasks.
My teams: With the data structure above, this can be done directly as Current User’s Teams (using the list field). Alternatively, it can be done as Search for Teams where Members includes Current User (this condition isn’t strictly needed since privacy rules will only allow a user to see their own teams, but it can be helpful anyway).
On the team dashboard, searches may include:
Projects: This can be done directly as This Page’s Team’s Projects (using the list field). Alternatively, it can be done as Search for Projects where Team = This Page’s Team.
Members: This can be done directly as This Page’s Team’s Members (using the list field). Alternatively, it can be done as Search for Users where Teams includes This Page’s Team.
A selected Project’s tasks: This can be done directly as Parent group’s Project’s Tasks (using the list field). Note: “Parent group” assumes you’re showing the list within a group that has a data type = Project, which you change the value of when a user selects a project. If you are using a board/Kanban view, you may have a repeating group of lanes/statuses, where the data type is the Status option set and each cell has a search for tasks with that status.
Additional notes
Project management software can get very feature-rich in order to satisfy the needs of the broadest range of teams and projects. In addition to the basic structure above, below are a few common features you may want to include in your database structure:
The ability for users to post comments within a task to collaborate
Custom fields on a task, either at the team or project level
A history of updates for a task (e.g., status changes, edits to name/description, reassignment, deadline shifts)
Custom statuses / tags for each team or project (as described above)
Subtasks (i.e., the ability for tasks to be nested under one another)
Project management tools are sometimes white-labeled, so each team can have their own copy on their domain. Bubble supports this through their “sub-app” feature. If you take this approach, you can create the app assuming just one team, and create a copy for each team.
About the author: Airdev
Headquartered in San Francisco, we have spent the past 7 years developing a unique process for bringing ideas to life using Bubble. This includes:
A globally distributed network of the best Bubblers in the world
A building framework (Canvas) that provides best-in-class design and functionality to every app at 10x the speed
A custom process facilitated by our Bubble-built project management tool
Last updated
Was this helpful?