كثرة الخيارات تدفع المستخدمين إلى الانسحاب

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

أعطيت المستخدمين المزيد، وجعلت المنتج أسوأ. هذا هو فخ الميزات.

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

يشتري الناس تعقيدًا أكثر مما يحتاجون

أطلق Debora Viana Thompson, Rebecca Hamilton, وRoland Rust اسمًا على هذا النمط في عام 2005: الإرهاق من كثرة الميزات. قبل أن يملك الناس المنتج، تجعله الميزات الإضافية يبدو واسع الإمكانات. وبعد أن يملكوه، تتحول الميزات نفسها إلى أشياء عليهم أن يختاروا من بينها ويتعاملوا معها.

وتناول Barry Schwartz المشكلة نفسها من زاوية أخرى. فكثرة الخيارات غالبًا ما تولّد مزيدًا من الندم والتجنب، لا مزيدًا من الرضا. وقبل ذلك بوقت طويل، قاس William Hick الكلفة بصيغة أبسط: الخيارات الأكثر تبطئ اتخاذ القرار.

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

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

معظم ما أضفته لا يُستخدم

في عام 2019، درست Pendo 615 منتجًا برمجيًا، ووجدت أن 80 بالمئة من الميزات نادرًا ما تُستخدم أو لا تُستخدم إطلاقًا. لهذا الرقم أهمية، لأن الميزات غير المستخدمة لا تبقى في الشيفرة فحسب. بل تظهر في القوائم، والإعدادات، وخطوات البدء، والتنقل، وصفحات المقارنة.

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

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

أصبح Jira منتجًا مليئًا بالقرارات

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

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

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

Jira مثال جيد لأن الألم لا يأتي فقط من الجهد الذي يتطلبه. بل من أنه يظل يطلب من المستخدمين اتخاذ قرارات لم يأتوا لاتخاذها أصلًا.

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

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

وهذا أحد أسباب أهمية الخيارات الافتراضية هنا. فالخيارات الافتراضية الجيدة تتيح للمنتج اتخاذ القرار السهل نيابةً عن المستخدم. أما السيئة فتلقي عليه العبء كاملًا وتسمي ذلك مرونة.

عُدّ القرارات

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

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

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

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

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