ما هي مبادئ تصميم واجهة المستخدم مثل" فصل المخاوف " التي يمكنني استخدامها لإقناع المطورين بأن واجهة المستخدم تحتاج إلى إصلاح?[مغلق]

Question

مغلق.يجب أن يكون هذا السؤال أكثر مركزة.لا يقبل حاليا الإجابات.

---

تريد تحسين هذا السؤال? قم بتحديث السؤال بحيث يركز على مشكلة واحدة فقط من خلال تحرير هذا المنشور.

مغلق منذ 5 سنوات.

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

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

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

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

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

لقد لخصت كمبدأ لتصميم واجهة المستخدم أن"واجهة مستخدم واحدة يجب ألا تحتوي على شيئين مختلفين تماما".بينما جادلوا بأنهم يريدون دفع مثل هذا الجهد وكل الجهد الجانبي (مثل المزيد من واجهة المستخدم ، والمزيد من المواقف لحل واجهة المستخدم ، والمزيد من جهد التطوير/الاختبار/الصيانة مقارنة بتصميم واجهة المستخدم الذي يفصل بين الأمرين المختلفين) ، للمستخدم للحصول على برنامج سهل الاستخدام وسهل الاستخدام.بالطبع بكل تأكيد, أنا لا أتفق تماما مع هذا التصريح, كيف يمكن أن يكون البرنامج غير الجيد في كل جانب آخر مفيدا للمستخدم?وليس هناك ما يمكن قياسه لأن فريق التصميم ليس لديه تصميم كامل حتى الآن.

وينتهي الأمر مع لا أستطيع إقناع الفريق.كل شيء يبدو لا يزال موضوعيا.

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

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

من فضلك لا تغلق هذا:) هذه مشكلة كبيرة حقا بالنسبة لي كمدير ديف.

Answer 1

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

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

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

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

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

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

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

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

بحث على شبكة الإنترنت حتى تتحول العديد من المقالات والكتب.وهنا مادة جيدة جدا لتبدأ:http://alistapart.com/article/usability-testing-demystified

الفقرة الأولى من ويكيبيديا حول اختبار قابلية الاستخدام يقول:

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

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

Answer 2

كنت على اتصال على عدة جوانب مختلفة في هذا السؤال;انا ذاهب الى التركيز على إدارة تجربة المستخدم.

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

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

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