The operational problem and product value
Digitize the whole food movement, not only the act of giving.
The requirements describe volunteers and charity partners coordinated through messaging groups and calls, with participation certificates generated and distributed manually. That made it harder to track activity, keep partners informed and understand performance.
The product connects donation submission, review and inspection to inventory, allocation and distribution. Volunteer participation and verified hours sit alongside that operation. The strategy then addresses adoption: how donors return, volunteers become active and requesting organizations submit information that can be acted on.
The value model is an operating network. More reliable supply, suitable volunteer capacity and better request information can improve the flow of food. Recognition and communication support that network; they cannot substitute for fulfilled work.
| Value layer | Product mechanism | Intended benefit |
|---|---|---|
| Operational | One record from donation through distribution | Less fragmented coordination and better traceability |
| Partner | Clear requests, decisions, schedules and status | More predictable collaboration |
| Volunteer | Event discovery, attendance, verified hours and certificates | Easier participation and trustworthy recognition |
| Contributor | Impact visibility and recognition based on verified actions | Reasons to remain involved |
| Leadership | Role-specific reporting and operational exceptions | Better planning and resource allocation |
Requirements baseline; product strategy
Different roles, different needs
The platform serves people contributing, organizations requesting and staff controlling the operation.
The strategy contains composite personas for donor, corporate, volunteer, requester and future beneficiary audiences. They are planning lenses, not evidence of completed field interviews. The requirements and prototype provide the stronger basis for explaining each role’s actual task.
| Segment | Need | Product response |
|---|---|---|
| Individual donor | Know what can be donated and what happens next | Eligibility guidance, structured submission, review status and handoff instructions |
| Corporate donor | Coordinate surplus safely and report contribution | Company registration, scheduled collection and contribution reporting |
| Volunteer | Find suitable opportunities and have service recorded accurately | Eligibility and capacity visibility, QR attendance, training status and certificates |
| Requesting organization | Request the right food and understand the decision | Structured request, official letter, status tracking and resubmission guidance |
| Charity partner | Accept work within real transport and storage capacity | Collection details, accept/decline controls and distribution confirmation |
| Supervisor | Make timely decisions with accurate stock | Inspection, inventory, near-expiry alerts and allocation controls |
| Admin | Maintain access, suitability and attendance integrity | Role governance, volunteer review, manual exception validation and audit history |
Role requirements; composite strategy personas
Three doors, shared operational foundations
Give, Help and Request organize the proposition; review and fulfillment make it work.
The launch request flow in the requirements is for organizations, including charity partners, government entities and labor accommodations. A private individual assistance journey is a later strategy proposal requiring policy agreement. Keeping that boundary explicit prevents a compelling future concept from silently expanding the current service promise.
Give
A donor checks eligibility, submits the applicable food, money or fridge-partnership details and receives the relevant next step.
Output: A reviewable contribution request
Inspect and record
Food is checked for condition, quality and accepted quantity before it becomes available stock.
Output: Verified intake with a traceable inventory batch
Help
Volunteers discover eligible opportunities, register and receive tasks subject to training and operational readiness.
Output: Suitable participation and verified service records
Request
Registered organizations provide their needs and supporting information for Supervisor and Director review.
Output: A decision with a visible status and reason when action is required
Allocate and complete
Available stock is allocated, collected or delivered, then confirmed with actual quantities and proof.
Output: Updated inventory and a recorded distribution outcome
Donation, inventory, distribution and food-request use cases
Product choices and rationale
Trust and operational clarity shape the experience choices.
| Choice | Behavior in the materials | Rationale and boundary |
|---|---|---|
| Eligibility before effort | Donation guidance appears before submission | Reduce avoidable submissions without replacing the inspection decision |
| Automation with fallback | Barcode/catalogue or OCR may populate food details; manual completion remains available | Use automation to reduce effort while preserving a dependable path |
| Training as an assignment gate | Food-distribution assignments require completed hygiene training | Turn a safety rule into an explicit readiness condition |
| Verification before recognition | Hours require attendance validation; contribution recognition uses verified activity | Celebrate completed work rather than unverified intent |
| Progressive request guidance | A proposed completeness meter and bilingual examples explain useful detail | Help organizations produce actionable requests without claiming a proven turnaround improvement |
| Recognition without financial prizes | Impact Circle uses badges, certificates, milestones and titles | Build belonging without a transactional reward model |
| Privacy in the request experience | The strategy separates assistance from feeds and competition | Keep vulnerable need away from recognition and public ranking |
Functional requirements, recognition design and proposed experience enhancements have different approval maturity. They are shown together as product decisions, not as a single shipped release.
Requirements; Impact Circle design; revised product strategy
Scope and release logic
The roadmap separates operational coverage from engagement depth and policy expansion.
The requirements cover eleven modules: account, events, volunteer participation, dashboards, attendance, awareness requests, donations, inventory, distribution, food requests and public services. This is the operational spine of the product.
The revised strategy groups the experience backlog with MoSCoW priorities. It places donation presets, eligibility guidance, impact visibility, request completeness, QR flows and notifications in the proposed launch experience; team participation and additional sponsorship mechanics come later. It explicitly excludes peer-to-peer food listing, donor selection of specific beneficiaries and cash-value rewards from the first-year proposal.
| Planning horizon | Scope | Reason to sequence it | Gate |
|---|---|---|---|
| Operational foundation | Role access, donation review, inspected inventory, distribution, attendance and organization requests | Establish a reliable service record | Business rules, data readiness and integrations |
| Launch experience proposal | Give/Help/Request entry, guidance, recognition visibility and notifications | Make the operating platform understandable and useful | Agreed experience scope, recognition rules and release readiness |
| Engagement depth proposal | Team volunteering, institutional participation and fridge sponsorship | Increase repeat participation after core use works | Capacity, consent and measurable adoption |
| Individual assistance expansion | Private individual request journey and additional public languages | Extend access while protecting dignity | Policy, partner routing and service support |
Release windows and targets in the strategy are assumptions for review. They are not deployment evidence.
Requirements module map; proposed roadmap and MoSCoW scope
Stories with acceptance conditions
A useful backlog defines the service rule and the failure path together.
These acceptance conditions are derived from the documented use cases and business rules. They show how product ownership can make scope reviewable for design, development and testing. They are not a claim that all corresponding tests have passed.
Traceability connects the story to the relevant rule: approved attendance before certificates, training before assignment, valid stock before distribution, and auditable reasons for workflow decisions.
| Story represented in the requirements | Acceptance condition derived from the use case | Exception to include |
|---|---|---|
| A donor checks eligibility before submitting | Relevant acceptance and handling guidance is available for the selected donation type | Missing catalogue or OCR data leads to manual completion |
| A volunteer joins an event with remaining capacity | Registration validates eligibility and open slots; the board updates capacity | A full event prevents registration |
| An admin approves attendance and hours | Only validated records contribute to certificate issuance | Missed checkout and no-show records enter manual review |
| A supervisor assigns food-distribution work | The selected volunteer has completed hygiene training | Assignment is blocked with a clear reason when training is incomplete |
| A supervisor allocates stock | Allocated quantity does not exceed available inventory | Cancelled distribution restores reserved quantity; partial delivery records actual quantity |
| A requesting organization submits food needs | Mandatory information and the official request letter are validated | Rejection or resubmission requires remarks; status changes notify the requester |
| A partner completes distribution | Actual quantity and proof are recorded before completion | Delayed collection is visible and can be rescheduled or reassigned |
Functional stories, use cases and business rules
The prototype makes the service tangible
The public front door and role workspaces translate the requirements into understandable actions.
The homepage concept invites participation through six clear entry paths: food donation, volunteering, financial support, locations, awareness requests and partnership. Arabic and English content support the same participation model. Public information can be explored before entering an authenticated role workspace.
The donor concept separates overview from creation: evidence capture, saved drafts, review status and the assigned handoff window. The volunteer concepts separate planning, training and profile readiness from live work. Supervisor and admin views distinguish field decisions from governance rather than giving every role the same dashboard.
The bilingual request guide provides a concrete service-design artifact. It contrasts vague requests with useful descriptions of need, quantity and unit, people served, timing, official documentation and receiving arrangements. The proposed request-completeness interface brings that guidance into the product.
| Prototype surface | Task emphasized | Connection to requirements |
|---|---|---|
| Public homepage and services | Choose a participation route and understand eligibility | Public information and access before registration |
| Donor overview and submission | Capture details, photos and a handoff plan | Donation review and scheduling |
| Volunteer events, training and profile | Commit, prepare and keep operational identity current | Participation, attendance and eligibility |
| Supervisor workspace | Inspect, prioritize, allocate and schedule | Donation, inventory, distribution and awareness operations |
| Admin workspace | Review users, roles, attendance exceptions and events | Access and governance |
| Charity collections | Accept work within capacity and confirm the handoff | Partner participation and distribution evidence |
The provided pages identify themselves as interactive prototypes with sample data and no backend connectivity. Displayed counters and activity records are illustrative.
Homepage and role prototypes; bilingual request guide
Dependencies and stakeholder decisions
Release planning depends on identity, data, operational rules and a credible service promise.
The requirements make external authority verification conditional on available integration capability. The strategy separately identifies meal methodology, launch timing, communications governance and individual-request policy as open decisions. A roadmap should expose those gates rather than treating them as implementation details.
My confirmed product-delivery responsibility is backlog, sprint and release ownership. These materials support explaining how that work connects to requirements and decisions. They do not establish Food Bank production release results.
| Decision or dependency | Stakeholder responsibility | Product implication |
|---|---|---|
| Donation and hygiene criteria | Food safety and operations specialists | Agree guidance, inspection and training gates |
| Review and authorization | Supervisor, Director and operational owners | Define decisions, reasons, resubmission and status transitions |
| Identity and role access | Digital delivery and identity providers | Verify each account type and restrict permitted actions |
| Notifications and location services | Digital delivery and service providers | Agree channel behavior, delivery failures and usable location data |
| Existing volunteer and partner records | Operational and data owners | Prepare consistent records and migration decisions |
| Meal-conversion methodology | Finance and program leadership | Set a published basis for estimates and preserve historical values |
| Individual assistance scope | Policy and partner-service owners | Confirm access, privacy and routing before expanding the request door |
| Launch communications | Product, operations and communications | Tie campaign timing to readiness and capacity |
Requirements dependencies and interfaces; strategy open decisions
A measurement model that can be defended
Separate the operating result from the estimate used to recognize contribution.
The recognition model fixes the meal value at the time of giving and labels it as an estimate. A later rate change should not rewrite historical contribution or demote a contributor. Operational distribution records and estimated contribution counts answer different questions and should remain distinguishable.
The strategy proposes separate adoption funnels for Give, Help and Request, plus experiments for donation defaults, share cards, completeness guidance and first-shift commitment. Those are test hypotheses. No completed experiment results or measured uplift are claimed.
| Measure | Definition or source | Use |
|---|---|---|
| Completed distributions | Distribution records with actual quantity and completion evidence | Track delivered operational work |
| Contribution meal estimates | Meal-equivalent fixed using the published rate at the contribution date | Show consistent contribution progress without implying exact deliveries |
| First-submission approval | Requests approved without resubmission divided by submitted requests | Test whether completeness guidance reduces avoidable rework |
| Request turnaround | Median time from submission to decision | Identify queue and review friction |
| Volunteer activation | New volunteers who complete a first shift within an agreed cohort window | Distinguish registration from participation |
| Volunteer repeat | Volunteers with repeat verified shifts within an agreed period | Measure durable participation |
| Rescued food | Accepted food quantity recorded in inventory | Track usable supply rather than self-declared donation volume |
| Operational exceptions | Near-expiry stock, delayed collections, missing attendance and unassigned work | Show service reliability and resource gaps |
The source strategy contains proposed targets. Public copy uses the measure definitions and does not publish unvalidated targets as outcomes.
Impact Circle measurement rules; proposed KPI and experiment framework
Product boundaries protect trust
The governing rules are part of the product, not a final review checklist.
Food that fails inspection cannot become available stock. Expired and damaged quantities stay out of distributable inventory. Attendance exceptions need review before hours become recognition. Assistance decisions need reasons and visible status. These constraints define what users can trust.
The recognition design keeps public visibility opt-in, preserves historical achievement and separates honorary titles from entitlement. It also has a deliberately limited membership scope: recurring registered contributors are different from anonymous walk-up giving and operational rescue agreements. That distinction needs to remain clear when the strategy is translated into release requirements.
The artifacts suggest a useful lesson for product delivery: connect adoption to operational capacity. A successful campaign that produces more requests, volunteers or surplus than the service can handle damages the same trust that brought people in. Guidance, verification, exception handling and capacity-aware rollout belong in the release conversation.
| Risk | Product response |
|---|---|
| More demand than the operation can fulfill | Stage adoption, expose capacity and retain assisted support |
| Recognition attached to unverifiable activity | Use inspection, approved attendance and auditable completion |
| Contribution estimates presented as exact deliveries | Publish methodology and label estimates consistently |
| Organization and individual request scopes become mixed | Keep the current workflow and future policy-gated expansion explicit |
| A reward layer changes the humanitarian meaning | Use recognition rather than cash-value incentives |
| Prototype data becomes a performance claim | Present concepts as illustrative and measure live behavior separately |
Business rules; recognition governance; strategy risk register
Make the homepage an adoption tool
The public proposition gives visitors three strategic doors: Give, Help and Request. Each door has to explain the relevant contribution or request without making the operational rules disappear.
The marketing and partner materials propose education, participation and partner onboarding. The strategy treats recognition as acknowledgement of verified contribution, not a cash-redeemable reward. A complete request is also an adoption problem: people need to understand what makes it ready for review.
My 1 October progress update records the final homepage design as ready and eight full scenario wireframes completed. Those are design outputs; they do not establish a live launch or campaign conversion result.
People and needs
Composite stakeholder models from the product strategy. They describe needs and roles, not a validated interview cohort.
Donor
- Goal
- Make a meaningful contribution.
- Friction
- Knowing that the contribution reaches people.
- Experience need
- Verified delivery and understandable impact.
Volunteer
- Goal
- Belong to a purposeful community.
- Friction
- Finding a useful role and knowing what to do.
- Experience need
- Clear participation paths and operational coordination.
Person requesting support
- Goal
- Get help with privacy and dignity.
- Friction
- Urgency, effort and exposure when asking for help.
- Experience need
- A private, low-friction request journey.
Key screens & project artifacts
Outcomes and learning
Operational modules in the requirements baseline
Full scenario wireframes reported complete on 1 October 2026
Give / Help / Request strategy entry points
The evidence establishes product requirements, a revised strategy, role prototypes, homepage direction and eight reported scenario wireframes. Strategy and GTM material remains a leadership-review plan; production deployment and measured social impact are not claimed.
The homepage earns attention. The service earns trust.
About the evidence
- Requirements, recognition design, revised strategy and role prototypes have different maturity. The public case distinguishes specified behavior, proposed enhancements and illustrative UI.
- Source material includes internal review documents. Public copy omits private contacts, approval details, speculative market figures, budgets and unpublished commercial arrangements.
- No portal/app Jira data is attributed to Food Bank. The broader Dubai Municipality portal is a separate product stream.
