Reading the Brief
Identify the users, existing workflow, pain points, and constraints described or implied in an assignment brief. Distinguish explicit requirements from inferred needs and proposed implementation approaches, then translate validated requirements into testable acceptance criteria to ensure the implementation addresses the customer's requirements.
A dispatch lead receives a chart showing order counts. The chart appears complete but does not identify which orders require follow-up. A list of orders requiring follow-up, with unresolved records clearly identified, would help the dispatch lead prioritize the morning’s follow-up tasks.
Identify the customer's task, document explicit requirements, and define measurable acceptance criteria before selecting an implementation approach. A feature list alone does not demonstrate that the solution provides the information needed to make the decision.
Understanding the customer’s task
Consider this fictional brief:
Every morning, the dispatch lead reviews the daily order CSV, compares promised dates with the current date, and manually checks dispatch statuses to identify orders requiring follow-up. This manual process leads to missed follow-ups and repeated order checks.
Build a local tool that accepts an order CSV file and a run date as inputs. List all orders with a promised date earlier than the run date and a dispatch status other than
dispatched. Include orders with missing promised dates in the output and flag them as unresolved.Run the tool locally without transmitting CSV data to external services. Consider a dashboard as an optional interface.
Read it first for five things:
User: The dispatch lead.
Current process: Compare the daily CSV with today’s date, then manually check dispatch status.
Pain: Missed follow-ups and repeated checking.
Constraint: Operate locally without transmitting the CSV to external services.
Observable desired outcome: Identify orders needing follow-up while seeing which ...