A trade journey includes customers and reviewers
Montaji+ brings together food and consumer-product registration, import, transfer and export journeys. The service mapping distinguishes food traders, consumer-product manufacturers, food-business owners and health-related establishment owners.
Customers prepare product and shipment information, seek approvals and manage recurring work. Reviewers and inspectors need accurate evidence, clear queues, current standards, allocation rules and a usable record of decisions. Improving one side while leaving the other unchanged can preserve the same delay.
The programme documents support the wider service context. They do not assign every decision, interview or release item to an individual author.
Montaji+ services, personas and journeys mapping; interview notes.
Rebuild a usable design baseline
The workstream began with disconnected design files, incomplete flow documentation and weak traceability to user stories. Before detailed production could progress, the service logic and unresolved requirements needed to become visible.
The report identifies my contribution as auditing and restructuring inherited files, extracting and creating flows, and identifying gaps and ambiguities. Its summary records 59 flows: 28 in registration, 17 in import and 14 in export. These are reported workstream counts, rather than an independently audited measure.
The next working model gave me the requirements-to-design role: clarifying business intent, mapping stories to the right flows, preparing verified design briefs and reviewing functional accuracy. Detailed screen production was assigned separately, with both roles contributing to review and handoff.
| Workstream component | Evidence status |
|---|---|
| File audit, restructuring, flow mapping and gap identification | Reported as completed foundation work. |
| Business verification and story clarification | Prepared and scheduled in the report; later completion is not established by this document. |
| Role-based handoff and shared progress tracking | Proposed working model. |
| Functional and visual quality gates before development | Proposed review mechanism. |
| Detailed production and development-ready packages | Upcoming phases in the report. |
The full report contains inconsistent headline counts and domain wording. The public case uses the detailed 28 + 17 + 14 breakdown and the three named service areas, while keeping planned work separate.
Montaji+ Design Workstream report and executive summary.
Discovery across the customer and staff service
The interview guide sought to understand food import/export business models, the people involved and the needs and pains across their journeys.
The research plan used one-to-one interviews, in person or by phone, with permission required before recording. Journey-led discussion, emotion mapping and affinity mapping were included in the planned approach. The target of five to seven interviews per archetype is a recruitment plan, not a completed sample size.
The project file also contains dated customer and staff notes. Customers raised label-assessment effort, unfamiliar standards, repeated data entry, slow uploads, catalogue search, request-status uncertainty and fragmented document verification. Time-sensitive goods made approval and inspection delays consequential.
Staff notes expose the other side: manual allocation and reporting, unprioritised work, duplicate handling, standards scattered across sources, unpredictable inspection demand and delayed updates after site visits.
| Evidence from discovery | Implication for the service |
|---|---|
| Customers struggle to know the status and next responsibility. | Make progress and required actions visible after submission. |
| Product information and documents must be entered repeatedly. | Support catalogue reuse and a coherent document workflow. |
| Staff depend on manual queues and fragmented standards. | Design decision context, allocation and review tools alongside customer flows. |
| Inspection demand and timing are difficult to coordinate. | Include capacity, scheduling and on-site updates in the service model. |
Participant names, company identities, private volumes and verbatim interview quotations are omitted.
Montaji+ interview guide and dated interview notes.
Hear the differences between customers
Six original customer-note records describe recurring registration/import work, seasonal cosmetics importing and daily import/re-export. The June 2026 testing workbook captures bugs, pain points and suggestions from a partly overlapping group.
The findings include file restrictions, slow uploads, lost draft data, unclear barcode/variant rules, incomplete ingredient review, uncertain payments and limited filters/status information. Positive notes also describe fewer major issues after newer releases, visible modification reasons and rare support contact.
These records are not added together to make a larger research number. Session identity, cohort and task need to be deduplicated before stating a programme-wide total.
| Observed friction | Experience question |
|---|---|
| Lost work around draft/reopen or navigation | How can a customer recover without repeating entered information? |
| Variant and barcode uncertainty | Which item requires action, and what rule explains it? |
| Document and upload ambiguity | What must be prepared, and why is this input required? |
| Bulk and payment feedback | What was selected, reviewed, paid or still pending? |
| Status and SLA uncertainty | What happens next, who owns the action and when should support be used? |
Design beyond the submission screen
The import to-be blueprint connects Prepare, Check, Ship and Release. The export blueprint connects Prepare, Register, Issue certificate and Export. Both distinguish customer, frontstage, backstage and backend activity.
Guided preparation, catalogue/document reuse, role permissions, manual fallback, inspection and payment/certificate handoffs are service-design decisions. A target flow can be coherent even while some automation remains planned.
The simplified phase view below is an explanatory reconstruction from the original blueprint. Proposed timing/inspection comparisons in the original are not presented as achieved improvement.
Test a concrete trade task
A historical import-concept study involved five customer organisations: three food-only and two food/consumer; four were retail and one logistics. The study reviewed entry points, import data, Excel/catalogue products, documents, review/payment, the request page and green-channel clearance.
Adjacent original material explicitly records key-screen refinements based on customer feedback: import details, shipment-method selection and history. This provides a real research-to-screen iteration sequence, without inventing a numerical usability improvement.
The Sprint 11 review context is dated 14 August 2024. This study remains separate from the February 2025 follow-up and the 2026 customer records.
Resolve the states that cause rework
Original October 2024 material documents Back-navigation losing uploaded documents/products, unclear mandatory documents and a hidden required import purpose. The archive contains entry, document-revisit, add-product/purpose, review/payment and required-document states.
A later label-assessment failure modal demonstrates how an ineligible task was communicated. It is historical design evidence, not proof of the current production behaviour.
The design priority is to make a rule or failure understandable while preserving the customer’s work. Exact current remedies and a comparable retest are still separate from the original issue record.
Investigate why improved screens still fail to create adoption
A February 2025 feedback round focused on inactive consumer-product customers and barriers to adoption.
Customers noticed a clearer interface and improvements, but long review time still led them to return to the previous system. Missing capabilities and weak communication about recent releases also limited adoption.
The business lesson is specific: submission convenience and approval throughput must be evaluated together. A faster form does not remove a review bottleneck, and a released capability does not help customers who do not know it exists.
| Issue in the source summary | Frequency reported in the five-customer summary |
|---|---|
| Long request processing time | 5 of 5 |
| Import access or finding products in the catalogue | 3 of 5 |
| Registration renewal or amendments | 3 of 5 |
| Payment and document-upload problems | 2 of 5 each; the notes say these were working at the time of feedback. |
| Variant registration | 2 of 5; awareness and use of the new bulk capability were issues. |
This is a small qualitative follow-up, not a representative adoption rate. The source summary uses a denominator of five; no population-level percentage is inferred.
Consumer-customer feedback, February 2025.
Make operating rules explicit before delivery
Discovery records and staff feedback turn review and export processes into concrete product requirements.
The records show why a single generic approval flow would be insufficient. Food and consumer-product journeys have different review, evidence and certificate rules.
| Decision area | Documented rule or design question |
|---|---|
| Independent review | A second reviewer must differ from the first; approval and rejection require defined handling, with senior review for conflicts. |
| Assignment and capacity | Availability, request type and first/second-review capacity affect allocation; some assignment choices remain unresolved. |
| Concurrent work | A start-review mechanism should prevent two reviewers from working on the same request simultaneously. |
| Review continuity | Chosen remarks should persist, accumulate and appear in request details. |
| Export certificates | The flow differs by certificate purpose, catalogue eligibility, destination, shipment context and whether approval can be automatic. |
| Customer-facing status | Internal review stages should preserve a coherent customer status and a clear SLA model. |
The requirements contain unresolved items and later feedback. They are presented as decision work, not as proof that all rules were released.
Four-eyes discovery, export workshops and staff feedback.
Create a traceable design baseline
An original colleague assignment gave me the Product role for 23 February–13 March 2026: clarify requirements, prioritise must-haves, coordinate effort/progress and organise business design sign-off.
My 31 March update reports the audit/restructure baseline of 59 flows: 28 registration, 17 import and 14 export. Requirements/business verification, mapping and briefs were distinguished from detailed screen production.
A June 2025 audit also distinguishes Done, Pending and Prioritized items. Those states must not be flattened into a claim that all designs were implemented.
Measure the whole journey
For a registration/import task, useful measures include successful completion, repeat entry, recoverability, payment resolution and visibility of the next step. For the service, review throughput and support dependence matter alongside form usability.
These are measurement priorities grounded in observed problems. No fabricated survey total, aggregate customer count or current post-redesign uplift is supplied.
Working service archetypes
Explanatory archetypes reconstructed from the research grid, reviewed notes and staff context. They are not invented interview participants.
Recurring importer
- Goal
- Complete frequent catalogue and shipment work.
- Friction
- Repeated entry, variants, uploads and uncertain payment/status.
- Experience need
- Reuse, bulk handling, recovery and visible next actions.
Occasional registration user
- Goal
- Prepare compliant information correctly.
- Friction
- Learning requirements, category language and document rules.
- Experience need
- Early guidance and clear field-level feedback.
Service reviewer
- Goal
- Review accurate evidence and make a traceable decision.
- Friction
- Fragmented standards, manual allocation and duplicate work.
- Experience need
- Decision context, role permissions and clear handoffs.
Key screens & project artifacts
Outcomes and learning
Mapped-flow baseline reported in my March 2026 update
Customer organisations in the historical import-concept study
Original customer-note records reviewed, not total programme participants
The case establishes real customer/staff evidence, target service design, historical concept testing and screen refinements, plus a documented personal requirements-to-design contribution. Current final-screen, retest and production-impact claims remain outside the verified scope.
A strong service homepage gives people orientation before it asks them for action.
About the evidence
- Original customer notes, June testing workbook, Miro research copy, import/export blueprints, Confluence archive and personal handoff correspondence.
- Original transactional Figma links are retained internally. Historical screens were recovered from the archive; final current versions and after-change impact are not asserted.
