FlutterFlow High Fidelity Screens

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 FlutterFlow high fidelity screens.

Just a heads up when designing in HF: 1px in FF does not always equal 1px in Figma, but overall it should be similar

Instructions:

1. To create high-fidelity wireframes for apps in FlutterFlow, we have created the FF Template, which will make the design process faster. This library has also been created in FF and will help devs to gain time, because they will no longer need to focus on thinking how design will look and being able to see it there

Get latest Figma file FF Template


2.When you have started the High Fidelity phase, duplicate the file FF Template and save it in the corresponding team folder using the following naming convention:
LowCode/ {year}/ {Project Name}
For example: LowCode/ 2024/ Internal App.


Once the team is created, please transfer the file ownership to: catalina@lowcode.agency. If you encounter any issues with creating teams, please reach out to Catalina for assistance.

The FF template pages will only exist in the Internal File. The client file will not contain those pages

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]



💱 06. Icons 

🧩 07. Components

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

⚠️ Important: This file will belong exclusively to LowCode and will not be accessible to the client. The high-fidelity wireframe we share with the client will be a separate file, containing only screens related to the project and no "Canvas" elements or pages. The client file will contain: 
  • ✅ 01. Project Cover

  • ⭐️ 02. Project App Designs

  • 🎨 03. UI Kit & Grids

  • 📁 04. Brand Assets & Design Elements

  • 🗑️ 05. Drafts [Ignore]



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

This includes:

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


Typography: ideally from Google Fonts.  If the client wants some particular font, and they have the file ready, we can use it. But if we're designing, let's choose from Google fonts

🔔 Important note: The file that we customize is the ‘Internal’ file, not the Client file.

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.

Use this template by copying and pasting it into your own Figma file.

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.

Use this template by copying and pasting the elements that you need it into your own Figma file.

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

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. 



Confirm with the project manager which screens will be designed. We normally design between 4-6 screens. Remember that the screens that we need to design in Figma are the ones that contain a yellow tag. 

Designers need to always add the HF screen for "Password successfully changed."


🎨 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!). We need to add all button instances, default, hover, active (while pressed) and inactive.

 

Use this template by copying and pasting the elements that you need it into your own Figma file. You will see that there are some notes to guide you.

It is crucial to add the Images section, this way devs can easily download them

Grids

FlutterFlow works with different sizes. When designing in mobile we need to design for Iphone 14 Pro 393px (width).

In the UI Kt & Grids we need to specify the:

  • Default border radius of components
  • Default padding for app’s structure

 


📁 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)
  5. Reference (any visual reference that the client has provided)

Use this template by copying and pasting the elements that you need it into your own Figma file. 

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

These notes don't have a native arrow; for connecting the notes to the components, please use this plug-in: Autoflow

To use it, open the plugin, then select the note and the specific component you want to connect. An arrow will appear linking them. As long as the plugin remains open, the arrow will move with the note. However, if you close the plugin and move the note, the arrow will stay in its original position. To re-enable movement, simply reopen the plugin

On the ⭐️ 02. Project App Designs you will will need to add the Comments & Notes section + the doc Before start developing 


👤 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]
As you can see, the pages are very similar to the internal file, with the difference that we do not include anything related to FF Template in this file (Foundation, Components, Page Templates pages should not appear). Page 05 (Drafts & History) may or may not be included, depending on the case. For example, if the client requested many changes in the high-fidelity wireframes, and this is causing delays in development, it would be a good idea to document this in the history. This way, the client can see that the delays in the development process are a result of all the requested changes.

When sharing the file to the client, make sure they have ‘View Access’ so they can view and write comments.

 


Was this article helpful?
© 2025 LowCode Internal Docs