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 and weak traceability to user stories. My documented contribution was to audit and restructure the inherited files, reconstruct flows and surface missing logic, screens and requirements.
The March 2026 report records 59 mapped flows: 28 registration, 17 import and 14 export. The later planning snapshot adds clearance and explicitly names food and consumer-product registration, while reporting 18 new user stories.
My role connects business intent to design readiness: map stories to their flows, compare the design with developed behaviour, prioritise the consolidated backlog and prepare briefs with verified rules, constraints and reference screens.
Directly credited work
Flow audit and organisation, requirements clarification, gap analysis, story positioning, backlog and design briefs.
Shared programme evidence
Customer and staff research, service blueprints, prototype scenarios and historical testing provide the wider context. They are not all claimed as individually authored work.
The new report’s phases and joint production model are shown in the delivery-plan chapter. Reported flow counts are kept in their dated context.
March design-workstream report; Project current state and plan.
Understand the work behind the request
Compare customer discovery, staff operations and empathy maps in one research workspace. Each original excerpt is paired with the experience decision it informs.
Recruit across business models and behaviours
The programme synthesis separates food and consumer-product research. Company size, activity, shipment frequency and complaint history helped broaden the perspective beyond a single type of trader.
Read the study & coverage analysis
Research coverage
| Research group | Activity reported | How to interpret it |
|---|---|---|
| Food customer discovery | 9 companies · 17 participating individuals | Programme research; multiple roles can represent one organisation. |
| Consumer-product discovery | 9 companies · 16 participating individuals | Separate group; cross-group overlap is not established. |
| Staff discovery | 16 interviews · 20 attendees | 9 food sessions and 7 consumer-product sessions. Some interviews had multiple attendees. |
| Historical import concept, 2024 | 5 customer organisations | A separate bounded concept study, described later in this case. |
| Dated customer records, 2026 | 6 original note records | Records rather than a unique participant total; later testing partly overlaps. |
Research method
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 planned target of five to seven interviews per archetype is kept separate from the completed activity reported in the synthesis.
These are programme/team research counts. The archive does not establish that I personally conducted every interview. Distinct studies and partly overlapping records remain separate.
The customer needs confidence as well as speed
The synthesis links navigation and repeated input to a broader service problem: customers need predictable decisions, understandable requirements and timely information after submission.
Read the customer insights analysis
From research theme to design response
| Research theme | Experience response | Service dependency |
|---|---|---|
| Repeated entry and complex forms | Progressive registration choices, artwork upload and editable product details | Reliable catalogue data, upload handling and validation. |
| Unclear requirements | Classification, document guidance and visible review information | Current rules and consistent interpretation by the service owner. |
| Late or unclear returns | Issue summary, contextual remarks and a guided amendment route | Structured review reasons and a clear resubmission state. |
| Uncertain progress | Request filters, status and next-action visibility | A trustworthy shared status model across customer and staff systems. |
| High-volume recurring work | Manual and Excel registration choices; reuse opportunities | Bulk processing capacity and usable reporting. |
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? |
The mappings explain the relationship between findings and supplied designs. They do not establish that every recommendation was implemented or that a customer KPI improved.
Design the review system alongside the customer journey
Staff discovery reports 16 interviews with 20 attendees across food and consumer-product work, including inspection, review, workflow and laboratory roles.
Read the staff insights analysis
Staff discovery coverage
| Group | Sessions | Operational contexts |
|---|---|---|
| Food | 9 | Airport, sea port, DIP and Hatta inspection; sampling, workflow and supervisory roles. |
| Consumer products | 7 | Public-health/quality review and laboratory roles, including analysis and specialist work. |
A service response, not just a dashboard
A sorted queue can help staff find work, but it cannot by itself fix unreliable integrations, unclear responsibility or missing standards. The blueprint therefore links customer steps to reviewer actions, backend capabilities and external handoffs.
The 20 attendees are not 20 additional one-to-one interviews. The source distinguishes session counts from attendees.
Connect the company’s goals to the person doing the work
The source maps separate business priorities from day-to-day interactions. Food-trade timeliness and consumer-product sales pressure can lead to different support and preparation needs.
Read the empathy maps analysis
Use the maps to guide decisions
Company maps explain why a delay or repeated request matters commercially. Customer empathy maps explain what the person sees, hears, does and needs while navigating it. Their design implications are a synthesis to validate through tasks and further research.
These are the original company and empathy-map excerpts. Their scenario descriptions are not additional participant counts.
Five original persona hypotheses
Original persona hypotheses based on exploratory rounds 1 and 2; the source planned further refinement in rounds 3–5. Names, portraits and biographical details illustrate the personas and are not presented as identifiable research participants.
Business owner · Maryam
- Goal
- Source products and grow the business without excessive operational effort.
- Friction
- Limited process knowledge, a small supplier network and language barriers.
- Experience need
- A guided start, clear preparation and visible follow-up.
Department head · Parveen
- Goal
- Coordinate the clearing team and keep clients informed.
- Friction
- Bulk clearing limitations, system slowness and difficult port coordination.
- Experience need
- Shared progress, reliable work queues and support for recurring volume.
Clearing agent · Nimesh
- Goal
- Clear shipments promptly and coordinate port-to-warehouse handoffs.
- Friction
- Many entities and touchpoints, delayed gate-pass communication and inefficient bulk tasks.
- Experience need
- A coherent sequence, useful status and clear responsibility at handoffs.
Logistics specialist · Yasser
- Goal
- Prepare documents and report shipment progress accurately.
- Friction
- Repeated requests, supplier label revisions and requirements discovered late.
- Experience need
- Central guidance, document reuse and recoverable requests.
Regulatory specialist · Rana
- Goal
- Assess product compliance across market requirements.
- Friction
- Differences between standards and fragmented domain information.
- Experience need
- Current reference information, traceable evidence and usable review context.
Connect the screen to the service behind it
The original to-be import blueprint follows Prepare, Check, Ship and Release across customer, frontstage, backstage and backend activity.
Guide preparation, then connect product and shipment work
The design separates getting ready, checking product compliance and submitting shipment details. Customer inputs connect to staff review, information reuse and external integrations.
Read the prepare, check & ship analysis
Read across the service lanes
| Lane | What the blueprint connects |
|---|---|
| Customer | Orientation, account access, product evidence, shipment information and next actions. |
| Frontstage staff | Review, assignment, customer clarification, inspection and escalation. |
| Backstage | Decision context, rule checks, scheduling, documents and notification capabilities. |
| Backend / external partners | Identity, trade/customs, laboratories, handling authorities and payment connections. |
This is target service design. Automation, integration and operational assumptions require service-owner and engineering validation.
Resolve inspection, exceptions and closure
Release includes different risk and inspection paths, laboratory testing, conditional outcomes and evidence of closure. It is not a single success message.
Read the release & full blueprint analysis
Keep the target separate from the result
The original contains timing and inspection comparisons to describe its intended direction. They are not a verified before/after result. The portfolio therefore presents the blueprint as a proposal and uses the measurement section to define what a later evaluation would need.
The earlier export blueprint is a separate Prepare → Register → Issue certificate → Export service path. It remains part of the wider archive rather than being represented by this import canvas.
Start with the customer’s registration intent
Five original screens show how the scenario narrows the task before collecting detailed product information.
The selected manual route sits alongside an Excel upload choice for different volumes of work.
Food is selected in this scenario. Consumer products and pet food remain visible alternatives.
The scenario selects retail for the local market before continuing into product classification.
A selected food subgroup narrows the information and rules required for the next step.
The selected route covers a product without an international barcode; a loose-item alternative is also visible.
Original supplied design prototype. Product, company, request, date and fee values are sample content. The screens document the design scenario; production implementation and measured performance are separate evidence.
Turn artwork into information the customer can verify
The prototype explores assisted input while keeping product information, ingredient review, documents and final confirmation visible.
| Decision to validate | Why it matters |
|---|---|
| Assisted ingredient entry | Define accuracy, customer confirmation, corrections and staff review before introducing the concept. |
| Submission versus approval | A receipt must explain whether the request is pending, approved or awaiting action. Confirm the eligibility rule behind each message. |
| Review and payment | Check the source of fee information, conditional choices and pending-payment behaviour against the verified business flow. |
The completed upload state identifies the two pieces of artwork supplied for the product.
An explicit scanning state communicates that the supplied images are being processed.
The original proposes reading ingredients with GPT, then asking the customer to check and edit them. This is a prototype concept, not a verified production AI capability.
The review screen brings product details, ingredients, declarations and fee or label-assessment choices together before submission. Values shown are prototype examples.
The supplied confirmation uses auto-approval wording. Eligibility and consistency with later review states require validation; this screen is not evidence that every registration is automatically approved.
Original supplied design prototype. Product, company, request, date and fee values are sample content. The screens document the design scenario; production implementation and measured performance are separate evidence.
Make a returned request actionable
The amendment journey keeps reviewer issues, supporting documents and the product’s information together, then distinguishes resubmission from a final approval.
This sequence responds to a recurring research question: what is wrong, what should I change and what happens after I submit the correction? A clear interface still depends on consistent review reasons, saved work and a trustworthy status model.
The issue summary identifies missing attachments and invalid information before the customer starts correcting the request.
Uploaded amendments sit beside contextual remarks and the previously submitted files.
The customer can update fields while keeping the relevant review remarks available alongside the form.
The review state gives a final check of the amended product information before resubmitting.
The confirmation explicitly says the amendment has been submitted for staff review.
Status and action filters support ongoing work. The original list illustrates approved, resubmitted, returned and in-review states with sample data.
Original supplied design prototype. Product, company, request, date and fee values are sample content. The screens document the design scenario; production implementation and measured performance are separate evidence.
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.
Translate scenarios into explicit requirements
The supplied Stories vs Design canvas maps shipment variants, field behaviour, business decisions and a 27-item validation list. It shows the detail needed between a service journey and a development-ready story.
Booked or arrived shipments use manual entry across Air, Sea and Land. A declared-shipment route adds integration and read-only fetched fields. Full re-export, partial re-export and transfers between emirates have their own eligibility, purpose and review paths.
These variants need traceable rules rather than a universal form. The source distinguishes a blocking error from a warning, validates duplicate declarations and suppliers, reconciles container counts and weights, and tracks different food and consumer-product review states.
The original also records a session-timeout/data-loss gap. Recovery belongs in the acceptance criteria alongside the happy path; the archive does not establish that the issue is present in the current live service.
| Rule area | Example in the source | Design implication |
|---|---|---|
| Conditional input | Shipment method changes documents, containers and fields | Show only applicable inputs and explain when a requirement changes. |
| Integration | Declared shipment fields can be fetched and read-only | Distinguish fetched facts from editable information and account for failures. |
| Data integrity | Unique declaration, supplier name/country, matching container count and consistent weights | Place specific, actionable validation at the relevant step. |
| Eligibility and routing | Different transfer, re-export and product-type paths | Validate the selected purpose and preserve independent review states. |
| Payment and continuity | Pending-payment handling, drafts and session recovery | Explain the remaining action and preserve the customer’s work. |
| Staff decision quality | Independent review, persistent remarks and senior escalation | Make ownership, conflict handling and the decision record explicit. |
Rules and known issues describe the supplied working specification. Release completion is not implied.
Stories vs Design; four-eyes discovery; export workshops and staff feedback.
Build shared language before building shared screens
The working glossary contains 192 numbered terms across ten domain categories. Its purpose is to clarify the vocabulary used in requirements, research and review.
| Reference area | How it supports the work |
|---|---|
| Shipping, customs and warehousing | Distinguish shipment, consignment, transport and storage concepts when mapping input and document rules. |
| Food, consumer products and labelling | Understand the product evidence and classification context customers and reviewers discuss. |
| Regulatory, quality and inspection terminology | Clarify review, testing and compliance concepts with the responsible subject-matter experts. |
| Trade finance and sustainability | Recognise wider commercial and disposal/re-export dependencies in the service journey. |
This is a working domain reference. Mentioned ISO or certification terms describe the domain; they are not personal certifications or current regulatory advice.
Glossary.pdf, supplied Montaji+ project folder.
Make the path to delivery reviewable
The new workstream plan places flow verification before detailed production, then uses shared review to prepare prototypes and sign-off.
A dated assignment gave me the Product role for 23 February–13 March 2026: clarifying requirements, prioritising must-haves, coordinating progress and organising business design sign-off. The March update reports a 59-flow baseline across registration, import and export.
The later supplied planning snapshot broadens the inventory to five domains: food registration, consumer-product registration, import/transfer, export and clearance. It assigns me flow organisation, flow-to-development gap analysis, story positioning, a consolidated design backlog and verified design briefs.
The revised collaboration model assigns detailed production jointly to the two designers. Business walkthroughs confirm logic and open questions; functional accuracy and visual consistency are then checked before prototypes advance to sign-off.
| Phase | Snapshot status | Responsibility / quality gate |
|---|---|---|
| 1 · Flow creation and organisation | 80% in progress | My assigned ownership; audit, organise and identify gaps across the five domains. |
| 2 · Design migration and alignment | In progress | My flow-to-development comparison, story mapping and backlog; shared review of updated context and effort. |
| 3 · End-to-end business review | Upcoming | Prepare walkthroughs and open questions; business confirms requirements and signs off verified flows. |
| 4 · Requirements and design | Planned | I prepare structured briefs; joint screen production and cross-review for functional and visual quality. |
| 5 · Prototyping and sign-off | Planned | My assigned prototyping responsibility after the preceding gates. |
This is a progress/planning snapshot, not proof that all five phases were completed. The report’s 120+ headline and 60+ detailed flow count conflict; the case retains the earlier detailed 59-flow baseline rather than choosing an inflated total.
Project current state and plan; dated role assignment and March workstream update.
Track capability readiness across the service
The planning deck also includes a programme scope/status snapshot. It distinguishes completed items from work in progress and remaining dependencies across registration, trade and clearance.
Reported done
Examples marked green in the source snapshot.
- Registration artwork input, drafts, return-for-modification flow and request notifications.
- Import shipment details, trade integration and single-product selection.
- Transfer integration and status synchronisation; export request submission, documents and staff decisions.
In progress
Examples marked blue in the source snapshot.
- Registration reporting and import bulk upload, documents and payment.
- Clearance assignment, contraventions, conditional actions and follow-up.
- Export certificate generation and customer/staff amendment handling.
To do
Examples marked orange in the source snapshot.
- Additional import contexts and migration/reporting work.
- Selected transfer approval and clearance release dependencies.
- Fines, risk handling and selected external integration work.
These are selected statuses reported by the programme snapshot. They are not a current production audit or individually attributed delivery claims.
Project current state and plan, final embedded scope/status board.
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.
| Evaluation question | Measure to define | Evidence needed |
|---|---|---|
| Can a customer finish the intended task? | Task completion, time and error/recovery rates | Comparable task, participant group, baseline and period. |
| Does assisted entry reduce effort accurately? | Correction rate, verification effort and input accuracy | Source-to-field checks and observed review tasks. |
| Can a returned request be corrected? | Successful amendment, repeated returns and recoverability | Linked return reasons and comparable resubmission outcomes. |
| Does the service become more predictable? | Review throughput, status enquiries and effort after submission | Request-level service data with consistent definitions and owners. |
| Do customers adopt the capability? | Eligible use, repeat use and reasons for returning to the previous system | Defined customer cohort and an observation period. |
Service entry point
Scroll to explore the full design. Open the viewer to zoom.
Documented work and learning
Mapped-flow baseline reported in the March 2026 workstream update
New user stories reported in the supplied planning snapshot
Original persona hypotheses from exploratory rounds 1 and 2
The evidence now connects programme discovery and persona hypotheses to an original service blueprint, detailed registration and amendment prototypes, explicit business rules and my documented delivery contribution. Historical testing adds real learning about form effort, operational throughput and adoption. A comparable retest and current production-impact result remain to be established.
The customer experience depends on the clarity of the interface and the quality of the decisions and handoffs behind it.
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.
- New original evidence: interviews synthesis, persona, Blueprint, empathy maps, Stories vs Design, Glossary, Project current state and plan, and the supplied product-registration scenario.
- Food and consumer-product research groups, staff sessions, historical concept testing and dated records are shown separately; their counts are not summed into a unique total.
- Original personas are hypotheses. Prototype-assisted input and auto-approval copy are design proposals to validate. Blueprint performance comparisons are targets, not achieved outcomes.
