When working on the high-fidelity designs, at least one screen must showcase how the filters will appear and function. The filters should be clearly mapped out to ensure developers understand their behavior and layout. Keep in mind which component is m ...
User roles: They are represented by vertical columns (each user has their own space). Flows: Are represented by horizontal rows (each user's tasks/processes are stacked within their column). Labels help with organization: A bar at the ...
Keep it short: The screen name should be the name of the screen/view, so the name of the tab itself "Users", "Dashboard" etc. Plus, the specifics of what's showcased on the screen if we have the same screen in different stages/states. Step by step F ...
To maintain a structured and clear representation of project statuses, notes, and screen flows through color coding. This ensures all team members and clients can easily understand and track the progress and requirements of the wireframes. All ...
Once a Low Fidelity Flow (LF) is approved, we need to add a general "Expected Flow Outcome" note at the beginning of each flow. How to do it: Add a Logic Note at the start of the flow with the following: Color: Violet (to indicate it's logic-r ...
Guidelines for managing user flows and wireframes in separate files, ensuring clear documentation and efficient design processes in app development projects.
0% tolerance policy for typos in wireframes, this is due to the wireframe being a final client deliverable and to keep things professional. No grammar mistakes: Good grammar is essential across all communication—especially in wireframes. There sho ...
Once wireframe is ready for approval and final... Ensure that the client has comment access here: Inform the client that ordinarily, we do not grant comment access, but we are making an exception, trusting that their feedback will be minimal. Ad ...
The wireframe (WF) serves as the final reference and must accurately reflect all final decisions. Although it's not common, there may be rare cases where a "TBD" (to be determined) item remains on a flow or consideration after the WF has been approv ...
This checklist is the result of gathering information on what typically "fails" or needs to be reviewed before delivering a WF (ideally to the client, but at the very least, to development).Find QA checklist here: https://lowcode.plutio.com/projects/9gXo9 ...
This SOP explains how to use the right naming convention when creating new files for wireframing, emphasizing the inclusion of project names, add-ons if applicable, and specific tasks to maintain organization and searchability.
Follow these rules to ensure efficiency and speed in the design process by keeping wireframes simple and focusing on what can be quickly edited directly in Glide.
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 ...
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 alw ...
Since we track notes during the Low-Fidelity phase, we also need to do the same for High-Fidelity—this applies to both Bubble and FlutterFlow projects. Once the LF is approved, all relevant notes should be added to the Internal File for reference. ...
This SOP provides guidance on the recommended use of different UI elements. Choosing between pop-ups (modals) and drawers (side panels) depends on context, user flow, and the level of interruption you want in the experience. 🧱 Pop-ups (Modals) ...