التمييز بين مشكلة المستخدم وطلب الميزة

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

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

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