«على حسب» الجملة الأشهر في عالم تجربة المستخدم

لو اشتغلت فترة في مجال الـUX، أكيد سمعت الإجابة دي أكثر من مرة. حد يسأل: نحط الـFilters فوق ولا في Sidebar؟ نخلّي الـSign-up خطوة واحدة ولا نقسمه على كذا خطوة؟ نستخدم Modal ولا Toast Message؟ وفي الغالب الإجابة بتكون: على حسب.

في البداية، الجملة ممكن تحسها إجابة مراوغة شوية. أنت سألت سؤال واضح ومستني حد يقول لك الصح من الغلط، أو على الأقل يديك Best Practice تمشي عليها. لكن مع الوقت بتكتشف إن «على حسب» مش تهرّب من اتخاذ القرار، بالعكس، أحيانًا بتكون أكثر إجابة دقيقة ممكن تقولها، لأن قرار التصميم نادرًا ما بيكون صح أو غلط في المطلق. القرار بيبقى مناسب أو غير مناسب داخل سياق معين.

وده يمكن واحد من أهم التحولات في طريقة تفكير أي Product Designer. بدل ما تدور طول الوقت على إجابة جاهزة، تبدأ تسأل: مناسب لمين؟ في أي موقف؟ لتحقيق إيه؟ وتحت أي قيود؟

الـBest Practices مهمة، لكنها مش قوانين

طبعًا وجود Best Practices وDesign Patterns معروفة شيء مهم جدًا. إحنا مش محتاجين نعيد اختراع الـNavigation أو الـForms أو الـCheckout Flow في كل مشروع من الصفر، وفي حاجات كتير اتجربت واتدرست قبل كده ونقدر نتعلم منها.

المشكلة بتبدأ لما نحول الـBest Practice من نقطة بداية إلى إجابة نهائية. مثلًا، ممكن تقرأ إن تقليل عدد الخطوات في أي Flow أفضل للمستخدم، فتقرر إن كل عملية تسجيل لازم تكون في صفحة واحدة. الكلام يبدو منطقي، لكن ماذا لو المستخدم بيقدم على خدمة بنكية وتحتاج منه كمية كبيرة من البيانات؟ هل وضع كل شيء أمامه مرة واحدة فعلًا أبسط؟ ولا تقسيم الرحلة إلى خطوات صغيرة وواضحة هيكون أسهل؟

نفس المبدأ ينطبق على قرارات كثيرة. الحاجة نفسها ممكن تكون حل ممتاز في منتج، وحل سيئ جدًا في منتج تاني. اللي اختلف مش الـPattern نفسه، اللي اختلف هو السياق المحيط به.

مثال بسيط: فين نحط الـFilters؟

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

مين فيهم صح؟ الاتنين ممكن يكونوا صح، وممكن يكونوا غلط.

لو المنتج متجر إلكتروني على الموبايل، وعدد الـFilters كبير، والمساحة محدودة، فإخفاؤها خلف زر واضح ممكن يكون منطقي جدًا. لكن لو بتصمم تجربة بحث معقدة، زي منصة عقارات أو رحلات، والمستخدم بيعدّل الـFilters باستمرار أثناء المقارنة، فإظهارها بشكل دائم قد يكون أهم من توفير المساحة.

السؤال هنا مش: إيه أفضل مكان للـFilters؟ السؤال الأدق هو: إيه الدور اللي الـFilters بتلعبه في التجربة دي تحديدًا؟

هل هي خطوة ثانوية المستخدم بيعملها مرة واحدة؟ ولا أداة أساسية بيرجع لها كل شوية؟ هل أغلب الاستخدام Mobile ولا Desktop؟ هل المستخدم محتاج يشوف نتيجة تغييره فورًا؟ كل إجابة من دول ممكن تغيّر القرار.

ونفس الكلام مع الـNotifications

خلينا نقول إن المستخدم أضاف منتج للسلة. هل نظهر له Toast Message صغيرة ونكمل؟ ولا نوقفه بـModal في منتصف الشاشة؟

ممكن أول رد ييجي في بالك إن الـModal مزعج، وبالتالي الـToast أفضل. لكن برضه الإجابة على حسب أهمية الحدث وما الذي يحتاجه المستخدم بعده.

لو الرسالة مجرد تأكيد إن المنتج اتضاف للسلة، فغالبًا مفيش سبب نقطع تجربة المستخدم. رسالة صغيرة تؤكد العملية وتختفي ممكن تكون كفاية. لكن لو الحدث له نتيجة مهمة ويحتاج تأكيد واضح أو قرار فوري من المستخدم، فهنا طريقة العرض ممكن تحتاج تكون أكثر وضوحًا.

الفكرة إننا مش بنختار الـComponent لأنه «حديث» أو لأنه مستخدم في تطبيق مشهور. إحنا بنختاره بناءً على حجم المعلومة، وأهمية القرار، ومدى خطورة إن المستخدم يتجاهلها أو ما يفهمهاش.

خطوة واحدة ولا Multi-step Form؟

نفس النقاش بيتكرر في الـForms. هل الأفضل نجمع كل البيانات في صفحة واحدة عشان نقلل عدد الخطوات؟ ولا نقسمها إلى مراحل عشان ما نحطش كمية كبيرة من المعلومات قدام المستخدم مرة واحدة؟

لو الـForm فيها أربع خانات بسيطة، تقسيمها على ثلاث شاشات غالبًا هيزود التعقيد من غير فايدة حقيقية. لكن لو المستخدم مطالب يدخل بيانات شخصية، ويرفع مستندات، ويختار خيارات متعددة، ويراجع البيانات قبل الإرسال، فصفحة واحدة ممكن تتحول بسهولة إلى حائط طويل من الحقول.

هنا عدد الخطوات لوحده مش Metric كفاية. أربع خطوات واضحة ومفهومة ممكن تكون أسهل كثيرًا من خطوة واحدة مزدحمة. وفي المقابل، تقسيم Flow بسيط إلى مراحل كثيرة لمجرد إن الـMulti-step Forms «أفضل» ممكن يخلي التجربة أبطأ من غير سبب.

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

«على حسب» مش نهاية الإجابة

لكن في نقطة مهمة هنا. كلمة «على حسب» لوحدها مش إجابة كويسة برضه.

لو حد سألك عن قرار تصميم وقلت له «على حسب» وسكت، فأنت فعليًا ما ساعدتوش بحاجة. القيمة الحقيقية تبدأ في السؤال اللي بعد الجملة: على حسب إيه؟

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

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

بدل ما تقول: «أنا شايف إن الحل ده أحسن»، حاول تقول: «بما إن المستخدم بيكرر الخطوة دي كثير، وبيحتاج يغيّر الاختيارات أثناء المقارنة، فإظهار العنصر بشكل دائم هيقلل عليه الرجوع والخطوات الإضافية».

هنا التصميم بقى قرار يمكن مناقشته، مش مجرد Taste.

طيب، فين دور القواعد؟

وجود السياق مش معناه إننا نرمي القواعد والـHeuristics والـDesign Systems وراء ضهرنا ونبدأ نبتكر Interface جديد كل مرة. ده غالبًا هيخلق مشاكل أكثر مما هيحل.

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

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

ولو قررت تكسر Pattern معروف، لازم تكون عارف أنت بتكسره ليه، وإيه اللي بتكسبه مقابل تكلفة إن المستخدم يتعلم سلوك جديد.

السؤال الأهم قبل أي قرار تصميم

مع الوقت، بدل ما أول سؤال يكون: إيه الـBest Practice هنا؟، بيبقى عندك سؤال أهم: إيه المعلومات اللي محتاج أعرفها عشان أقدر أقرر؟

وده تغيير صغير في صياغة السؤال، لكنه فرق كبير في طريقة التفكير.

لأن شغل الـUX مش مسابقة في حفظ القوانين. القوانين والمبادئ والـPatterns أدوات تساعدك، لكن شغلك الحقيقي إنك تفهم المشكلة، والمستخدم، والهدف، والقيود، وبعدها تستخدم الأدوات دي لاتخاذ قرار مناسب.

عشان كده المرة الجاية لما تسمع Designer يقول «على حسب»، ما تعتبرهاش بالضرورة محاولة للهروب من الإجابة. اسأله السؤال اللي بعدها مباشرة:

على حسب إيه؟

هنا غالبًا هيبدأ النقاش المفيد فعلًا.

Reference

• Nielsen Norman Group : It Depends: UX Context: https://www.nngroup.com/videos/it-depends-ux-context/