حل المشكلات في UX

لو سألت أي مصمم UX ناجح "إنت بتعمل إيه؟"، الإجابة مش هتكون "بصمم شاشات حلوة." الإجابة هتكون: "بحل مشكلات."

التصميم في جوهره هو حل مشكلات. كل شاشة بتصممها، كل زرار بتحطه، كل Flow بتبنيه — ده حل لمشكلة ما عند المستخدم. لكن المشكلة الحقيقية هي: إزاي تحدد المشكلة الصح؟

Albert Einstein قال جملة شهيرة:

"لو عندي ساعة عشان أحل مشكلة، هقضي 55 دقيقة أفكر في المشكلة و5 دقائق أفكر في الحل."

في المقال ده، هنتعلم أهم الأطر (Frameworks) والمنهجيات اللي بتساعدك تحدد المشكلة صح وتوصل لحلول فعالة.

ليه تحديد المشكلة أهم من الحل؟

أكتر خطأ شائع في التصميم هو القفز للحل مباشرة:

• العميل: "عايز زرار Chatbot على الموقع"
• المصمم المبتدئ: يبدأ يصمم الـ Chatbot
• المصمم المحترف: يسأل "ليه؟ إيه المشكلة اللي بتحلها؟"

ممكن يكتشف إن المشكلة الحقيقية هي إن صفحة الأسئلة الشائعة مش منظمة ومحدش بيلاقي فيها حاجة. الحل مش Chatbot — الحل هو إعادة تنظيم المحتوى.

القاعدة: لو حليت المشكلة الغلط صح، لسه ضيعت وقتك. لكن لو حددت المشكلة الصح، حتى حل متواضع هيكون أفضل.

إطار Jobs to be Done (JTBD)

الفكرة

بدل ما تسأل "مين المستخدم؟"، اسأل: "إيه الـ Job اللي المستخدم بيحاول ينجزه؟"

Clayton Christensen — أستاذ في Harvard — هو اللي طور الإطار ده. مثاله الشهير عن الميلك شيك:

سلسلة مطاعم فاست فود كانت عايزة تبيع ميلك شيك أكتر. عملوا أبحاث سوق تقليدية: "عايزه أسمك؟ أحلى؟ أرخص؟" غيروا الوصفة كذا مرة والمبيعات مزادتش.

بعدين جم باحثين وسألوا سؤال مختلف: "إيه الـ Job اللي الميلك شيك بيعمله في حياة العميل؟"

اكتشفوا حاجة مفاجئة: أغلب المبيعات الصبح. الناس بتشتري الميلك شيك وهي رايحة الشغل. الـ Job مش "عايز حاجة حلوة" — الـ Job هو "عايز حاجة تشغلني في المشوار الطويل، تملي معدتي، وإيد واحدة تكفي".

المنافس الحقيقي للميلك شيك مكانش آيس كريم أو عصير — كان الموز والـ Bagel والملل.

إزاي تستخدمه في UX

صيغة الـ Job Statement:

لما [الموقف]، عايز [الدافع] عشان [النتيجة المرجوة]

مثال: "لما أكون في المواصلات وزهقان، عايز أقرأ حاجة مفيدة عشان أحس إني استغليت الوقت."

الخطوات:

1. راقب المستخدمين في سياقهم الطبيعي
2. اسأل: "إيه اللي كنت بتحاول تعمله؟" (مش "إيه رأيك في المنتج؟")
3. حدد الـ Job الأساسي والوظائف الاجتماعية والعاطفية المرتبطة بيه
4. صمم حل بيحقق الـ Job بشكل أفضل من البدائل الحالية

تقنية الـ 5 Whys

الفكرة

تقنية بسيطة جدا وقوية جدا: اسأل "ليه" 5 مرات عشان توصل للسبب الجذري للمشكلة. طورها Sakichi Toyoda مؤسس Toyota.

مثال عملي

المشكلة الظاهرة: المستخدمين مش بيكملوا عملية الشراء.

1. ليه مش بيكملوا؟ → لأنهم بيسيبوا صفحة الدفع
2. ليه بيسيبوا صفحة الدفع؟ → لأنهم بيتفاجأوا بتكاليف الشحن
3. ليه بيتفاجأوا؟ → لأن تكاليف الشحن مش بتظهر إلا في آخر خطوة
4. ليه مش بتظهر بدري؟ → لأن الفريق حاسس إن عرضها بدري هيخوف العملاء
5. ليه هيخوفهم؟ → لأن تكاليف الشحن عالية مقارنة بالمنافسين

السبب الجذري مش في التصميم — هو في تسعير الشحن. الحل التصميمي (عرض التكاليف بدري) مهم، لكن الحل الحقيقي هو مراجعة سياسة الشحن.

نصائح للاستخدام

• مش لازم تكون 5 بالظبط — أحيانا 3 كفاية وأحيانا محتاج 7
• ممكن تتفرع: كل "ليه" ممكن يكون ليها أكتر من إجابة
• خلي الفريق كله يشارك: كل واحد ممكن يشوف السبب من زاوية مختلفة
• ركز على العمليات مش الأشخاص: "ليه العملية بتسمح بده" أفضل من "مين غلط"

إطار How Might We (HMW)

الفكرة

بعد ما حددت المشكلة، "How Might We" بيحولها لسؤال إبداعي مفتوح. الصيغة:

"إزاي ممكن ن... [الفعل]... عشان [الهدف]؟"

ليه الصيغة دي قوية

• "How": بتفترض إن فيه حل — بتفتح الباب للإبداع
• "Might": مش لازم — بتشجع على الاستكشاف بدون ضغط
• "We": مش أنا لوحدي — ده شغل فريق

أمثلة

• المشكلة: المستخدمين مش بيلاقوا المحتوى اللي بيدوروا عليه

• HMW: "إزاي ممكن نساعد المستخدمين يلاقوا المحتوى المناسب ليهم بأقل مجهود؟"

• المشكلة: المستخدمين بيحسوا بالملل أثناء الانتظار

• HMW: "إزاي ممكن نخلي وقت الانتظار تجربة ممتعة بدل ما تكون مملة؟"

نصائح

• متخليهاش واسعة أوي: "إزاي ممكن نحسن التطبيق؟" — ده مش مفيد
• متخليهاش ضيقة أوي: "إزاي ممكن نضيف زرار بحث أزرق؟" — ده حل مش سؤال
• الوسط المثالي: واسعة بما يكفي لتوليد أفكار متنوعة، وضيقة بما يكفي لتكون مركزة

Problem Statement

الفكرة

بيان المشكلة هو جملة واضحة ومحددة بتوصف المشكلة اللي بتحلها. ده بيكون مرجعك طول المشروع.

الصيغة

[المستخدم] محتاج طريقة عشان [الاحتياج] لأن [السبب/الرؤية]

أو صيغة أكتر تفصيلا:

[المستخدم] بيعاني من [المشكلة] لما بيحاول [المهمة] وده بيأدي لـ [النتيجة السلبية]

مثال

"أمهات شغالات في القاهرة بيعانوا من صعوبة تتبع مصاريفهم اليومية لما بيحاولوا يديروا ميزانية الأسرة، وده بيأدي لتجاوز الميزانية الشهرية باستمرار والإحساس بفقدان السيطرة."

نصائح لبيان مشكلة جيد

• مبني على بحث حقيقي مش افتراضات
• محدد بما يكفي إنك تشتغل عليه
• مفيهوش حل — بيوصف المشكلة بس
• بيحدد التأثير — ليه المشكلة دي مهمة
• قابل للقياس — تقدر تعرف لو حلتها ولا لا

إطار Double Diamond

الفكرة

إطار طوره Design Council البريطاني وبقى من أشهر أطر حل المشكلات في التصميم. اسمه "الماسة المزدوجة" لأنه بيتكون من مرحلتين كل واحدة فيها توسع وتضييق:

الماسة الأولى: المشكلة الصح

1. Discover (اكتشف): وسع فهمك — اعمل بحث، قابل مستخدمين، راقب سلوكيات. متحكمش على أي حاجة — الهدف إنك تجمع معلومات
2. Define (حدد): ضيق التركيز — من كل اللي اكتشفته، إيه المشكلة الحقيقية اللي لازم تحلها؟ هنا بتطلع بـ Problem Statement واضح

الماسة التانية: الحل الصح

3. Develop (طور): وسع خيارات الحلول — Brainstorm، Ideate، ولد أكبر عدد ممكن من الأفكار. مفيش فكرة غلط في المرحلة دي
4. Deliver (سلّم): ضيّق وصقل — اختار أفضل حل، اعمل Prototype، اختبره، وطوره

الفكرة المهمة: كتير من الفرق بتبدأ من الماسة التانية مباشرة (بتبدأ تحل) بدون ما تستثمر وقت في الماسة الأولى (فهم المشكلة). ده السبب الرئيسي لفشل كتير من المنتجات.

تقنية Affinity Mapping

الفكرة

لما عندك كمية كبيرة من البيانات (من مقابلات، ملاحظات، Feedback)، Affinity Mapping بيساعدك تنظمها وتطلع بأنماط.

إزاي تعمله

1. اكتب كل ملاحظة على Post-it منفصل (ورقي أو رقمي في Miro)
2. ابدأ جمّع المتشابه مع بعض — بدون ما تحدد الفئات مسبقا
3. سمّي كل مجموعة بعد ما تتشكل
4. رتب المجموعات حسب الأهمية أو التكرار
5. اطلع بـ Insights — إيه الأنماط اللي ظهرت؟

مثال عملي

بعد 10 مقابلات مع مستخدمين لتطبيق بنكي، جمعت 80 ملاحظة. بعد الـ Affinity Mapping، ظهرت 5 مجموعات:

• الأمان: الناس خايفة من الاحتيال (18 ملاحظة)
• البساطة: عايزين يعملوا التحويلات بسرعة (15 ملاحظة)
• الشفافية: عايزين يفهموا الرسوم والعمولات (14 ملاحظة)
• التحكم: عايزين يتحكموا في الإشعارات والحدود (12 ملاحظة)
• الدعم: مش لاقيين مساعدة لما بيحتاجوها (11 ملاحظة)

دلوقتي عرفت إن الأمان والبساطة هم الأولوية القصوى.

تقنية Crazy 8s

الفكرة

تقنية سريعة لتوليد الأفكار: ارسم 8 حلول مختلفة في 8 دقائق. دقيقة واحدة لكل فكرة.

ليه بتشتغل

• السرعة بتمنع الـ Perfectionism: مفيش وقت تفكر كتير — ارسم وخلاص
• الكمية بتولد الجودة: أول 2-3 أفكار هيكونوا عاديين، لكن الأفكار 5-8 هيكونوا أكتر إبداعا لأنك استنفذت الأفكار الواضحة
• بتطلع الكل من منطقة الراحة: مفيش وقت للتردد أو الخوف

إزاي تعملها

1. اطوي ورقة A4 عشان يكون عندك 8 مربعات
2. حط Timer على 8 دقائق
3. ارسم فكرة مختلفة في كل مربع — كل مربع دقيقة
4. بعد ما تخلص: شارك مع الفريق واختاروا الأفضل

إطار RICE للتحديد الأولويات

بعد ما ولدت أفكار كتير، محتاج تحدد أولويات. RICE بيساعدك:

• Reach: كام مستخدم هيتأثر؟
• Impact: قد إيه التأثير هيكون كبير؟ (1-3)
• Confidence: قد إيه إنت واثق في التقديرات دي؟ (%)
• Effort: كام وقت/موارد محتاج؟

النتيجة = (Reach x Impact x Confidence) / Effort

الأفكار اللي عندها نتيجة أعلى بتتنفذ الأول.

نصائح عامة لحل المشكلات في UX

١. قاوم "First Solution Bias"

أول حل بييجي في بالك نادرا ما بيكون الأفضل. خد وقتك واستكشف خيارات مختلفة.

٢. اعمل Frame و Reframe

حاول تعيد صياغة المشكلة بأكتر من طريقة. "المستخدمين مش بيسجلوا" ممكن تتصاغ كـ "المستخدمين مش شايفين قيمة كافية للتسجيل" أو "عملية التسجيل طويلة أوي."

كل صياغة بتفتح باب لحلول مختلفة.

٣. فكر في القيود كفرص

القيود (وقت محدود، ميزانية قليلة، قدرات تقنية محددة) مش عقبات — هي بتوجه الإبداع. أحيانا أفضل الحلول بتيجي من أشد القيود.

٤. اختبر الافتراضات

كل حل مبني على افتراضات. حددها صراحة واختبرها:

• "المستخدمين هيفهموا الأيقونة دي" ← اختبر
• "الناس هتدفع مقابل الميزة دي" ← اختبر
• "المشكلة الأساسية هي السرعة" ← اختبر

٥. تعلم من الفشل

مش كل حل هينجح. الأهم إنك تتعلم من كل تجربة:

• إيه اللي نجح وليه؟
• إيه اللي فشل وليه؟
• إيه اللي هنعمله مختلف المرة الجاية؟

أدوات ومصادر

• كتب: "Competing Against Luck" لـ Clayton Christensen (عن JTBD)، و"Sprint" لـ Jake Knapp (عن حل المشكلات في أسبوع)
• أدوات: Miro للـ Affinity Mapping، FigJam للتعاون، Notion للتوثيق
• كورسات: IDEO U: From Ideas to Action عن حل المشكلات بشكل إبداعي
• بودكاست: The Design Better Podcast بيتكلم كتير عن حل المشكلات في التصميم

الخلاصة

حل المشكلات في UX مش موهبة — ده مهارة بتتعلمها وبتتمرن عليها. الأطر اللي اتكلمنا عنها — Jobs to be Done، 5 Whys، How Might We، Double Diamond — هي أدوات في صندوق أدواتك. مش لازم تستخدمهم كلهم في كل مشروع، لكن لازم تعرفهم عشان تختار المناسب.

أهم حاجة تفتكرها: اقضِ وقت أطول في فهم المشكلة. لو فهمت المشكلة صح، الحل غالبا بيكون واضح. لو قفزت للحل مباشرة، هتلاقي نفسك بتحل المشكلة الغلط.

في مشروعك الجاي، قبل ما تفتح Figma، اكتب Problem Statement واحد واضح. لو مقدرتش تكتبه في جملتين، يبقى لسه مش فاهم المشكلة كفاية.