البحث في الموقع

يكون الويب موجهًا للجميع عند تصميمه تصميمًا جيدًا، ولكن التصميم السيئ سيشكّل حاجزًا، مما يؤدي إلى الإخفاق ومنع الوصول والفشل في تمثيل الأفراد وحرمان المجموعات من حقوقها. يدرك الويب إمكانياته المتمثلة في العمل من أجل جميع الأشخاص -أي إمكانية الوصول وقابلية الاستخدام والشمولية-، وذلك عندما ينجح المصممون والمطورون في عملهم. يبدأ التطوّر من خلال الوضوح والتفاهم المشترك، ولكن الناس يبدّلون في عالم التصميم الرقمي وتجربة المستخدم بين المصطلحات، مما يشوّش المختصين في هذا المجال، مثلما يحدث عندما يشير العملاء إلى تجربة المستخدم UX على أنها واجهة المستخدم UI، أو عند استخدام مبدأ أجايل Agile على أنه عملية تطوير البرامج بسرعة مثلًا. وقد أدى الاستخدام غير الرسمي للمصطلحات غير الدقيقة المتعلقة بإمكانية الوصول accessibility والشمولية inclusivity إلى حدوث ارتباك يمتد إلى عالم التصميم، فهناك أوجه تشابه وتداخل بين المصطلحَين، مع وجود اختلافات رئيسية. يشرح هذا المقال الفرق بين هذين المصطلحين وأهميتهما للعاملين في مجال التصميم والتطوير. تعريف إمكانية الوصول والشمولية والاختلاف بينهما تضمن إمكانية الوصول Accessibility أن يتمكّن أيّ شخص من الوصول إلى تجربة أو وظيفة بغضّ النظر عن قدرته، إذ يركّز التعريف التقليدي لإمكانية الوصول الرقمية على تلبية احتياجات الأشخاص ذوي الإعاقة عند استخدام موقع ويب أو تطبيق أو نظام رقمي. تحدّد الإرشادات مثل إرشادات إمكانية الوصول إلى محتوى الويب في W3C، المعاييرَ التقنية والبرمجية والتفاعلية والتصميمية، مثل نسب تباين الألوان وأهداف اللمس وأحجام الخطوط والنص البديل والتنقّل باستخدام لوحة المفاتيح وما إلى ذلك، وتضمن تلبية هذه المتطلبات للأفراد الذين يعانون من إعاقات في النطق أو السمع أو البصر أو الحركة أن يفهموا ويتفاعلوا ويتنقّلوا دون عوائق بغض النظر عن قدرتهم. تستند هذه الإرشادات إلى مبادئ W3C الأربعة لإمكانية الوصول وهي: قابلية الإدراك Perceivable: يجب أن تكون المعلومات ومكونات واجهة المستخدم قابلةً للعرض على المستخدمين بطرقٍ يمكن إدراكها، حيث يمكن للشخص المصاب بإعاقة بصرية قراءة المحتوى باستخدام قارئ شاشة، أو يمكن توفير نصوص الأصوات التوضيحية للشخص الأصم. قابلية التشغيل Operable: يجب أن تكون مكونات واجهة المستخدم والتنقل قابلةً للتشغيل، إذ يجب أن يكون الأشخاص قادرين على التفاعل مع المحتوى المُدرَك سواءً عن طريق لوحة المفاتيح أو الصوت أو الفأرة أو اللمس. إمكانية الفهم Understandable: يجب أن تكون معلومات واجهة المستخدم وتشغيلها مفهومَين، حيث يجب أن يكون المستخدمون قادرين على فهم العرض المُقدَّم. المتانة Robust: يجب أن يكون المحتوى متينًا بدرجة كافية، بحيث يمكن تفسّره مجموعة متنوعة من وكلاء المستخدم بما في ذلك التقنيات المساعدة تفسيرًا موثوقًا، إذ يجب أن يكون المستخدمون قادرين على الوصول إلى المحتوى حتى في حالة تطور التقنيات. قد يكون بعض الأشخاص على دراية بمبادئ وإرشادات إمكانية الوصول السابقة، ولكنهم قد لا يكونون على دراية بمستويات التوافق conformance المختلفة، حيث يحدد كل مستوى بوضوح المتطلبات التي يمكن تطبيقها ومراقبتها وهي: المستوى A: وهو المستوى الأدنى من خلال تلبية جميع متطلبات إمكانية الوصول الأساسية. المستوى AA: يتمثّل بتلبية متطلبات إمكانية الوصول متوسطة المستوى، وهو المستوى الذي تهدف الشركات إلى الوصول إليه. المستوى AAA: وهو تلبية أكبر عدد من المتطلبات، ويتضمّن المستويات A وAA وAAA. تؤثّر المكونات المتعددة التي يجب أن تعمل جميعها معًا على إمكانية الوصول، مثل مكونات محتوى الويب بما في ذلك العناصر الموجودة على الشاشة وخارجها والشيفرة البرمجية، حيث تؤثر هذه المكونات على طريقة الوصول إلى المحتوى مثل المتصفحات والصوت والمشغّلات والبرمجيات، وعلى طريقة الإنتاج مثل البرمجيات والخدمات وأدوات التأليف authoring tools وأنظمة إدارة المحتوى وسكربتات التشغيل وغيرها. تتعلق معايير إمكانية الوصول إلى حد كبير بمعمارية وتنسيق المعلومات وكيفية تقديمها، ولكنها لا تتعلق بالمعلومات بحد ذاتها، إذ قد تكون الكلمات والصور ومقاطع الفيديو عديمة القيمة أو مسيئةً أو تمييزيةً أو متحيزة، ولكن لا يزال يمكن الوصول إليها. لا يضمن اتباع أفضل الممارسات المتعلقة بإمكانية الوصول شعور الأشخاص بأنهم ممثَّلون ويريدون استخدام شيء ما أو الإعجاب به، فهذا هو المجال الذي يناسبه اتباع نهج التصميم الشامل. التصميم الشامل Inclusive Design: من القدرات إلى وجهات النظر تسعى الشمولية إلى إنشاء شيء يمكن لجميع الأشخاص استخدامه مع وجود الرغبة في استخدامه أيضًا، وهي تشمل الأشخاص ذوي القدرات المختلفة إلى جانب الأقليات والسكان المتنوعين.يُعَد التصميم الشامل نهج تصميمٍ يأخذ في الحسبان تنوع سمات الأشخاص وخبراتهم وأحوالهم، مثل: الجنس. العمر. الموقع. الحضارة. اللغة. التعليم والثقافة. الكفاءة والخبرة التقنية. العوامل الاجتماعية والاقتصادية. البيئة الفيزيائية. التقنية والأجهزة والاتصالات. تعرِّف مايكروسوفت Microsoft التصميم الشامل بأنه منهجيةٌ نشأت من البيئات الرقمية، حيث تتيح هذه المنهجية مجال التنوع البشري الكامل وتعتمد عليه، وهذا يعني تضمين الأشخاص الذين لديهم مجموعةً من وجهات النظر والتعلم منهم. يكون الهدف من التصميم الشامل هو إنتاج موقع ويب أو واجهة أو منتج رقمي يمكن استخدامه على أوسع نطاقٍ ممكن، وذلك بغض النظر عن الحالة أو القدرة. لا يحتوي التصميم الشامل على قواعد موثَّقة أو إطار عمل محدَّد، على عكس التصميم الذي يمكن الوصول إليه، والذي حدد المتطلبات والإرشادات، لأن التصميم الشامل يركّز على عملية صنع التصميم الذي سيرغب الجميع في استخدامه، فهو أكثر عاطفيةً وأقل منطقية، وبالتالي لا يوجد نهج قابل للتطبيق عالميًا ومناسبٌ للجميع، إذ قد يتضمن التصميم الناتج حلولًا مختلفة. كتبت خبيرة ورائدة التصميم الشامل سوزان جولتسمان Susan Goltsman: وهذا يطرح سؤالين مرتبطين وهما: السؤال الأول: هل التصميم الذي يمكن الوصول إليه شامل، وهل يمكن الوصول إلى تصميم شامل؟ يمكن أن يدعم التصميم الذي يمكن الوصول إليه جوانب التصميم الشامل، ولكن تركيزه الأساسي سينصبّ على معالجة الإعاقات وليس على الانتماء الأوسع، بينما يفيد التصميم الشامل جميع المستخدمين سواء كانوا يعانون من إعاقة أم لا. يجب أن تؤدي عملية التصميم الشامل إلى تصميم يمكن الوصول إليه، ولكن ليست التصاميم التي يمكن الوصول إليها شاملةً دائمًا. السؤال الثاني: هل التنوع diversity يعني الشمول inclusion، وهل التصميم لأحدهما يضمن كليهما؟ يشير التنوع إلى أوجه التشابه أو الاختلاف بين الأفراد فيما يتعلق بالتركيبة السكانية وخصائص هويتهم، مثل الهوية الجنسية والعمر والعرق. من بين الأمثلة التي يمكن أن يعتمدها المصممون، نجد اختيار صور متنوعة مثل الصور الفوتوغرافية لأشخاص ليسوا سليمي البنية أو ان لديهم صفة مختلفة عن العادة، وذلك للابتعاد عن الصور النمطية؛ بينما بالنسبة لصانعي المحتوى، فإن استخدام الضمائر المحايدة بين الجنسين أو الشاملة في الكتابة أو استخدام لغة الشخص الأول person-first language من شأنه أن يأخذ التنوع في الحسبان. يمثّل التنوع الاختلاف بين الأفراد، بينما تمثّل الشمولية طريقة احتضان الأفراد ذوي الهويات المتنوعة وإدماجهم. أسباب أهمية إمكانية الوصول والشمولية يريد معظمنا عالمًا يحقق المساواة ويتيح الفرص نفسها للجميع، فالشيء العادل والصحيح الذي ينبغي عمله هو أن يتمتع كل شخص بوصول متساوٍ إلى المعلومات والخبرات الرقمية. ولكن إن لم تلتزم القيادة أو المالكون بالأخلاق وحدها في عالمٍ يكون فيه المال أكثر أهمية من الأشخاص، فإليك كيفية تأثير هذه المفاهيم أو تجاهلها على المحصلة النهائية. تقليل المخاطر تتعرض الشركات لخطر أن تكون هدفًا لدعاوى قضائية عندما يتعذر الوصول إلى التصاميم، وتتزايد الدعاوى القضائية بسبب عدم الامتثال لقانون الأمريكيين ذوي الإعاقة والمادة 508، فإذا تعذّر الوصول إلى شيءٍ ما، فهذا يمثّل تمييزًا. خلق قيمة للأعمال تخلق المنتجات الأفضل مزيدًا من القيمة، فإن لبَّت مواقع الويب أو التطبيقات أو الحلول الرقمية مزيدًا من احتياجات الأشخاص، فستتمتع بجاذبية أوسع وستستهدف مزيدًا من الأسواق، وكلما زاد عدد الأشخاص الذين يمكنهم استخدام المنتج، زادت احتمالية النجاح والربح. تحسين رضا العملاء يُعَد الاحتفاظ بالمستخدمين والعملاء أسهل من اكتساب عملاء جدد، وتزداد احتمالية رضا العملاء واستمرار عودتهم إليك من خلال فهم واحتضان ومعالجة تنوع قاعدة المستخدمين، وهذا مفيدٌ للأفراد والشركات. اتخاذ الإجراءات التي يمكن أن ينفذها مجتمع تجربة المستخدم UX يعرف المبتدئون والخبراء في تجربة المستخدم UX على حد سواء أن هناك دائمًا فرصة لجعل الأمور أسهل وأكثر فاعليةً وجاذبية. إليك كيفية البدء في إنشاء تصميمات ذات إمكانية وصول وشمولية أكبر: تحديد الأهداف والأولويات التي تتعلق بإمكانية الوصول أو الشمولية بناءً على جمهور المشروع وأهدافه وموارده. الاستفادة من الإرشادات والأدوات الراسخة لتحديد مجالات التحسين وتتبّع التقدم. التوظيف والتعاون والاختبار مع مستخدمين متنوعين لفهمٍ أفضل للتحديات والفرص. الاستمرار في استخدام مناهج وتقنيات تجربة المستخدم التي أثبتت جدواها مثل إجراء البحوث واستخدام الشخصيات personas ذات الصلة والتخطيط العاطفي empathy mapping وتحديد حالات الاستخدام والاختبارات التكرارية. طلب المساعدة من الخارج من خلال جلب الخبراء، أو استخدام الخدمات الخارجية لتقييم إمكانية الوصول أو مراجعات الشيفرة البرمجية أو اختبار المستخدم. بناء الفرق المتنوعة التي ستؤثر هوياتها ووجهات نظرها وخبراتها المختلفة على التصميمات. لا يمكن تحسين التجربة لكل مستخدم، ولكن يمكن تطبيق شيءٍ ما لجذب مزيدٍ من الأشخاص عند اقترابهم من التصميم، فهناك دائمًا طريقة لتحسين التجربة وتحقيق نتائج أفضل. مصادر التصاميم التي تتمتع بإمكانية الوصول والشمولية معايير W3C لإمكانية الوصول. قائمة أدوات إمكانية الوصول الخاصة بالويب في W3C. تطوير جوجل لإمكانية الوصول. أداة فحص إمكانية الوصول من أدوبي. إضافات إمكانية الوصول من ووردبريس. مجموعة أدوات التصميم الشامل من مايكروسوفت. دليل التصميم الشامل من مركز الأبحاث الشامل. فيديو جون مايدا John Maeda: تصميم فرق ومنتجات شاملة، تصميم من أجل التنوع. ترجمة -وبتصرّف- للمقال Accessibility and Inclusivity: Distinctions in Experience Design لصاحبته Jennifer Leigh Brown. اقرأ أيضًا تصميم تجربة تهيئة المستخدم User Onboarding الكتابة لتجربة المستخدم UX Writing أساس التهيئة الفعالة للواجهات ما هي الكتابة لتجربة المستخدم UX Writing؟ تاريخ موجز عن تجربة المستخدم

في كل مرة أسمع فيها كلمة "بيان" (manifesto) تسري رعدة في جسدي، إذ أنها متصلة في ذهني دومًا بالسياسة، ألا ترى أن الساسة الذين لا يستحقون الثقة يستخدمونها قبل الخوض في سيل وعود ما قبل الانتخابات، والتي سيتناسونها مباشرة بعد خداع الناس كي يعطوهم أصواتهم؟ لكن البيان الذي أسعد بالقول أني لا تصيبني نفس الرعدة حين أسمع به هو بيان Agile (التطوير المرن) لتطوير البرامج، ذلك الذي يضع مبادئ عامة لتطوير البرمجيات. وقد ظهر هذا البيان نتيجة حيرة سببها أسلوب الشلال التقليدي "Waterfall process" الذي كانت تُجهَّز فيه كل المتطلبات دفعة واحدة مقدَّمًا، وترسم التصاميم وتُعتَمد ثم تُختَبر، وكل ذلك بأسلوب خطي (Linear). وقد كان ذلك أسلوبًا عقيمًا ومرهقًا وغير فعّال لتطوير البرامج. ثم اجتمع بعض المطورين في فبراير من 2001 بعد أن سئموا هذا الأسلوب وخرجوا بشيء أفضل، وهو أسلوب Agile لتطوير البرمجيات -حيث agile تعني مرن-، وكتبوا بيانًا يضعون فيه المبادئ العامة لهذا المنظور الجديد من أجل نشره في وسط المبرمجين: وقد ألهمني بيان Agile فوضعت بياني الخاص حول تجربة المستخدم كي أنشر ما أظنها بعض المبادئ المهمة في تجربة الاستخدام، وأنا أسوقها إليك فيما يلي. التعاون عوضًا عن العمل في صوامع كتبت فيما مضى عن كيف أن تجربة المستخدم تشبه الرياضة الجماعية، ويجب أن يُنظر إليها هكذا، ذلك أن التعاون مفتاح لتصميم تجربة مستخدم رائعة، سواء كان تعاونًا مع مصممين آخرين أو مطورين أو خبراء في النطاقات (domains) أو المستخدمين أنفسهم أو حاملي الأسهم في الشركة، …إلخ. ولأن تجربة المستخدم هي المساحة المشتركة بين كل من حاجة المستخدم وقيود التقنية وأهداف الشركة، فلا يمكن أن تكون أي شيء غير مجهود جماعي، أما البديل فيشبه أسلوب "اقذفها من فوق السور" الذي لا زالت بعض شركات التصميم تستخدمه للأسف. إذ يجلس بعض المصممين في برجهم العاجي ليخرجوا ببعض التصاميم التي "تبدو" رائعة ثم يلقونها من برجهم ذاك إلى فريق التطوير كي يعتمدها، وقد ركّزت على كلمة "تبدو” لأن تلك التصاميم لا تجتاز قنطرة الفحص والمراجعة لأنها بُنيَت على افتراضات فقط. ثم يأتي حملة الأسهم ليشتكوا أن أحدًا لم يستشرهم في تلك التصميمات، ويشتكي فريق التطوير أن التصميمات يستحيل تطبيقها واعتمادها، ويجد المستخدمون أنفسهم في النهاية أمام تصميم لا يحل مشكلتهم أو يلبي حاجاتهم. النماذج الأولية التفاعلية، عوضًا عن التوثيق الثابت إنني أكره كتابة التوثيق لأنه نشاط ممل يدمّر نفسيتي في كل مرة، ولا أحد يقرؤها في النهاية، ويجب أن تُحدَّث كلما تغير التصميمات أو المتطلبات، ومن الصعب أن تكتب التوثيق بدرجة تفصيل مناسبة، فالإسهاب أكثر من اللازم يجعل المطورين يهربون من قراءته، وكذلك الإيجاز أكثر من اللازم يجعلهم يكثرون من الأسئلة حتى لَتَعجَبَ من جدوى التوثيق أصلًا. من أجل ذلك فإني أفضّل النماذج الأولية التفاعلية، فهي أفضل طريقة لعرض التصاميم ومتطلباتها لأنها تظهر كيف ستعمل التصميمات في سياقها، أو على الأقل في سياق افتراضي، فبدلًا من توثيق مرهق عن ماذا سيحدث حين ينقر المستخدم على هذا أو ذاك، يمكنك ببساطة أن تعرض ذلك الحدث كتفاعل في النموذج الأولي. ويحب المطورون النماذج الأولية لأنها تريهم كيف سيعمل التصميم، ويحبها حملة الأسهم لأنها تريهم التصميم حيًا يتحرك أمامهم، وكذلك فإن من يختبر التصميمات يحبونها أيضًا لأنها تريهم كيف يعمل التصميم وكيف سيبدو في النهاية. والأهم من هذا كله أن النماذج الأولية مهمة لجمع الملاحظات من المستخدمين من خلال جعلهم يتفاعلون مباشرة مع التصميم. وقد صار من السهل جدًا هذه الأيام أن تنشئ تصميمات تفاعلية بسرعة بسبب كثرة الأدوات التي تقوم بهذا والتي زادت في السوق مؤخرًا. يمكنك إنشاء نموذجًا أوليًا بسرعة وبسهولة باستخدام برنامج مثل Axure. التصميم للمستخدمين عوضًا عن التصميم لحملة الأسهم إن مصطلح UX يختصر كلمتي User eXperience واللتان تترجمان إلى "تجربة المستخدم"، لطالما تساءلت لماذا كانت X وليس E من الكلمة الثانية، لعلها تبدو أجمل هكذا، المهم أني أريدك أن تذكّر نفسك بمعنى هذا الاختصار في كل مرة يأتيك أحد حملة الأسهم ليحاول التحكم في مسار أو شكل تصميم ما. ذلك أنك تصمم للمستخدم بالنهاية، وليس لحملة الأسهم، ولو كان حملة الأسهم هم من يدفعون المال لهذا التصميم كي يخرج إلى النور فإن المستخدمين هم في النهاية من يحكمون على نجاح أو فشل التصميم وليس حملة الأسهم. فالتصميم الرائع لتجربة المستخدم يدور حول العثور على نقطة وسط بين حاجات المستخدم وقيود التقنية وأهداف الشركة. فلا شك أن حملة الأسهم لن يفكروا في أي شيء سوى المال، وكذلك الفِرَق التقنية لن تفكر في أي شيء سوى قيود التقنيات التي يستخدمونها، فيؤول الأمر في النهاية إلى تجربة الاستخدام ومن يختبرها كي يعتنوا بالمستخدمين من خلال التفكير في حاجاتهم وتلبيتها. ما يحتاجه المستخدمون، عوضًا عما يريدونه إنني والد لطفلين صغيرين، وأنا أعلم -كأي أب- أن ما يريده الأطفال يختلف تمامًا عما يحتاجونه حقًا، فلو أني تركتهم لما يريدون لقضوا أغلب النهار في مشاهدة التلفاز وهم يأكلون الشوكولاتة والكعك والمثلجات. وكذلك فإن مهمة معرفة حاجات المستخدم تقع على عاتق المصممين وليس المستخدمين أنفسهم، ويدعم ستيف جوبز -أحد مؤسسي Apple- هذا الكلام بقولته المشهورة "ليست مهمة المستخدمين أن يعرفوا ما يريدون". وقد كتبت من قبل عن كيف أن المستخدم ليس دائمًا على حق، فلا يمكنك أن تعرف ما يحتاجونه بمجرد سؤالهم، بل عليك أن تفهمهم وتفهم مشاكلهم وأهدافهم، وسبب حيرتهم، ودوافعهم، والمهام التي يريدون تنفيذها. صحيح أن بإمكانك سؤالهم وإشراكهم في كل خطوة من عملية التصميم، لكن لا تتوقع أن يقوموا بعملك بدلًا عنك. ما يفعله المستخدمون عوضًا عما يقولونه لقد راقبت عن كثب مئاتٍ من جلسات اختبار سهولة الاستخدام عبر السنوات الماضية، قضيت فيها ساعات تلو ساعات أشاهد فيها الناس تستخدم تقنيات من هنا وهناك، وقد وجدت نمطًا يتكرر في كل تلك الجلسات، وهو أن ما يقوله المستخدمون يختلف تمامًا عما فعلوه. إليك مثالًا لتوضيح قصدي: أنا: كيف وجدت هذا المنتج من حيث سهولة استخدامه؟ المشارِك: أوه، لقد كان سهلًا، لم أعاني أية مشكلة في استخدامه. أنا: حقًا؟ لم تختبر أية مشكلة؟ المشارِك: لا. أنا: فماذا عن المهام الثلاثة التي لم تستطع إتمامها، أو تلك النافذة التي قلتَ أنَّ من صممها غبي؟ المشارِك: آه صحيح! .. لكن بخلاف ذلك، لقد وجدته سهل الاستخدام. قد يستحي المشاركون من الاعتراف أن منتجًا ما صعب الاستخدام، أو أنهم يرفضون الاعتراف أن هم اضطروا لتنفيذ الأمر بطريقة ملتوية، بل إنهم حتى قد لا يتذكروا أنهم واجهوا مشاكل أصلًا، إذ تخبرنا قاعدة peak-end أننا نميل إلى تذكّر لقطات سريعة من أي تجربة، فحين يخبرك أحدهم أنه وجد س أو ص سهل الاستخدام رغم أنك راقبته ووجدت الأمر خلاف ذلك، فاعلم أنَّه لا يحاول خداعك، بل في الغالب يعني ما يقول. فما أريد قوله هو أن المهم هو ما يفعله المستخدمون حقًا، وليس ما يقولونه، سواء كان ذلك في تجربة استخدام أو مراقبة مستخدمين أو جمع بيانات استخدام أو حتى سؤال أحدهم أن يصف مهمة أو وظيفة يقوم بها. ملاحظات المستخدمين، عوضًا عن الافتراضات لقد كتبت من قبل "لماذا يجب أن يقوم المصممون بدراسات، ولماذا يجب أن يصمم الباحثون"، فدراسة المستخدم (User Research) وملاحظات المستخدم (User Insights) التي تخرج من دراسة جيدة للمستخدمين هي حجر الزاوية في تصميم تجربة استخدام ناجحة. أما بدون هذه الملاحظات التي تجمعها من المستخدمين فإنك تصمم بناءً على افتراضات، وتخيل معي أنك تصمم منزلًا مثلًا على أساسات هشّة ثم لا يلبث أن ينهار ويخرّ متهدّمًا، فكذلك التصميم بناءً على افتراضات غير واقعية. لكن لا أريدك أن تسيء فهمي، فالافتراضات ليست سيئة في ذاتها، فوضع افتراضات والعمل عليها ثم تقييمها وتعديلها خلال سير العمل فيما بعد قد يسرّع عملية التصميم -طالما أنك تقيّمها فعلًا--. لكن يجب أن تكون ملاحظات المستخدمين هي ما تقود تصميماتك، وليس الافتراضات، فكما قال جوبز "كلما زاد فهمك للتجارب البشرية، كانت تصميماتك أفضل". الواقعية عوضًا عن مثالية التصميم المرتكز حول المستخدم لقد قدّمت عرضًا قبل بضع سنين بعنوان يقول "كيف تخلصت من عادة التصميم حول المستخدم وتعلمت أن أحب التصميم الرشيق لتجربة الاستخدام" في UX Cambridge. وقد تحدثت حول تجربتي مع التصميم المرتكز حول المستخدم (User-Centered Design) وكيف بدأت في اعتماد عقيدة جديدة هي التصميم الرشيق لتجربة المستخدم. فكما ترى فإن لي علاقة حب وكراهية معًا مع هذا التصميم، فأنا أحب فكرة وضع المستخدمين في قلب عملية التصميم، لكني أكره حقيقة أن مشاريع ذلك النوع من التصميم لا تبتعد عادة عن مؤشر الصفر، أو تكون بطيئة ومكلّفة، ولا تقدّم ما وعدت به في البداية. فأظن أن بعض ذلك سببه أننا -مصممي تجربة المستخدم- نميل عادة إلى المثالية حين نعمل في مثل هذه المشاريع، فربما يقول أحدنا "نحن نحتاج على الأقل إلى 12 مستخدمًا قبل أن نفكر في اعتماد التصميم" أو "نحن نحتاج إلى ميزانية كذا وكذا لأعمال دراسات المستخدمين وحدها!". وصحيح أني معجب بالتصميم الرشيق لتجربة المستخدم لكني أريده أن يكون عمليًا فهذا أهم عندي، وقد ذكرت في كلمتي التي ألقيْتها مثلًا عن صيغة mp3، فالشخص المثالي هنا سيكون ذلك الذي لن يتردد في شراء نظام Hi-Fi رغم ثمنه الباهظ، وستجده يتحدث عن مساوئ مشغلات mp3، وكيف أن جودة الصوت منها رديئة وباهتة وصناعية. لكن بالنسبة لنا -باقي المستخدمين لهذه التقنية- فإن الاستماع إلى ملفات بهذه الصيغة عبر سماعات الأذن العادية التي يكون صوتها غير نقي غالبًا، أو حتى عبر مكبرات صوت عادية، أكثر من كافٍ طالما أنه يؤدي الغرض، ناهيك أننا نستمع إلى تلك الملفات في أماكن مزدحمة غالبًا وبها ضجيج أو ضوضاء، فهذه جودة أكثر من جيدة في الواقع. ألن يكون أفضل أن يكون لديك صيغة تعطيك صوتًا أفضل وأغنى بالتفاصيل والطبقات؟ بالتأكيد! لكن من المنظور العملي (pragmatic)، فإن الجودة التي تعطيها صيغة mp3 ممتازة في 99% من الحالات. والشاهد من مثالي الطويل هذا أنك يجب أن تطبّق نفس المبدأ في التصميم المرتكز حول المستخدم، فلا تبذل أكثر من الجهد الذي يخرج معك نتائج مشابهة للتي كان التصميم المرتكز حول المستخدم ليُخرجها، فقط، ولا تزد على ذلك. فلا تخشى تعديل دراسات أسلوبك في دراسات تجربة الاستخدام وأعمال التصميم، فذلك خيرٌ من أن تكون مثاليًا. خاتمة ها قد انتهيت من بياني لتجربة المستخدم، ألخصه لك فيما يلي: التعاون عوضًا عن العمل في صوامع. النماذج الأولية التفاعلية، عوضًا عن التوثيق الثابت. التصميم للمستخدمين عوضًا عن التصميم لحملة الأسهم. ما يحتاجه المستخدمون، عوضًا عما يريدونه. ما يفعله المستخدمون عوضًا عما يقولونه. ملاحظات المستخدمين، عوضًا عن الافتراضات. الواقعية عوضًا عن مثالية التصميم المرتكز حول المستخدم. وأنا أريد الآن أن أسمع منك، فماذا ترى؟ وما هي القواعد التي تريدها في "بيانك" الخاص بك؟ ملاحظة: “ … وأعلم أن هناك قيمة في العناصر على اليمين، لكني أقدّر العناصر على اليسار أكثر". ترجمة -بتصرف- لمقال A UX manifesto لصاحبه Neil Turner

في السّنوات الأخيرة ازداد الطلب على مُصمّمي تجربة المستخدم لدرجة عالية جدًا، كما ازداد عدد الكتب التي تتحدّث عن هذا الموضوع وأُضيف لهذا التخصّص قوانين، نظريات وفلسفيات من أجل تطويره وتحسينه. إذا عدنا بالزّمن للوراء إلى بداية البرامج الحاسوبية، تجد أن مهندسين البرامج ومديري المنتجات كانوا يُعلّمون بأن البرنامج إذا ازدادت ميزّاته ووظائفه ازدادت مبيعاته. هذا كان صحيحًا وذلك لأنه لم يكن السّوق مليئا بالبرامج والمنتجات التقنية مما لا يدع للمستخدم أي خيار سوى أن يشتري هذا البرنامج حتى ولو كان معقّدًا من ناحية الاستخدام. إذا نظرنا الآن نجد أنّ البرامج والحلول التقنية في أيّ موضوع بسيط، مثلا تنظيم المهام، تجد أن عدد البرامج المتوفرة قد يجاوز المائة كحد أدنى مما يجعل المستخدم أمام كثير من الخيارات ويفتح باب المنافسة لأسهل البرامج استخدامًا، أجملها واجهة وحتى أكثرها متعة. إنّ من أهم المزايا التنافسية في الشركات العملاقة في عالمنا اليوم أمثال Google ،Apple ،Microsoft ،Samsung هي تجربة المستخدم. فعلى سبيل المثال جهاز بلاك بيري، كانت أجهزة بلاك بيري هي الرّائدة في سوق الهواتف الذكية ولكن عندما دخلت Apple بجهاز iPhone الذي كان بتطبيقات وخصائص عملية أقل من البلاك بيري، استطاعت أن تحصل على النّسبة الأكبر من السوق. هناك عوامل تنافسية كثيرة بين المنتجات ولكن بالنسبة لمنتجين متشابهين وقابلين للمقارنة تجربة المستخدم من أهم العوامل. ولتوضيح الفكرة أكثر انظر مثلا إلى جهاز iPod، بشكله البسيط، الرائع، الممتع في استخدامه وطرريقة ربطه مع برنامج iTunes، ما لبث أن ينزل على السّوق حتى أحَبه الجميع، مع العلم بوجود أجهزة تؤدي نفس الوظائف الرئيسية التي يؤديها iPod. ماهي تجربة المستخدم وماذا يندرج تحتها؟ الكثير من الناس يخطئ في فهم تجربة المستخدم أو قد يختزلها في موضوع معين، فمثلا هناك من يخلط ما بين تجربة المستخدم وواجهة المستخدم User Interface أيضا هناك من يخلط ما بينها وبين سهولة الاستخدام، لا يتّسع المجال لذكر كل المفاهيم الخاطئة فلذلك سنقوم في البداية بشرحٍ بسيط لتجربة المستخدم ومن ثم نقوم بتوضيح أكثر المفاهيم الخاطئة انتشارًا. تجربة المستخدم مجمل التأثير الذي يشعر به المستخدم كنتيجة لتفاعله واستخدامه لنظام (برنامج)، جهاز أو منتج متضمنا تأثير كل من سهولة الاستخدام والمنفعة والتأثير العاطفي. مع مراعاة أن التفاعل مع المنتج يتضمن النظر، اللمس، التفكير، الإعجاب بالمنتج وصورة المنتج في ذهن المستخدم قبل تجربته. لذا يمكن القول أن كلاً من سهولة الاستخدام والمنفعة والتأثير العاطفي هي عناصر مكونة لتجربة المستخدم. ولكن ماذا يعني كل عنصر من هذه العناصر ضمن إطار تجربة المستخدم، سأقوم بكشف هذا الغموض في توضيح هذه العناصر. سهولة الاستخدام هي العنصر العملي لتجربة المستخدم ويتضمن الفعالّية، الكفاءة، الإنتاجية، المرونة، القدرة على التعلم والاحتفاظ، ومدى رضا المستخدم. المنفعة العنصر المسؤول عن مدى تحقيق الوظائف التطبيقية للمنتج لأهداف المستخدمين، بمعنى هل حقق استخدام المنتج غايات المستخدمين وأهدافهم عندما أرادوا استخدامه. التأثير العاطفي العنصر العاطفي الذي يؤثر على عواطف المستخدم بشكل عام. ولكثرة العواطف وصعوبة حصرها سنذكر أكثرها أهمية ومراعاة مثل المتعة، السرور، الاستمتاع أثناء الاستخدام، جاذبية المنتج، أصالته، الرغبة باستخدامه وإبداعيته. كما يدخل أيضا فيها المشاعر العميقة مثل التعبير، الهوية الذاتية، الشعور بالمساهمة في العالم وفخر الملكية. تجربة المستخدم لا يمكن تصميمها تجربة المستخدم هي شعور داخلي يشعر به المستخدم أثناء استخدامه للمنتج ولذلك لا يمكن تصميمها، ولكننا نُصمّم المنتجات بحيث تعطي للمستخدم هذه التجربة، أي أننا نُصمّم لأجل تجربة المستخدم ولا نُصمّم التجربة ذاتها. حتى أن الكثير من المصممين اقترحوا تغيير مصلطح مصمم تجربة المستخدم إلى مهندس تجربة المستخدم أو المخطط الاستراتيجي لتجربة المستخدم. تجربة المستخدم ليست واجهة المستخدم واجهة المستخدم UI ليست إلا واجهة يقوم المستخدم بالتفاعل معها ليقوم بالوظائف التطبيقية التي يقوم بها النظام، ووجود كلمة مصمم هي ما أدت إلى الوقوع في هذا اللبس، فظن البعض أن مصمم تجربة المستخدم مثل مصمم الواجهات أو التصميم المرئي على Photoshop مثلا. في الحقيقة مصممي تجربة المستخدم يقومون بالتصميم ولكن ليس بالطريقة المعروفة في التصميم المرئي وإنما يقومون بتصميم الشيء غير المرئي ليقوموا بحلِ مشكلة ما أو تحسين العملية الوظيفية. سهولة الاستخدام مهمة ولكن تجربة المستخدم أكثر من ذلك مع بداية تطور هذا العلم ونضجه أصبحت الكثير من الشركات التقنية تتبنّى المبادئ الهندسية لسهولة الاستخدام وتستثمر في المختبرات المعقدة وتساهم في وضع اختبارت لسهولة الاستخدام، كل هذا وبلا شك رفع من جودة المنتجات من ناحية سهولة الاستخدام إلا أنه ثبت فيما بعد أن سهولة الاستخدام ليست هي الميزة التنافسية الوحيدة بين المنتجات وظهرت هناك عوامل تنافسية أخرى فيما بين المنتجات. لذلك، بالرغم من أن سهولة الاستخدام هي من أساسات تجربة المستخدم ولكنها لا تقف فقط هنا، فالتركيز في تصميم تجربة المستخدم يعود على البشر وليس على التقنية. تجربة المستخدم ليست محصورة على البرامج والأنظمة التصميم لتجربة المستخدم ليس محصورا على البرامج أو المواقع الإلكترونية، ولكنه يضم أيضا التصميم لكافة المنتجات سواء كانت برمجية أو مادية. فمثلا، وأنت تقوم بسحب النقود من الصراف الآلي فأنت تشعر بتجربة معينة نتيجة لانتظارك في الصف، لقرائتك للتعليمات، لإدخالك البطاقة ولسحبك النقود. تخيل ماذا لو كانت نافذة الصراف الآلي أطول أو أقصر منك ماذا لو قَرَأتِ البطاقة ولم تخرجها أو أخرجت مبلغا غير الذي طلبت. ما أحاول أن أصل إليه هنا هو أن المنتجات في كل مكان ونتفاعل معها في حياتنا اليومية وانتباهك لهذه المنتجات سيحسّن من طريقة تفكيرك كمُصمم لتجربة المستخدم وسيعمّق من نظرتك للأمور. سير العملية والاستراتيجة في تصميم تجربة المستخدم بالنظر إلى تجربة المستخدم وعناصره، يتضح لنا كم هو واسع إطار تجربة المستخدم وعن كمية الأشياء الهائلة التي يمكن أن تندرج تحته، لذلك لا بد من منهجية عمل تسهل بناء المنتجات بطريقة احترافية مع المحافظة على إمكانية الإبداع فيها. في الصورة أعلاه هناك خمس خطوات لإصدار النسخة الأولية من المنتج أو البرنامج وهو ما يسمى في الشركات الناشئة بالمنتج الفعّال القاعدي (Minimum Viable Product) أما الخطوتان الأخيرتان فهما تعودان إلى ما بعد الإصدار الأول وذلك لإنه حتى نصل إلى جودة عالية في المنتج لا بد من التكرار والتحسين عليه، بناءً على التغيرات التي تحدث في العالم (تطور التكنولوجيا، زيادة المنتجات المنافسة، …) وبناءً على رُدود الفعل من المستخدمين. منهجية العمل البحث: أنت لست المستخدم النهائي للمنهج وبالتالي لا بد لك من عمليات بحث مع أصحاب العمل ومع الجمهور المستهدف والتخطيط لكيفية بناء المنتج وما التكنولوجيا المستخدمة حتى تتمكن من فهم الأهداف من وراء المنتج. وبالعادة يتم استخدام البحث النوعي أو الإثنوجرافي (Ethnography) في بداية أية مشروع. المعالجة: تقارير البحث النهائية ليست كافية لتبدأ التصميم، هناك فجوة ما بينها وما بين التصميم، لا بد من معالجة نتائج البحث بحيث يمكن ترجمتها إلى أشياء قابلة للتصميم والعمل. التصميم: هنا نبدأ بالتصميم ولكن المقصود بالتصميم ليس التصميم المرئي فقط، يتم التصميم عبر خطوات من رسم ونماذج حتى الوصول للنموذج البصري النهائي في التصميم المرئي. الاختبار: إن كان هناك أخطاء معينة في التصميم فلا بد لك من معرفتها قبل أن يكتشفها المستخدم بنفسه، لذا لا بد من التأكد هل ما تم تصميمه مفهوم وسهل الاستخدام أم هو معقد ولا يصل للأهداف المرجوة. في هذه المرحلة يتم الاختبار للتصميم الذي قمنا به مع العلم بأنه يسير بشكل متوازي مع مرحلة التصميم بمعنى أنه لا نقوم بالاختبار عندما ننتهي من الخطوة الثالثة نهائيا وإنما نقوم باختبار كل مرحلة من مراحل التصميم في الخطوة السابقة. الإصدار: في هذه المرحلة نقوم بإطلاق الإصدار الأول ولكن مع وضع المعايير التي سوف تحدد نجاح أهدافنا التي سوف نقوم بقياسها بعد أن يتم تجربة البرنامج من قبل المستخدمين، ويتم التركيز هنا على البحث الكمي. القياس: عندما يصبح لدينا معلومات عن سلوك المستخدمين وكيفية استخدامهم لمنتجنا نقوم بتحليل هذه المعلومات وترجمتها إلى مرحلة التعلم. التعلم: عندما تبدأ بقياس النتائج سيتضح لك سلوك المستخدمين الحقيقي وليس الذي افترضته، هنا تتعلم أكثر عن حاجات وسلوك المستخدمين ومن ثم تقوم بترجمة هذه المعلومات إلى تحسينات، وعادة يتم استخدام البحث الكمي والنوعي في هذه المرحلة. لمزيد من القراءة مقال 10Most Common Misconceptions About User Experience Design مقالات UX Myths كتاب The Elements Of User Experience كتاب Don't Make Me Think