مدونات حول التصميم

10 دروس في 10 سنوات (الجزء 3)

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

فريق تطوير تطبيقات B2B للصناعة في الولايات المتحدة

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

أحد المبادئ الأساسية لـ Agile UX هو التفكير في وقت التشغيل. حكم وقت التشغيل هو أحد الجوانب الحاسمة التي لا يبدو أن مجتمع UX قد كتب عنها الكثير. في دورة تطوير رشيقة نموذجية ، قد تحصل UXer على ما بين 2-3 أسابيع من الوقت قبل دفع التصاميم في سباق التطوير. لتحقيق أقصى استفادة من هذه الركائز القصيرة ، غالبًا ما يحتاج المرء إلى الاعتماد على الفهم المكتسب سابقًا لسلوكيات المستخدم وتوقع النوايا أثناء استخدام لوحة الرسم.

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

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

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

كل جلسة مراجعة أصحاب المصلحة أو مفاهيم التصميم لبرنامج ميكانيكا التبريد ، الدنمارك 2006

لقطة من "10 تحديات مختلفة لبيانات واجهة المستخدم لتحدي واجهة المستخدم" المذكورة أعلاه

6. مواصفات التصميم لا معنى لها ما لم يتم إثباتها من خلال قصص ذات صلة وجذابة من سياق المستخدمين (2013)

فريق متعدد الوظائف في بانكوك

غالبًا ما يعتقد المصممون أن المطورين لا يهتمون بشكل حصري بسبب سبب تصميم شيء ما بطريقة معينة. يمكن أن يكونوا مخطئين للغاية حيال ذلك.

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

تطبيق مثل الملخص التفاعلي لجميع القصص ذات الصلة التي تم التقاطها خلال جلسات الاكتشاف مع محلل المخاطر في بانكوك ، 2013

 

تابع إلى الجزء 3

أستوديو التصميم

نحن نحاول باستمرار إحداث تأثير إيجابي ، وإحداث فرق إيجابي.
أبحاث التصميم
مختبرات الابتكار
تجربة المستخدم
تصميم الخدمات
ابتكار المنتجات
أبحاث التصميم