شخصيات المستخدمين

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

دلوقتي تخيل لو حد قال: "طب أحمد — المحاسب اللي عنده 35 سنة وبيستخدم التطبيق في المواصلات — هو محتاج الميزة دي؟"

فجأة الحوار بيتحول من آراء شخصية لنقاش مبني على احتياجات مستخدم حقيقي. ده بالظبط قوة الـ User Personas.

إيه هي الـ User Persona؟

الـ User Persona هي شخصية خيالية بتمثل مجموعة من المستخدمين الحقيقيين. هي مبنية على بيانات حقيقية من بحث المستخدمين وبتساعد الفريق كله يفهم ويتعاطف مع المستخدم المستهدف.

Alan Cooper — اللي اخترع مفهوم الـ Personas في كتابه "The Inmates Are Running the Asylum" — بيقول:

"الـ Personas مش ناس حقيقيين، لكنها بتمثل ناس حقيقيين خلال عملية التصميم. هي نماذج افتراضية لمجموعات المستخدمين المستهدفين."

المهم: الـ Persona الكويسة مش بتتألف من الخيال — هي مبنية على بيانات من بحث حقيقي (مقابلات، استبيانات، تحليل بيانات).

ليه الـ Personas مهمة؟

١. بتبني التعاطف

لما عندك Persona بتفاصيل — اسم، صورة، قصة — الفريق بيبدأ يحس بالمستخدم كإنسان مش كرقم. ده بيأثر على جودة القرارات التصميمية.

٢. بتوحد الفريق

بدل ما كل واحد يفكر في "المستخدم" بشكل مختلف، الـ Personas بتخلي الكل يتكلم عن نفس الشخص. ده بيقلل الخلافات وبيسرع اتخاذ القرارات.

٣. بتساعد في تحديد الأولويات

لما يكون عندك 3 Personas وميزة جديدة بتخدم واحد بس منهم، بتقدر تاخد قرار مبني على مين الأهم في المرحلة دي.

٤. بتمنع التصميم لنفسك

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

عناصر الـ Persona الأساسية

الـ Persona الجيدة بتحتوي على العناصر دي:

المعلومات الأساسية

الاسم: اسم حقيقي مش "المستخدم أ". "سارة" أفضل من "مستخدم شريحة 2"
الصورة: صورة واقعية (مش Emoji أو أيقونة)
العمر والمهنة: بيساعد في تحديد السياق
الحالة العائلية: لو مرتبطة بالمنتج
الموقع: مدينة أو منطقة

الأهداف والدوافع (Goals)

إيه اللي عايز يحققه باستخدام المنتج؟
إيه الدوافع الأعمق ورا الأهداف دي؟

مثال: سارة عايزة تتابع مصاريفها (هدف ظاهري) لأنها عايزة تحس بالأمان المالي (دافع أعمق).

الإحباطات ونقاط الألم (Pain Points)

إيه اللي بيزعلها في الحلول الحالية؟
إيه العوائق اللي بتمنعها توصل لأهدافها؟

السلوكيات والعادات

إزاي بتستخدم التكنولوجيا حاليا؟
إيه التطبيقات اللي بتستخدمها يوميا؟
إمتى وفين بتستخدم المنتج؟

السياق

البيئة: في الشغل؟ في البيت؟ في المواصلات؟
الأجهزة: موبايل؟ لابتوب؟ الاتنين؟
القيود: وقت محدود؟ إنترنت ضعيف؟ خبرة تقنية محدودة؟

اقتباس (Quote)

جملة واحدة بتلخص موقف أو احتياج الـ Persona. مثلا: "عايزة أعرف فلوسي بتروح فين بدون ما أقعد ساعة أحسب".

إزاي تبني Persona مبنية على بحث

الخطوة ١: اجمع البيانات

مفيش Persona كويسة بدون بيانات حقيقية. الطرق الأساسية:

مقابلات مستخدمين (الأهم):

قابل 5-10 مستخدمين من جمهورك المستهدف
اسألهم عن أهدافهم، مشاكلهم، وسلوكياتهم
سجل المقابلات (بإذنهم) عشان ترجعلها

استبيانات:

ابعت استبيان لعينة أكبر (50-200 شخص)
اسأل عن الديموغرافيات والسلوكيات والتفضيلات

تحليل البيانات:

لو عندك منتج موجود، حلل بيانات الاستخدام
مين بيستخدم إيه؟ إمتى؟ قد إيه؟

أبحاث السوق:

تقارير الصناعة
بيانات المنافسين

الخطوة ٢: حلل البيانات وحدد الأنماط

بعد ما جمعت البيانات، ابدأ دور على الأنماط:

فيه مجموعة من المستخدمين بيتشاركوا في نفس الأهداف؟
فيه أنماط سلوكية متكررة؟
فيه مشاكل مشتركة؟

استخدم Affinity Mapping: اكتب كل ملاحظة على Post-it وابدأ جمّع المتشابه.

الخطوة ٣: حدد عدد الـ Personas

القاعدة: 3-5 Personas كافية لأغلب المشاريع. أقل من كده وإنت بتفوت شرائح مهمة. أكتر من كده وهتتشتت.

حدد:

Primary Persona: المستخدم الأساسي اللي بتصمم ليه أولا
Secondary Personas: مستخدمين مهمين لكن مش الأولوية القصوى
Anti-Persona (اختياري): مين مش المستخدم بتاعك — ده بيساعدك تركز

الخطوة ٤: ابني الـ Persona

دلوقتي اجمع كل البيانات في وثيقة واحدة واضحة. خليها:

صفحة واحدة: لو طويلة أوي، محدش هيقرأها
بصرية: استخدم صور وأيقونات وألوان
سهلة القراءة: عناوين واضحة ونقاط مختصرة

الخطوة ٥: شارك واستخدم

الـ Persona مش بتتعلق على الحيطة وخلاص — لازم تستخدمها:

علقها في غرفة الفريق أو حطها في الـ Wiki
ارجع ليها في كل اجتماع تصميمي
استخدم اسم الـ Persona في النقاشات: "سارة هتفهم ده؟"

مثال عملي: Persona لتطبيق توصيل أكل

سارة — الأم العاملة

المعلومات الأساسية:

العمر: 32 سنة
المهنة: محاسبة في شركة خاصة
الحالة: متزوجة وعندها طفلين (4 و7 سنين)
الموقع: مدينة نصر، القاهرة
الأجهزة: iPhone 14، بتستخدم الموبايل أكتر من اللابتوب

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

الأهداف:

توفر وقت في الطبخ أيام الشغل
تلاقي أكل صحي ومناسب للأطفال
تتحكم في ميزانية الأكل الشهرية

الإحباطات:

التطبيقات الحالية مش بتوري المعلومات الغذائية
وقت التوصيل غير دقيق — الأطفال بيجوعوا
الأسعار بتتغير ومفيش شفافية

السلوك:

بتطلب أكل 3-4 مرات في الأسبوع
بتفضل تطلب من الشغل الساعة 5 عشان الأكل يوصل لما ترجع البيت
بتقرأ التقييمات قبل ما تجرب مطعم جديد
بتفضل الدفع أونلاين عشان مش بتحب تتعامل بكاش

السياق:

بتستخدم التطبيق في 3 أوقات: الصبح (بتخطط)، الضهر (بتطلب)، بالليل (بتقيّم)
إنترنت موبايل أحيانا بطيء في المواصلات
بتقارن بين 2-3 تطبيقات قبل ما تطلب

أنواع Personas مختلفة

Proto-Personas (مبدئية)

Personas مبنية على افتراضات الفريق مش بحث حقيقي. مفيدة كنقطة بداية لما مفيش وقت أو ميزانية لبحث كامل.

إمتى تستخدمها: في بداية المشروع لتوحيد فهم الفريق، بس لازم تتأكد منها ببحث في أقرب وقت.

Data-Driven Personas

مبنية على تحليل بيانات كمية (Analytics, Surveys). بتكون أكتر دقة من ناحية الأرقام لكن ممكن تنقصها العمق الإنساني.

Buyer Personas vs. User Personas

User Persona: اللي بيستخدم المنتج فعلا
Buyer Persona: اللي بياخد قرار الشراء

أحيانا هم نفس الشخص، أحيانا لا. مثلا في برامج الشركات (B2B)، اللي بيشتري (المدير) مختلف عن اللي بيستخدم (الموظف).

أخطاء شائعة في بناء الـ Personas

١. الـ Persona المألفة

"أحمد، 25 سنة، بيحب التكنولوجيا ومتابع آخر التطورات" — ده مش Persona، ده وصف عام ينطبق على ملايين. الـ Persona لازم تكون محددة بما يكفي إنها تساعد في اتخاذ قرارات.

٢. الـ Persona بدون بحث

أخطر حاجة هي إنك تألف الـ Persona من خيالك. ده بيعطي الفريق ثقة كاذبة — فاكرين إنهم فاهمين المستخدم وهم في الحقيقة بيتكلموا عن شخصية خيالية.

٣. كثرة الـ Personas

10 Personas؟ لا. الفريق مش هيفتكرهم ومش هيستخدمهم. 3-5 كفاية.

٤. الـ Persona الثابتة

المستخدمين بيتغيروا. الـ Personas لازم تتحدث كل 6-12 شهر بناء على بيانات جديدة.

٥. تفاصيل كتير مش مفيدة

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

بدائل ومكملات للـ Personas

Jobs to be Done (JTBD)

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

Empathy Maps

أداة بسيطة بتقسم فهمك للمستخدم لـ 4 أرباع:

بيقول (Says): كلام المستخدم في المقابلات
بيفكر (Thinks): أفكاره الداخلية اللي ممكن ميقولهاش
بيحس (Feels): المشاعر والإحباطات
بيعمل (Does): الأفعال والسلوكيات الحقيقية

User Stories

جمل قصيرة بصيغة: "كـ [نوع المستخدم]، عايز [إجراء] عشان [هدف]"

مثال: "كأم عاملة، عايزة أشوف المعلومات الغذائية للوجبات عشان أختار أكل صحي لولادي."

أدوات لبناء الـ Personas

Figma: في Templates مجانية كتير في Figma Community
UXPressia: أداة متخصصة في بناء Personas وCustomer Journey Maps
Miro: ممتاز للعمل الجماعي على Personas
Notion: لتوثيق ومشاركة الـ Personas مع الفريق
حتى PowerPoint أو Google Slides: أبسط طريقة لو عايز حاجة سريعة

الخلاصة

الـ User Personas هي من أقوى أدوات التعاطف في تصميم UX. هي بتخلي المستخدم "حقيقي" في عقل كل فرد في الفريق — من المصمم للمطور لصاحب القرار.

لكن تذكر: الـ Persona مش هدف في حد ذاتها — هي أداة. لو بنيتها ومحدش استخدمها، فأنت ضيعت وقتك. القوة الحقيقية في إنك ترجعلها في كل قرار تصميمي.

ابدأ بحاجة بسيطة: اعمل Proto-Persona لمشروعك الحالي بناء على اللي تعرفه عن مستخدميك. وبعدين تأكد منها بمقابلة 3-5 مستخدمين حقيقيين. هتتفاجئ قد إيه الواقع مختلف عن الافتراضات.