Describe a user task before screens
Write a task as a person and a result: a coordinator reviews a request and assigns its next action, or a member submits a document and sees whether it was received. Identify the starting event and the evidence of completion. A list of screens without this purpose makes scope difficult to control.
Choose the smallest set of records needed for the task. Distinguish essential fields from information that might be useful someday. Name the person who owns field definitions and status rules. An initial portal can replace scattered tracking without attempting to become every system the organization uses.
Make roles and status explicit
List who may create, read, update, approve and archive each type of record. Check the difference between a staff user, an outside participant and an administrator. Access rules must apply at the data boundary, even if a user opens a direct link or sends a request outside the interface.
Use statuses tied to work, such as received, missing information, under review and completed. For each transition, identify the actor and the conditions required. Avoid making a status change depend only on the color of a card. Users should be able to understand what happened and what comes next.
Agree on acceptance and later phases
Prepare acceptance examples with normal input, a missing required field, a duplicate, a denied permission and a recoverable error. Ask a daily user to complete the workflow without developer guidance. Include the devices they use, the text they must understand and the time allowed for review.
Keep a separate list of future modules, such as payments, advanced reports or additional roles. Add them after observing use and reviewing cost and dependencies. A first portal should have a clear boundary and a handover plan; it does not imply a complete ERP or a native mobile application.
Bring this question to your project.
Use the explorer to organize your task and prepare a reviewed brief.
Prepare my project brief