تجربة المستخدم هي الناس مش التكنولوجيا
لما نتكلم عن تجربة المستخدم، سهل جدًا إن تركيزنا يروح ناحية التكنولوجيا نفسها: سرعة التطبيق، شكل الواجهة، جودة الـAnimations، عدد الـFeatures، أو حتى مدى تعقيد النظام اللي الفريق قدر يبنيه. كل ده مهم طبعًا، لكنه مش النقطة اللي بتحدد إذا كانت التجربة ناجحة فعلًا أو لأ.
في الفيديو السابع من سلسلة جاكوب نيلسن، بيختصر الفكرة في جملة بسيطة جدًا: “UX is People” : تجربة المستخدم هي الناس.
المقصود هنا إن التكنولوجيا مهما كانت متطورة، هي في النهاية مجرد وسيلة. اللي بيحدد نجاح التجربة هو الشخص اللي بيستخدمها: هل فهمها؟ هل عرف يعمل اللي داخل يعمله؟ هل النظام ساعده ولا عطله؟ وهل التجربة متوافقة أصلًا مع طريقته في التفكير وتوقعاته واحتياجاته؟
وده فرق مهم، لأننا أحيانًا بنقيس جودة المنتج بالحاجة الغلط.
التكنولوجيا ممكن تبهر الفريق والمستخدم يفضل تايه
تخيل إنك بتشتغل على تطبيق جديد، والفريق متحمس جدًا للتفاصيل التقنية. الانتقالات بين الشاشات ناعمة، الـAnimations معمولة بعناية، الواجهة شكلها حديث، وكل Interaction فيها لمسة مختلفة. من ناحية التنفيذ، المنتج ممكن يكون ممتاز.
لكن المستخدم يدخل التطبيق ومش عارف يبدأ منين.
مش فاهم اسم الزرار اللي محتاجه، مش قادر يتوقع الخطوة اللي بعدها، أو محتاج يلف بين كذا شاشة عشان يعمل حاجة المفروض تكون بسيطة. وقتها كل القوة التقنية الموجودة في المنتج مش هتغير حقيقة واحدة: التجربة نفسها مش شغالة كويس.
وده مش معناه إن التكنولوجيا غير مهمة. بالعكس، التكنولوجيا ممكن تفتح حلول ماكانتش ممكنة قبل كده، وتخلي المنتج أسرع وأسهل وأكثر قدرة. لكن قيمتها الحقيقية بتظهر لما تكون في خدمة احتياج حقيقي عند الناس، مش لما تتحول هي نفسها إلى الهدف.
السؤال مش: نقدر نبني إيه؟ السؤال: الناس محتاجة إيه؟
من الطبيعي جدًا إن الفرق تبدأ أحيانًا من الإمكانيات المتاحة. عندنا Technology جديدة، أو Feature نقدر ننفذها، أو Tool تخلينا نعمل Interaction ملفت، فيبدأ السؤال: إزاي نستخدمها؟
لكن من منظور تجربة المستخدم، السؤال الأهم غالبًا بييجي قبل ده: هل في مشكلة أصلًا محتاجة الحل ده؟
ممكن تقدر تضيف عشر Features جديدة، لكن لو المستخدم محتاج واحدة منهم فقط والباقي بيزود عليه التعقيد، فوجود الإمكانية التقنية مش سبب كفاية لاستخدامها.
وممكن تعمل Flow ذكي جدًا من الناحية التقنية، لكن لو طريقة عمله مختلفة تمامًا عن توقعات المستخدم من غير داعٍ حقيقي، فأنت نقلت جزءًا من تعقيد النظام إلى الشخص اللي المفروض النظام يساعده.
عشان كده فهم الناس مش خطوة صغيرة بنعملها في أول المشروع ونرجع بعدها للتصميم. هو المرجع اللي المفروض ترجع له طول الوقت وأنت بتاخد القرارات.
التصميم الجيد يبدأ من سلوك الناس، مش من افتراضاتنا عنهم
جزء كبير من شغل الـUX هو إنك تخرج شوية من الطريقة اللي أنت شايف بها المنتج، وتحاول تفهمه من زاوية الشخص اللي هيستخدمه.
إنت كـDesigner أو Developer ممكن تكون شايف الـFlow عشرات المرات، وعارف كل زرار بيعمل إيه، وعارف المنطق اللي ورا النظام. المستخدم مش عنده الخلفية دي، وغالبًا مش مهتم يعرفها أصلًا. هو داخل عشان يحقق هدف معين، وكل اللي يهمه إن الطريق للهدف ده يكون مفهوم.
وده معناه إن التصميم مش لازم يمشي مع توقعات الفريق، لكنه لازم يحترم الـMental Model والتوقعات اللي المستخدم داخل بها.
هل الكلمات المستخدمة مفهومة بالنسبة له؟ هل ترتيب الخطوات منطقي؟ هل النظام بيديله Feedback واضح بعد كل Action؟ هل الأخطاء بتتشرح بطريقة تساعده يصلحها؟ وهل إحنا بنطلب منه معلومات فعلًا محتاجينها، ولا مجرد بيانات اتعودنا نجمعها؟
الأسئلة دي شكلها أبسط من الكلام عن التكنولوجيا، لكنها غالبًا أقرب للحاجات اللي بتحسم جودة التجربة فعلًا.
وحتى فريق الـUX نفسه ناس
جاكوب نيلسن بيوسع الفكرة كمان لنقطة مهمة: الناس مش بس هم المستخدمين الموجودين خارج الشركة. الناس كمان هم الفريق اللي بيصمم ويبني المنتج.
ممكن يكون عندك Designers شاطرين وDevelopers ممتازين وProduct Managers عندهم خبرة، لكن لو كل فريق بيشتغل بمعزل عن الثاني، أو كل شخص عنده تصور مختلف عن المشكلة الأساسية، فالنتيجة ممكن تكون تجربة مفككة جدًا رغم إن كل جزء منها اتنفذ بشكل كويس لوحده.
وده لأن تجربة المستخدم النهائية مش بتطلع من ملف Figma واحد أو من قرار Designer واحد. هي نتيجة مجموعة كبيرة من القرارات الصغيرة اللي بتتخذها فرق مختلفة، من أول الـResearch والـContent لحد الـDevelopment والـSupport.
لو الفرق دي مش فاهمة بعضها أو مش متفقة على مين المستخدم وإيه المشكلة اللي بتحاول تحلها، المستخدم هو اللي هيشعر بالتناقض في الآخر.
طيب، نعمل إيه كمصممين؟
الفكرة مش إننا نقلل اهتمامنا بالتكنولوجيا، لكن إننا نرتب الأولويات بشكل صح. قبل ما نسأل أي Tool هنستخدم، أو أي Pattern هنطبق، أو إزاي نخلي الـInteraction أكثر إبهارًا، لازم نفهم الأول مين الشخص اللي بنصمم له وإيه اللي بيحاول يعمله.
ابدأ بالمشكلة قبل الحل. حاول تفهم سياق الاستخدام، مش بس الـTask نفسه. راقب اللغة اللي الناس بتستخدمها، والخطوات اللي بيتوقعوها، والمشاكل اللي بتوقفهم، وبعدها استخدم التكنولوجيا عشان تقلل الاحتكاك ده.
والأهم إنك ما تعتبرش نفسك ممثلًا للمستخدم. كونك بتستخدم التطبيقات كل يوم مش معناه إن توقعاتك هي نفس توقعاته. كل ما القرار يكون مهم، حاول تخليه مبني على Research أو Observation أو Data بدل ما يكون مجرد إحساس داخلي عند الفريق.
في الآخر، المستخدم هو الحكم
ممكن الفريق يكون فخور جدًا بالمنتج، والتكنولوجيا المستخدمة فيه تكون متقدمة، والتنفيذ يكون ممتاز من الناحية التقنية. لكن لو الناس مش قادرة تستخدمه بسهولة، فكل ده مش هيحول التجربة إلى تجربة جيدة.
وده جوهر جملة “UX is People”.
تجربة المستخدم مش عن التكنولوجيا في حد ذاتها، لكنها عن العلاقة بين الناس والتكنولوجيا. كل زرار، وكل شاشة، وكل Feature ليها قيمة فقط بالقدر اللي بتساعد به شخص حقيقي يعمل حاجة محتاجها.
التكنولوجيا هتتغير، والـTools اللي بنستخدمها النهارده ممكن يتغير شكلها بالكامل بعد كام سنة. لكن السؤال اللي المفروض يفضل ثابت هو: هل اللي بنبنيه فعلًا مناسب للناس اللي هيستخدموه؟
لأن في النهاية، إحنا مش بنصمم للتكنولوجيا. إحنا بنستخدم التكنولوجيا عشان نصمم للناس.