Bubble High Fidelity Designs

Once the Low-Fidelity design is approved, we move on to creating the High-Fidelity screens. Below is a step-by-step guide on how to proceed with this phase of Bubble high fidelity screens.

Instructions:

1. To create high-fidelity wireframes for apps in Bubble, we usually use the Airdev Canvas template and Elemium. Therefore, we recommend downloading the Figma file for this template as soon as a new high-fidelity project begins. The file is frequently updated, so it’s best to always work with the latest version.

Airdev:

Get latest Airdev Canvas Figma file here
Find complete AirDev Canvas Library here


Elemium:

Get latest Elemium Figma file here
Doc to learn more from Elemium 

2. Immediately after downloading the file, the first step is to save it in the corresponding team folder using the following naming convention:
LowCode/ {year}/ {Project Name}
For example: LowCode/ 2024/ Internal App.


Once the file is created, please transfer the file ownership to: catalina@lowcode.agency

If the team doesn’t exist, you must create it. If you encounter any issues with creating teams, please reach out to Catalina for assistance.

3. Create the pages* we’ll need to organize everything related to the project:

✅ 01. Project Cover


⭐️ 02. Project App Designs


🎨 03. UI Kit & Grids


📁 04. Brand Assets & Design Elements


🗑️ 05. Drafts [Ignore]



These are the pages we usually create, but additional pages can be added if necessary.

4. The next step is to customize the file with the client’s branding elements.

This includes:

• Colors: (using variables).
• Typography (if applicable).


It’s generally recommended not to modify the typography, as it is already configured across all sizes. Additionally, developers build directly in the Airdev Builder, referencing the Figma file but not using it directly. This can sometimes lead to inconsistencies in ‘unconfigured’ fonts. However, if the client specifically requests it, we can replace the default typography (Inter) with any font, as long as it’s available on Google Fonts, without exception.

File Pages:

✅ 01. Project Cover: 

The Project Cover is created to ensure that when accessing the team, the project has a clear cover page, making it easy to identify. Additionally, it serves as an 'introduction' to the project. Make sure to set the cover as the project's thumbnail.

To set it as the Project Thumbnail, select the frame, right-click, and choose the option 'Set as Thumbnail'.

⭐️ 02. Project App Designs

This is where we will include the app screens designed by us.

Some screens come almost pre-built 'by default', such as:

• Log In / Sign Up
• ‘Add Your Details’
• Account Settings



All we need to do is add the client's logo, apply their design, and, of course, make sure the fields match what was defined in the low-fidelity wireframe. 



🎨 03. UI Kit & Grids

To assemble the UI Kit, we need to have the 'styles' configured. Once the screens are built, we will collect as many elements as possible that we used to create the screens and include them in this section. Be sure that the elements are organized according to their function (e.g., Buttons, Inputs, Cards, etc.).

We will also include elements from the Atomic pages—components that you believe will be present in the app, even if they aren’t part of the presented screens (refer to the low-fidelity wireframe for this!).

Grids

At the developers' request, the screen size must be set to 1440. The default screen sizes in AirDev Canvas are not configured to this size, so we need to adjust them ourselves. Important: The sign-up, log-in, and account settings screens do not need to be modified; we can use them as they are. 

📁 04. Brand Assets & Design Elements

In this section, we will include everything the client has provided for us to create the designs. This might includes:


1. Logo (and its variations)
2. Graphic elements, if applicable
3. Images (ask if they have any images we can incorporate into the app)
If the client doesn't provide images and we want to find some to make the app more visually appealing, we must ensure they are free and copyright-free.
4. Color palette and how it is implemented (if applicable)

It is very important that once the client provides their colors (and their implementation, if available), we perform an accessibility check to ensure that the contrast of the implementation meets accessibility standards. For this, we use the website Who Can Use and take screenshots to support our decision or to show the client how their colors align with this issue.

🗑️ 05. Drafts [Ignore]

In this section, we will include everything that we don’t want the client to see, such as drafts, trash, etc.—things we want to delete permanently but don’t want to store in other folders.

What we usually save there are drafts of the process to keep a record, but it’s up to each designer to decide how much 'material' to save. For example, if we change the color of a button, we don’t save that as evidence, but if there are changes to sections and/or layouts, it’s advisable to keep a history.

🚦 Status bars

To keep the wireframe organized, we need to assign statuses to the screens we are designing. The statuses are as follows:

🗒️ Comments & Notes

Just like in the low-fidelity wireframes, we can add notes in the high-fidelity ones, maintaining the same color-coding used in the low-fidelity versions.

For notes you can use the following Plug-in: Notely ✍🏼 | Sticky Notes

👤 Client File Copy

To share the wireframes with the client so they can provide feedback or simply view the progress of their project, we don’t share the working wireframe. Instead, within the team, we create a separate file where we build these pages:

• ✅ 01. Project Cover

• ⭐️ 02. Project App Designs

• 🎨 03. UI Kit & Grids

• 📁 04. Brand Assets & Design Elements

• 🗑️ 05. Drafts & History [Ignore]