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

لحسن الحظ، وصلنا في القرن الحادي والعشرين إلى مستوى من الذكاء الاصطناعي يسمح لنا بتوقع أن تتحدث المنتجات الرقمية “مثل البشر” بدلاً من التحدث بلغتها الروبوتية الخاصة!

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

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

ما علاقة التصميم التحاوري بكتابة تجربة المستخدم (UX Writing)؟

تعتبر Google Developers التصميم التحاوري مزيجاً من عدة تخصصات:

تصميم واجهة المستخدم الصوتية (Voice User Interface Design)، تصميم التفاعل (Interaction Design)، تصميم الصوت (Audio Design)، التصميم المرئي (Visual Design)، تصميم الحركة (Motion Design)، وأخيراً كتابة تجربة المستخدم (UX Writing).

دعونا نتوسع في الموضوع قليلاً

تبدأ القصة من حقيقة أن هدفنا في كتابة UX ليس إنشاء نص مؤثر، غني أدبياً، دائم ومُمتع.

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

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

ثمانية قوانين للتصميم التحاوري

المبادئ الثمانية التالية مستمدة من قوانين التصميم التحاوري المذكورة في كتاب “Conversational Design” والتي تمنحنا نظرة أكثر دقة وتفصيلاً.

هذه القوانين هي في الواقع نفس مبادئ المحادثات اليومية التي نتعلم الكثير منها منذ الطفولة، بشكل تجريبي وفي السياق الاجتماعي.

أولاً، التفاعل ثنائي الاتجاه شرط أساسي

الشرط الضروري في أي محادثة هو أن تكون ثنائية الاتجاه وتشاركية. في الواقع، لكي “يتشكل” التفاعل، يجب على كل طرف أن يلعب دوره. إن جعل تفاعل المستخدم مع المنتج أحادي الاتجاه وتحويل هذا الحوار إلى مونولوج يعطل التبادل الضروري لخلق تجربة مستخدم جيدة.

ثانياً، يجب أن يكون التفاعل موجهاً بالأهداف

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

في المقابل، يجب أن يذهب المنتج أيضاً إلى المستخدم بهدف واضح. إذا لم نعرف ما يبحث عنه المستخدم، فكيف نحدد ما إذا كان قد وصل إلى هدفه أم لا؟!

ثالثاً، لا ينبغي أن يكون المنتج خارج السياق!

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

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

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

هذا مثال واضح على عدم وعي المنتج، أو بلغتنا الخاصة “خروجه عن السياق”، بظروف وسياق التفاعل.

رابعاً، التحدث بطريقة غير مباشرة يجعل التفاعل غير فعال

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

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

خامساً، المونولوج خط أحمر لدينا

في المحادثة الجيدة، يتناوب طرفا التفاعل كمتحدثين ومستمعين نشطين.

إذا لم نسمح للمستخدم أو المنتج بالتواصل لفترة طويلة، سيتحول التفاعل إلى مونولوج، وهذا ما لا ينبغي أن يحدث تحت أي ظرف من الظروف!

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

ملاحظة! وضح بشكل دقيق دور كل طرف في كل مرحلة من مراحل تفاعل المستخدم مع المنتج. هل يجب أن ينتظر المستخدم المنتج، أم أن المنتج ينتظر المستخدم؟

سادساً، الثقة هي مفتاح التفاعل البناء!

من وجهة نظر ديتر رامس (Dieter Rams)، “صدق المنتج” هو أحد مبادئ التصميم الجيد العشرة. المنتج المصمم جيداً لا يبدو أكثر ابتكاراً أو كفاءة أو قوة مما هو عليه بالفعل.

في تصميم التفاعل أيضاً، خداع المستخدم هو خط أحمر. من ناحية أخرى، إذا اختصرنا صدق المنتج في “عدم استخدام عبارات مخالفة للواقع”، فإننا نخدع أنفسنا.

كون نظام أرصاد جوية على الإنترنت يبلغ عن الطقس وفقاً للواقع لا يعني أنه صادق؛ بل ببساطة يؤدي واجبه!

لتوضيح المقصود، تخيل أنك دخلت متجراً وفي بداية دخولك، تسير محادثتك مع البائع على النحو التالي: أنت: مرحباً. أود رؤية ملابس مريحة للأولاد لعمر خمس سنوات. البائع: مرحباً. هل سبق لك التسوق هنا؟ أنت: لا، هذه المرة الأولى. البائع: هل يمكنك تقديم معلومات الاتصال الخاصة بك حتى أسجلك في نادي العملاء؟ أنت: لكنني لم أشترِ بعد. حتى أنني لا أعرف ما إذا كان لديك الملابس التي أبحث عنها. البائع: لدينا خصم خاص لأعضاء نادي العملاء. انضم وأنا متأكد من أنك ستصبح عميلاً!

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

وفقاً لمجموعة نيلسن نورمان (Nielsen Norman Group)، فإن دعوات العمل ذات التسميات مثل Get Started (أو بلغتنا، ابدأ/هيا بنا) هي أمثلة بارزة على خداع المنتج. في مثل هذه الظروف، بينما يجب على المنتج أن يقدم نفسه في تفاعله الأول مع المستخدم، فإنه يوجه المستخدم إلى مسار مربك وغير ضروري لإنشاء حساب.

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

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

سابعاً، يجب أن يكون المنتج مهذباً!

احترام وقت المستخدم قد يكون أهم عنصر للأدب في تصميم التفاعل.

المنتج الذي يضغط على المستخدم بعروض غير ضرورية ومتنوعة، ويربكه بنصوص غير واضحة، أو يرسل رسائل إعلانية غير ذات صلة، سيرى قريباً نتيجة أفعاله!

التصميم المهذب يحقق أهداف العمل ويكسب رضا المستخدم.

ثامناً، المستخدم عرضة للخطأ!

إذا أدخلنا عنوان بريدي خاطئ في موقع تسوق عبر الإنترنت، فكم من الوقت يستغرق تصحيحه؟ سهولة تصحيح الخطأ في تجربة المستخدم تحدد مدى إنسانية التفاعل.

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

الحقيقة هي أن حتى إنسان القرن الحادي والعشرين يخطئ أيضاً! لذا دعونا لا نعاقب المستخدم على أخطائه