Starting a Lo-Fi Wireframe

Purpose and Scope

This SOP outlines the process for managing user flows and wireframes in app development projects at LowCode Agency. It provides guidelines on how to handle these crucial design elements, ensuring clarity, efficiency, and maintaining the integrity of approved designs.

Definitions

User Flows: Diagrams that depict the path a user takes to complete a task within an application.
Wireframes: Skeletal outlines of an application that showcase the basic structure and layout.
LF Wireframe: Low-fidelity wireframe.

Responsibilities

Project Managers: Oversee the process, ensure clarity of user flows, and manage communications between clients and design teams.
Designers: Create and modify user flows and wireframes based on project requirements and feedback during the Refinement Phase.
Sales/Discovery Team: Provide initial scope and user flow documentation.

Procedure

1. Initial Documentation

Carefully review the written scope of work (added in Plutio and Slack by PM/BA)
Watch the Discovery Call attached in the scope
Review any additional files shared by the client in the scope

2. User Flow Review

Review the initial user flows for clarity and add any questions you have (your questions are key).
- If user flows are clear and there are no questions, proceed to step 3.
If clarification is needed, schedule discussions with relevant team members or the client.

3. Wireframe Creation

The WFs are created in Whimsical (is the visual workspace that helps us with team communication, building lo-fi wire frames, flow charts, mind maps, sticky notes and documents.

Guides

The basics

Wireframes

Docs

Start the wireframes in the Userflows/Wireframes file (embeded in the whimsical scope)
Designers can start working on wireframes as soon as their workload and priorities allow, even if some aspects of the user flows are still unclear.

4. Iterative Design Process

As designers work on wireframes, they may identify questions or potential improvements to the user flows.
Document these questions or suggestions and discuss them with the Project Manager.
Update the user flows in the wireframe file as necessary, but keep the original user flow file unchanged as a reference.

5. Final Documentation

Once the wireframes are completed and approved (by the client), ensure that the user flows in the wireframe file accurately reflect the final design.
The original user flow file serves as a record of the initial approved design, while the wireframe file contains the most up-to-date flows.

Important: 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 approved.

If the WF has already moved into development and that TBD is resolved during the process, it is our responsibility to update the WF accordingly. This is essential to ensure alignment between the WF and the final app, and to prevent any confusion during the QA phase.

Exceptions and Special Scenarios

For smaller apps or projects with very clear initial user flows, the Project Manager may decide to start with LF wireframes immediately and skip any questions on user flows.
In cases of significant flow changes, consult with the PM and Client and get their approval before proceeding with major wireframe modifications.