أذكر ذلك اليوم جيدًا. كنا في اجتماع الفريق الأسبوعي، والحماس يملأ الغرفة. نناقش تطبيقًا جديدًا لإدارة المهام كنا نعمل عليه. بدأ الزملاء يطرحون الأفكار: “لنضف تكاملًا مع تقويم جوجل!”، “ما رأيكم في نظام إنجازات Gamification؟”، “يجب أن يكون التصميم داكنًا، فهو الموضة الآن!”. كنت أستمع وأهز رأسي، لكن شعورًا بعدم الارتياح بدأ يتسلل إلى داخلي. بعد نصف ساعة من النقاش المحتدم حول لون زر ثانوي، لم أعد أحتمل، وقاطعتهم سائلًا: “يا جماعة الخير، اسمحولي بسؤال… لمين بنبني هاد الأشي؟”.
ساد صمت مفاجئ. ثم أتت الإجابات المترددة: “للموظفين”، “للمدراء”، “لكل حدا مشغول وبده ينظم وقته”. كانت إجابات فضفاضة وعامة لدرجة أنها لم تكن تعني شيئًا. في تلك اللحظة، أدركت مشكلتنا الحقيقية: نحن لا نبني منتجًا لمستخدم حقيقي، بل كنا نبني لشبح. شبح لا اسم له، لا وجه له، ولا مشاكل حقيقية له. كنا نبني بناءً على ما نعتقد “نحن” أنه رائع، وليس ما يحتاجه “هو”. كان هذا هو جحيم التخمين، وكنا نغرق فيه بسرعة.
المشكلة: عندما تبني منتجًا لشبح
تصميم منتج بدون فهم واضح للمستخدم النهائي يشبه تمامًا خياطة بدلة لشخص لم تقابله قط. قد تخمن مقاسه، لونه المفضل، والمناسبة التي سيرتديها من أجلها، لكن في النهاية، غالبًا ما ستكون النتيجة بدلة لا تناسب أحدًا. في عالم البرمجيات، هذا “الشبح” يؤدي إلى كوارث حقيقية:
- زحف الميزات (Feature Creep): عندما لا تعرف ما يريده المستخدم، تبدأ في إضافة كل ميزة يمكن تخيلها على أمل أن “تعجب” إحداها الشبح.
- خلافات داخلية لا تنتهي: يصبح النقاش حول “أنا أظن” و”أنت تظن”، لأن لا أحد يملك حجة قوية مبنية على حاجة مستخدم حقيقي.
- تجربة مستخدم سيئة: المنتج النهائي يكون معقدًا ومشتتًا، لأنه يحاول إرضاء الجميع، وفي النها-ية لا يرضي أحدًا.
- إهدار الموارد: كل ساعة برمجة، وكل بكسل تصميم يتم إنفاقه على ميزة لا يريدها أحد هو مال ووقت ألقي في الهواء.
كنا عالقين في هذه الدوامة. نقضي أسابيع في تطوير ميزة، ثم نكتشف بعد إطلاقها أن لا أحد يستخدمها. كان الإحباط سيد الموقف، وبدا المشروع وكأنه يسير نحو حائط مسدود.
الحل المنقذ: ما هي “شخصيات المستخدم” (User Personas)؟
في خضم هذا الإحباط، طرحتُ على الفريق فكرة كانت بمثابة طوق النجاة: “دعونا نتوقف عن التخمين ونبدأ بالبحث. دعونا نخلق شخصيات المستخدم الخاصة بنا”.
ببساطة، شخصية المستخدم (User Persona) هي شخصية خيالية، لكنها مبنية على بيانات وبحث حقيقي، تمثل مجموعة من المستخدمين الذين يتشاركون في نفس الأهداف، السلوكيات، والإحباطات. هي ليست شخصًا حقيقيًا، بل تجميع لأبرز سمات شريحة مهمة من جمهورك المستهدف. الهدف منها هو إعطاء وجه واسم وروح لذلك “الشبح” الذي كنا نصمم له.
بدلًا من أن نقول “المستخدم يريد واجهة بسيطة”، أصبحنا نقول: “سالم، مدير المشاريع الذي ليس لديه وقت، يحتاج إلى لوحة تحكم تمنحه نظرة عامة سريعة في أقل من 30 ثانية”. الفرق هائل!
كيف بنينا شخصياتنا: من الفوضى إلى الوضوح
كانت العملية أشبه بعمل المحقق. قررنا التوقف عن كتابة أي سطر كود جديد لمدة أسبوعين، وكرسنا كل وقتنا لفهم من هم مستخدمونا الحقيقيون. اتبعنا الخطوات التالية:
الخطوة الأولى: البحث وجمع البيانات
لم نكتفِ بالجلوس في مكاتبنا. خرجنا إلى الميدان وبدأنا في جمع المعلومات من مصادر متعددة:
- مقابلات المستخدمين: تحدثنا مع مدراء مشاريع، موظفين مستقلين (freelancers)، وأعضاء فرق في شركات مختلفة. سألناهم عن يومهم، أدواتهم، وما الذي يسبب لهم الصداع في عملهم.
- استبيانات عبر الإنترنت: أرسلنا استبيانات لجمهور أوسع لفهم الأنماط السائدة.
- تحليل المنافسين: نظرنا إلى مراجعات المستخدمين للتطبيقات المنافسة. ما الذي يحبه الناس؟ وما الذي يكرهونه؟ كانت هذه منجم ذهب للمعلومات.
نصيحة أبو عمر: لا تستهين أبدًا بقوة الحديث المباشر. أفضل الأفكار وأعمقها لا تأتي من جداول البيانات، بل تأتي من فنجان قهوة تشربه مع مستخدم محتمل وهو يصف لك معاناته اليومية. هذه اللحظات لا تقدر بثمن.
الخطوة الثانية: تحليل الأنماط وتحديد المجموعات
بعد جمع كل هذه البيانات، قمنا بطباعتها (نعم، على ورق حقيقي!) ولصقناها على جدار كبير في المكتب. بدأنا في تجميع الملاحظات المتشابهة معًا. ظهرت أنماط واضحة. وجدنا مجموعة من المستخدمين هم “مدراء” هدفهم الرئيسي هو الرؤية الشاملة، ومجموعة أخرى هم “أعضاء فريق” هدفهم هو معرفة مهامهم اليومية بوضوح، ومجموعة ثالثة هم “مستقلون” يحتاجون لتتبع وقتهم بدقة.
الخطوة الثالثة: خلق الشخصيات
لكل مجموعة من هذه المجموعات، قمنا ببناء شخصية كاملة. أعطيناها اسمًا، صورة (من مواقع الصور المجانية)، عمرًا، وظيفة، قصة، أهدافًا، وأهم شيء: إحباطات. هذه الشخصيات أصبحت أعضاءً غير رسميين في فريقنا.
مثال عملي: تعرفوا على “سامي المدير”
لأوضح لكم الفكرة، اسمحوا لي أن أقدم لكم إحدى الشخصيات التي أنقذت مشروعنا، “سامي”.
بطاقة شخصية: سامي الأحمد
- الصورة: (صورة رمزية لرجل في منتصف الثلاثينات يرتدي قميصًا ويبتسم بثقة)
- الاسم: سامي الأحمد
- العمر: 35 سنة
- الوظيفة: مدير مشاريع في شركة تقنية ناشئة
- الخلفية: أب لطفلين، يعيش في مدينة مزدحمة، يستخدم التكنولوجيا بكثرة لكنه ليس خبيرًا تقنيًا. وقته ثمين جدًا.
- الأهداف (Goals):
- تتبع تقدم الفريق بسهولة وبنظرة واحدة.
- التأكد من أن الجميع على نفس الصفحة بخصوص المهام والمواعيد النهائية.
- تقليل عدد الاجتماعات غير الضرورية التي تسرق وقته.
- الإحباطات (Frustrations):
- يضيع وقته في التنقل بين عدة تطبيقات (البريد الإلكتروني، سلاك، جداول البيانات) ليجمع صورة كاملة عن الوضع.
- صعوبة الحصول على تقارير سريعة وواضحة عن حالة المشروع.
- يشعر أن الأدوات الحالية معقدة للغاية وتحتاج إلى تدريب لاستخدامها.
- اقتباس يمثله: “بس بدي أعرف مين بعمل شو ومتى بنخلص، بدون تعقيدات.”
كيف غير “سامي” كل شيء في المشروع؟
بمجرد أن أصبح “سامي” على الحائط أمامنا، تغيرت طريقة عملنا تمامًا. تحولت النقاشات من آراء شخصية إلى حوارات تتمحور حول المستخدم:
- عند اتخاذ القرار: بدلًا من “أعتقد أن هذه الميزة رائعة”، أصبح السؤال: “هل هذه الميزة ستحل مشكلة لسامي؟ هل ستساعده في تحقيق أهدافه؟”. فجأة، فكرة إضافة نظام “Gamification” المعقد بدت سخيفة، لأنها لا تخدم “سامي” في شيء.
- عند تحديد الأولويات: ميزة “لوحة التحكم الرئيسية” التي تظهر حالة كل المهام بنظرة واحدة قفزت إلى قمة الأولويات، لأنها تعالج مباشرة أكبر إحباطات “سامي”.
- عند التصميم والبرمجة: بطلنا نتخانق على لون الزر، وصرنا نفكر كيف نسهّل على سامي يوصل لهدفه بأقل عدد من الكبسات. أصبح مبدأ “البساطة” هو نجمنا المرشد، لأننا نعلم أن “سامي” ليس لديه وقت للتعقيدات.
حتى طريقة كتابتنا لقصص المستخدم (User Stories) تغيرت بشكل جذري، مما أعطى وضوحًا أكبر للمبرمجين:
As a user,
I want to see a list of tasks,
So that I can know what to do.
As Sami, a busy project manager,
I want to see a clear, one-page dashboard of all team tasks and their statuses,
So that I can quickly assess project health without digging through emails and spreadsheets.
هل ترون الفرق؟ القصة الثانية واضحة، محددة، ومليئة بالسياق. المبرمج الذي يقرأها يعرف تمامًا “لماذا” يبني هذه الميزة، وليس فقط “ماذا” يبني.
نصائح أبو عمر الذهبية لبناء شخصيات فعّالة
- لا تخترع من رأسك: الشخصية القوية مبنية على بحث حقيقي. التخمين هنا سيعيدك إلى نقطة الصفر.
- ركّز على الأهداف والإحباطات: هذه هي روح الشخصية. هي التي ستوجه قرارات التصميم والتطوير.
- اجعلها إنسانية: أعطها اسمًا، صورة، وقصة قصيرة. الفريق يتفاعل عاطفيًا مع “سامي” أكثر بكثير من “شريحة المستخدمين أ”.
- لا تكثر من الشخصيات: في معظم المشاريع، 3 إلى 5 شخصيات رئيسية تكون كافية. كثرة الشخصيات تؤدي إلى التشتت وفقدان التركيز.
- شاركها مع الجميع واجعلها مرئية: اطبع الشخصيات وعلقها على جدار المكتب. يجب أن تكون مرجعًا يوميًا لكل أعضاء الفريق، من المبرمجين والمصممين إلى فريق التسويق والدعم الفني.
الخلاصة: من الشبح إلى الشريك 🤝
ما بدأ كرحلة نحو المجهول، تحول بفضل “شخصيات المستخدم” إلى مسار واضح وهادف. لقد حولنا الشبح الغامض الذي كنا نبني له إلى شريك حقيقي في عملية التطوير، شريك له اسم ووجه واحتياجات واضحة. لم نعد نضيع الوقت في التخمين، بل أصبحنا نبني بثقة ويقين.
نصيحتي الأخيرة لك: لا تبنِ لشبح. استثمر الوقت في البداية لفهم مستخدميك، أعطهم أسماءً وقصصًا، واجعلهم بوصلتك في كل قرار تتخذه. وقتها فقط، ستبني منتجًا لا يحل مشكلة فحسب، بل منتجًا يحبه الناس ويستخدمونه فعلًا. وهاد هو الأشي المهم، صح ولا لأ؟ 😉
