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