تحديد المشكلة نصف الحل

تحديد المشكلة نصف الحل. في أي مجال، بزنس أو ماركتنج أو برمجة أو تصميم، عشان أعطي المستخدم أفضل نتيجة لازم أكون فاهم الـ pain تبعه: شو مشكلته بالضبط، وشو سببها، وليش صارت معه. بس وقتها بقدر أقدّم حل منطقي وقابل للاستخدام، مش حل نظري.

أكبر مثال على تحديد مشكلة بشكل فعّال هو Uber. الشركة انفتحت باسم UberCab في سان فرانسيسكو سنة 2009، بعد ما دفع المؤسسون 800 دولار للحصول على سائق خاص. المبلغ نفسه كان الإجابة على سؤال واحد: شو هي المشكلة؟

في تجربة المستخدم، نفس القصة

مكان زر واحد، أو ترتيب شاشة داخل فلو، ممكن يخلي المستخدم:

• ما يكمّل عملية شراء
• أو ما ينجز التاسك
• أو ما يوصل لمعلومة مهمة

وهاد بيأثر على التجربة وعلى البزنس سوا.

بس كيف بعرف إنها فعلاً مشكلة، مش مجرد رأي أو ذوق؟ عشان ما أخلط بين “مشكلة” و”افتراض وهمي” أو “ستايل عاجبني”، لازم إطار واضح.

Problem Statement Framework

[User A] experiences [this problem] when they [try to complete this action] in [this context]. This is a problem because [it has this impact on the user experience and on the business].

ولبناء واحدة فعّالة، في أداة بسيطة اسمها 5Ws:

1. Who: مين المتأثر بالمشكلة؟
2. What: شو هي المشكلة؟
3. Where: وين بتظهر؟
4. When: إمتى بتظهر؟
5. Why: ليش بتصير؟ وليش مهمة؟

مثال

لما العميل يحاول يشتري منتج من الموقع، بيتعطّل لأن خيارات الدفع مش واضحة أو مش شغالة، وهاد بيؤدي إلى تخلّيه عن عملية الشراء.

جملة واحدة، بس فيها المتأثر، والمشكلة، والسياق، والأثر. وهاي الجملة هي الي بتحكم على كل قرار تصميمي بعدها: هل هالقرار بيحلّها ولا لأ؟