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