باستخدام حالات الاستخدام الأساسية لتصميم تطبيق يركز على واجهة المستخدم [مغلق

Question

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

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

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

الآن لدي مشكلة أخرى: من الضروري (لا يقصد التورية) أن يكون لديك وصف واضح لتفاعل واجهة المستخدم ، لذا ، كيف يمكنني توثيقه؟ بعبارات أخرى، كيف يمكنني تحديد تطبيق من خلال استخدام حالات الاستخدام الأساسية حيث يكون تفاعل واجهة المستخدم أمرًا حيويًا له؟

أستطيع أن أرى بعض البدائل:

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

Answer 1

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

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

أنظر أيضا http://www.codinghorror.com/blog/2008/04/ui-first-software-development.html و http://www.codinghorror.com/blog/2007/01/low-fi-usebability-testing.html

Answer 2

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

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

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

انظر وصف العملية الأطول في http://www.cs.helsinki.fi/u/salaakso/papers/guide.pdf