Most of the time, a PRD lands on the design team with the solution already decided. The easiest path is to start executing right away. في أغلب الأوقات، الـPRD بيوصل لفريق التصميم والحل محدّد فيه مسبقاً. والمسار الأسهل إن الفريق يبدأ التنفيذ على طول.
The risk here isn't design quality — it's problem framing. A team can build a feature that's right in every way… for the wrong problem. The experience is consistent, delivery lands on time, and the metrics don't move. الخطر هنا مش في جودة التصميم، الخطر في تأطير المشكلة (Problem Framing). ممكن الفريق يبني ميزة صحيحة من كل النواحي… لمشكلة غلط. التجربة متسقة، والتسليم في معاده، والمؤشرات ما بتتحركش.
In this article I'll share four questions we use to anchor the problem before committing to any solution, and how each one applies in practice inside the team. I'll walk you through a real example from our work: a request that "merchants should select multiple orders and press merge," and how reframing it turned the ask from an operational tool into a growth opportunity. في المقالة دي هشارك 4 أسئلة بنثبّت بيها المشكلة قبل ما نلتزم بأي حل، وإزاي يتطبّق كل سؤال عملياً داخل الفريق. وهمشي معاكم بمثال من شغلنا: طلب إن «التاجر يحدد أكتر من طلب ويضغط دمج»، وإزاي إعادة تأطيره حوّلته من أداة تشغيلية لفرصة نمو.
Go back to the source and read the user's own words — not someone else's summary of them. ارجع للمصدر واقرأ كلام المستخدم بنفسك، مش تلخيص حد تاني عنه.
Why it matters. A request passes through several layers before it reaches design: the user, then support or sales, then the PM. At every layer, part of the problem description quietly turns into a solution description. The UX team's job is to walk the request back to its origin before building anything on top of it. ليه مهم؟ الطلب بيعدّي على أكتر من طبقة قبل ما يوصل لفريق التصميم: المستخدم، ثم الدعم أو المبيعات، ثم الـPM. وفي كل طبقة بيتحوّل جزء من وصف المشكلة لوصف حل. مسؤولية فريق UX إنه يرجّع الطلب لأصله قبل ما يتبنى عليه أي قرار.
How to apply it: إزاي تطبّقه:
- Make the original source a required part of every PRD: the feedback board, support tickets, interview recordings.اطلب المصدر الأصلي كجزء ثابت من أي PRD: منصة المقترحات، تذاكر الدعم، تسجيلات المقابلات.
- Read what users actually wrote. Notice the gap between their words and the PRD's terms.اقرأ كلام المستخدمين بالنص، ولاحظ الفرق بين مصطلحاتهم ومصطلحات الـPRD.
- Cluster similar requests: what repeats, and in whose words.اعمل تجميع بسيط للطلبات المتشابهة: إيه اللي بيتكرر، وبأي كلمات.
- If a request has no clear source, treat it as a hypothesis to validate — not a requirement.لو الطلب ملوش مصدر واضح، اعتبره فرضية محتاجة تحقق، مش متطلب.
A sign something is off: the PRD names a feature and lists its specs, but doesn't contain a single sentence from a real user. علامة إن فيه مشكلة: الـPRD فيه اسم ميزة ومواصفاتها، ومافيهوش ولا جملة من كلام مستخدم حقيقي.
A user usually describes the solution they've already imagined, not the situation they're actually suffering through. المستخدم غالباً بيوصف الحل اللي تخيّله، مش اللي بيعاني منه.
Why it matters. Starting from a solution closes the option space too early. The moment the team reaches the problem itself, simpler and higher-impact alternatives surface — and success can be measured by outcome instead of delivery. ليه مهم؟ البداية من الحل بتقفل مساحة الخيارات بدري. لكن لما الفريق يوصل للمشكلة نفسها، بتظهر بدائل أبسط وأعلى أثر، وبيقدر يقيس النجاح بالنتيجة مش بالتسليم.
How to apply it: إزاي تطبّقه:
- Walk back from the solution to the situation: what's happening, when, and what the user is losing.ارجع من الحل للموقف: إيه اللي بيحصل، وإمتى، والمستخدم بيخسر إيه.
- Write a one-sentence problem statement with no feature name in it, and agree on it with the PM before any solution discussion.اكتب Problem Statement في جملة واحدة مافيهاش اسم أي ميزة، واتفق عليها مع الـPM قبل أي مناقشة حلول.
- Tie the problem to a measurable impact: time, cost, sales, retention.اربط المشكلة بأثر قابل للقياس: وقت، تكلفة، مبيعات، احتفاظ.
- Put more than one direction on the table before committing to one.اطرح أكتر من اتجاه للحل قبل الالتزام بواحد.
A sign something is off: the PRD describes a UI element (button, screen, filter), not a user situation or a business impact. علامة إن فيه مشكلة: الـPRD بيوصف عنصر واجهة (زر، شاشة، فلتر)، ومش بيوصف موقف بيحصل للمستخدم أو أثر على البيزنس.
Sometimes the root of the problem sits with a party who never gets to speak. أحياناً جذر المشكلة عند طرف تاني ما اتكلمش.
Why it matters. The person writing the request is the one who has a channel to make themselves heard — not necessarily the one living the problem. Design only for the requester and the solution lands at the wrong point in the journey, usually long after the actual moment of pain. ليه مهم؟ اللي بيكتب الطلب هو اللي عنده قناة يوصّل بيها صوته، مش بالضرورة اللي بيعيش المشكلة. ولو التجربة اتصممت لصاحب الطلب بس، الحل هيتحط في نقطة غلط من الرحلة، غالباً متأخر عن اللحظة اللي بتحصل فيها المشكلة.
How to apply it: إزاي تطبّقه:
- Draw the whole ecosystem map: customer, merchant, operations, shipping carrier, platform.ابنِ خريطة للمنظومة كلها (Ecosystem Map): العميل، التاجر، فريق التشغيل، شركة الشحن، المنصة.
- Identify who feels the problem first, and at which point in the journey.حدد مين أول طرف بيحس بالمشكلة، وفي أنهي نقطة من الرحلة.
- Look for the party that has no channel to speak. Their absence from the data isn't absence from the problem.دوّر على الطرف اللي مالوش قناة يعبّر بيها. غيابه من البيانات مش معناه غيابه من المشكلة.
A sign something is off: the PRD is built around a single persona, even though the journey itself involves several parties. علامة إن فيه مشكلة: الـPRD مبني على Persona واحدة، مع إن الرحلة نفسها فيها أكتر من طرف.
If a solution demands manual effort every single time, ask the obvious next question: what if the system did it instead? لو الحل محتاج مجهود يدوي كل مرة، فكّر: ماذا لو النظام اشتغل بداله؟
Why it matters. Any solution that relies on repeated manual work is competing against the user's actual job. The result is usually a feature with weak adoption that disappears exactly during the busy periods when the problem is largest. ليه مهم؟ أي حل معتمد على مجهود يدوي متكرر بينافس على وقت المستخدم مع شغله الأساسي. والنتيجة غالباً ميزة بنسبة استخدام ضعيفة، تختفي بالظبط في فترات الضغط اللي المشكلة بتكبر فيها.
How to apply it: إزاي تطبّقه:
- Measure the task's frequency and scale: how many times a day, and across how many items?قيّم تكرار المهمة وحجمها: كام مرة في اليوم، ووسط كام عنصر؟
- Ask whether the decision can be expressed as a clear rule. If yes, the system should take it.اسأل: هل القرار ممكن يتصاغ كقاعدة واضحة؟ لو أيوه، النظام ياخده.
- Design automation as the default path, and manual intervention as the exception — reserved for cases that genuinely need human judgment.صمّم الأتمتة كمسار افتراضي، والتدخل اليدوي كاستثناء للحالات اللي محتاجة حكم بشري.
A sign something is off: the user flow starts with "the user opens… searches… selects… confirms…" for a task that happens every day. علامة إن فيه مشكلة: الـUser Flow بيبدأ بـ«المستخدم يدخل… يبحث… يحدد… يأكد…» في مهمة بتتكرر كل يوم.
Each question corrects a slice of the picture on its own. But applied together, they change the scope of the feature itself. "A merge button" became a three-layer system: كل سؤال لوحده بيصحّح جزء من الصورة. لكن لما الأربعة يتطبّقوا مع بعض، نطاق الميزة نفسه بيتغيّر. طلب «زر دمج» اتحوّل لنظام من 3 طبقات:
| Layerالطبقة | The question that produced itالسؤال اللي أنتجها |
|---|---|
| A reminder on the order confirmation page so the customer can add what they forgotتذكير للعميل في صفحة تأكيد الطلب إنه يقدر يضيف اللي نسيه | Q2 and Q3 — the real problem lives at the customer, not the merchantسؤال 2 و 3: المشكلة الحقيقية بتحصل عند العميل |
| Automatic merging under conditions: same customer, same address, before the carrier picks upدمج تلقائي بشروط: نفس العميل، نفس العنوان، قبل استلام شركة الشحن | Q4 — the decision is a clear rule and the merchant has no timeسؤال 4: القرار قاعدة واضحة، والتاجر ماعندوش وقت |
| Manual merging for edge casesدمج يدوي للحالات الخاصة | The original request — kept, but as an exception, not the main pathالطلب الأصلي، بس بقى استثناء مش المسار الأساسي |
Once the problem was reframed from "the merchant needs to merge orders" to "sales are leaking," the feature gained a measurable upside. The feature hasn't shipped yet, so this is an estimate built on transparent assumptions: لما المشكلة اتعاد تأطيرها من «التاجر محتاج يدمج طلبات» لـ«مبيعات بتضيع»، بقى للميزة أثر قابل للتقدير. ولأن الميزة لم تُطلق بعد، ده تقدير مبني على افتراضات واضحة:
- A store receiving 1,000 orders per month, with 3% of customers adding a product at an average of 60 SAR.متجر بيستقبل 1,000 طلب في الشهر، و3% من العملاء أضافوا منتج بمتوسط 60 ريال.
- Result: 1,800 SAR in additional sales per month, or 21,600 SAR per year — with zero extra effort from the merchant.النتيجة: 1,800 ريال مبيعات إضافية شهرياً، يعني 21,600 ريال سنوياً، من غير أي مجهود إضافي من التاجر.
- Across 70,000 stores: roughly 1.5 billion SAR of annual GMV flowing through the platform.على مستوى 70 ألف متجر: حوالي 1.5 مليار ريال سنوياً من الـGMV بتعدّي على المنصة.
The value here isn't in the precision of the number. The value is that reframing the problem changed how the feature itself gets evaluated: from an operational tool that saves time, to a growth opportunity that moves merchant and platform revenue. The actual uplift will decide the assumptions once we launch. القيمة هنا مش في دقة الرقم، القيمة في إن إعادة تأطير المشكلة غيّرت طريقة تقييم الميزة نفسها: من أداة تشغيلية بتوفّر وقت، لفرصة نمو بتأثر على إيرادات التاجر والمنصة. وبعد الإطلاق، نسبة الإضافة الفعلية هي اللي هتحسم الافتراضات دي.
Use this in a PRD review with your PM, before the team commits to a design direction: تقدر تستخدمها في جلسة مراجعة الـPRD مع الـPM، قبل ما الفريق يلتزم باتجاه تصميمي:
- The original source of the request is present, and users' own words have been read in full.المصدر الأصلي للطلب موجود، وكلام المستخدمين اتقرا بالنص.
- An agreed problem statement exists — with no feature name in it.فيه Problem Statement متفق عليه، من غير اسم ميزة.
- The problem is tied to a measurable impact.المشكلة مربوطة بأثر قابل للقياس.
- More than one solution direction was discussed before choosing one.اتطرح أكتر من اتجاه للحل قبل الاختيار.
- All parties in the ecosystem are mapped, and it's clear who feels the problem first.كل الأطراف في المنظومة متحددة، ومعروف مين أول واحد بيحس بالمشكلة.
- Repeated decisions have been reviewed: what should be automated, and what still needs human judgment.القرارات المتكررة اتراجعت: إيه اللي يتأتمت، وإيه اللي محتاج حكم بشري.
Sometimes the review confirms the PRD is already sound — and that in itself is a useful outcome. Other times, it reveals a bigger opportunity hiding behind a small request. أحياناً المراجعة بتأكد إن الـPRD سليم، وده في حد ذاته نتيجة مهمة. وأحياناً بتكشف إن ورا طلب بسيط فرصة أكبر بكتير من اللي اتكتب.
A team can build the right feature in every way… for the wrong problem. ممكن الفريق يبني ميزة صحيحة من كل النواحي… لمشكلة غلط.
Which of these four questions gets forgotten most often in your team? أنهي سؤال فيهم بيتنسي غالباً في فريقك؟