سر النماذج الأولية الأسرع؟ ثق بفريق الخبراء لدينا.

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

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

لا يحتاج النموذج الأولي الجيد إلى أن يبدو مكتملًا. يجب أن يساعدني في الإجابة على الأسئلة الصحيحة حول المنتج قبل أن أنفق الوقت والمال على التطوير. تبدأ العديد من الفرق بشاشات مصقولة وميزات تفصيلية ودورات موافقة طويلة. بعد الإطلاق، قد يكتشفون أن المستخدمين لا يمكنهم العثور على إجراء رئيسي، أو لا يفهمون قيمة المنتج، أو يفضلون مسارًا أبسط. يمنحني النموذج الأولي طريقة لاختبار هذه النقاط مبكرًا، عندما يكون إجراء التغييرات أسهل. ## ابدأ بمشكلة مستخدم واحد أبدأ بكتابة جملة واحدة واضحة: "يحتاج المستخدم إلى ______ لأن ______." على سبيل المثال: "يحتاج المستخدم إلى مقارنة خيارات التسليم لأن الاختيار بين السعر والسرعة يبدو مربكًا." يحافظ هذا البيان على تركيز النموذج الأولي. إذا حاولت حل خمس مسائل في وقت واحد، يصبح من الصعب قراءة اختبار المستخدم. قد أقوم بجمع العديد من التعليقات دون معرفة أي مشكلة تؤثر على المنتج أكثر من غيرها. يمكن أن يغطي النموذج الأولي المُركز مهمة قصيرة، مثل: - إنشاء حساب - حجز موعد - مقارنة خطط الخدمة - تحميل مستند - التحقق من حالة الطلب ## اختر المستوى المناسب من التفاصيل يمكن للرسم الورقي أن يجيب على أسئلة حول الهيكل والتدفق. يمكن للإطار السلكي القابل للنقر أن يُظهر كيفية تنقل الأشخاص بين الشاشات. يمكن أن يساعد النموذج الأولي عالي الدقة في اختبار التخطيط والصياغة والتسلسل الهرمي المرئي وتفاصيل التفاعل. لا أستخدم التصميم المرئي التفصيلي عندما يتمكن رسم بسيط من الإجابة على السؤال. القاعدة المفيدة هي: - استخدم تفاصيل منخفضة لاختبار الفكرة - استخدم تفاصيل متوسطة لاختبار التدفق - استخدم تفاصيل عالية لاختبار التجربة - هذا يبقي العمل مرتبطًا بالقرار الذي أحتاج إلى اتخاذه. كما أنه يقلل من خطر تلميع الشاشة التي قد تتم إزالتها لاحقًا. ## خريطة أقصر مسار مفيد أكتب فيه رحلة المستخدم قبل تصميم كل شاشة. بالنسبة لخدمة الحجز، قد يبدو المسار كما يلي: 1. اختر خدمة 2. حدد تاريخًا 3. راجع السعر 4. أكد الحجز 5. احصل على رسالة تأكيد يجب أن يتضمن المسار تفاصيل كافية للمستخدم لإكمال المهمة. يمكن للقوائم والإعدادات والميزات الجانبية الإضافية الانتظار. عندما أراجع سير العمل، أسأل: - هل تدعم كل شاشة المهمة؟ - هل يعرف المستخدم ما يجب فعله بعد ذلك؟ - هل يمكن للمستخدم العودة دون فقدان التقدم؟ - هل من السهل العثور على الأسعار والتواريخ والشروط الأساسية؟ - ماذا يحدث عندما يرتكب المستخدم خطأ؟ غالبًا ما تكشف هذه الأسئلة عن الفجوات قبل أن يصل النموذج الأولي إلى العميل. ## استخدم المحتوى الواضح قبل التلميع البصري لوريم إيبسوم يخفي المشاكل. أستخدم نصًا قصيرًا وواقعيًا يعكس المنتج. بدلاً من كتابة "إرسال"، قد أكتب "إرسال طلب موعد". بدلاً من "الخيار أ"، قد أكتب "التسليم القياسي - من 3 إلى 5 أيام". تساعدني الملصقات الواضحة في اختبار ما إذا كان الأشخاص يفهمون المنتج أم لا. كما أنها تكشف مشاكل التخطيط. قد يصبح من الصعب استخدام الزر الذي يبدو جيدًا مع كلمتين مع تسمية أطول وأكثر فائدة. يجب أن يجيب المحتوى على الأسئلة الأساسية للمستخدم: - ما هذا؟ - ماذا يمكنني أن أفعل هنا؟ - ماذا سيحدث بعد ذلك؟ - ماذا سأدفع؟ - هل يمكنني تغيير الإجراء أو إلغاؤه؟ ## الاختبار مع مجموعة صغيرة لا أحتاج إلى مشروع بحثي كبير للعثور على مشكلات سهولة الاستخدام الأساسية. يمكنني أن أطلب من عدد قليل من الأشخاص الذين يتناسبون مع الجمهور المستهدف إكمال مهمة واحدة دون تعليمات مفصلة. قد تتضمن جلسة بسيطة ما يلي: “من فضلك احجز خدمة ليوم الثلاثاء القادم وأخبرني بما تتوقع حدوثه بعد التأكيد”. أشاهد المكان الذي يتوقف فيه الشخص مؤقتًا، أو ينقر على عنصر التحكم الخاطئ، أو يطلب المساعدة، أو يستسلم. أتجنب شرح الشاشة مبكرًا لأن شرحي قد يخفي مشكلة سيواجهها المستخدمون في المستقبل. بعد الجلسة، أسجل: - محاولة المهمة - نقطة الارتباك - الكلمات التي استخدمها المستخدم - الإجراء الذي توقعته - الإجراء الذي اتخذه المستخدم - تغيير محتمل في التصميم - الإيقاف المؤقت دليل مفيد. وكذلك سؤال مثل "هل هذا هو السعر النهائي؟" يخبرني أن الشاشة قد لا توفر معلومات كافية. ## فرز التعليقات حسب تأثير المنتج لا يتطلب كل تعليق تغييرًا في التصميم. قد يفضل شخص واحد لونًا مختلفًا. قد يفشل العديد من الأشخاص في العثور على الإجراء الرئيسي. ولا ينبغي لهذه القضايا أن تحظى بنفس الاهتمام. أقوم بتجميع التعليقات في ثلاث مناطق: فشل المهمة لا يمكن للمستخدم إكمال الإجراء الرئيسي. احتكاك المهام يمكن للمستخدم إكمالها، لكن المسار يبدو بطيئًا أو مربكًا. التفضيل الشخصي يقترح المستخدم تغييرًا لا يؤثر على نجاح المهمة. أتعامل مع فشل المهمة قبل التفضيلات المرئية. وهذا يساعد الفريق على قضاء وقت التصميم والتطوير في المشكلات التي تؤثر على استخدام المنتج. ## البناء والاختبار والضبط في دورات قصيرة أتعامل مع النموذج الأولي كسؤال عملي، وليس كإجابة نهائية. قد تبدو دورة واحدة كما يلي: 1. تحديد سؤال منتج واحد 2. إنشاء الشاشات اللازمة لاختباره فقط 3. مطالبة المستخدمين المستهدفين بإكمال مهمة 4. تسجيل الإجراءات والتعليقات 5. تغيير التدفق أو المحتوى 6. اختبار الإصدار المنقح على سبيل المثال، قد يختبر التطبيق المالي ما إذا كان الأشخاص يفهمون ملخص الإنفاق. يمكن للفريق إنشاء نسختين من نفس الشاشة. يستخدم المرء المجموع الشهري في الأعلى. يعرض الآخر تفاصيل الفئة أولاً. يمكن أن تكشف جلسات المستخدم عن التخطيط الذي يساعد الأشخاص في الإجابة على السؤال التالي: "أين ذهبت أموالي هذا الشهر؟" لا يحتاج الاختبار إلى إثبات التصميم المثالي. يجب أن يوضح الاتجاه الذي يستحق المزيد من العمل. ## حافظ على ارتباط التصميم والتطوير بالنموذج الأولي الذي يمكن أن يوفر الوقت فقط عندما تصل نتائجه إلى الأشخاص الذين يقومون ببناء المنتج. أشارك مهمة المستخدم وملاحظات الاختبار وتدفق الشاشة والأسئلة المفتوحة مع المصممين والمطورين ومديري المنتجات وفرق الدعم. يمكن أن تتضمن عملية التسليم القصيرة ما يلي: - الغرض من النموذج الأولي - مهمة المستخدم التي تم اختبارها - نقاط الاحتكاك الرئيسية - التغييرات المعتمدة - الأسئلة التي لا تزال بحاجة إلى أدلة - التفاصيل التي لا تشكل جزءًا من النطاق الحالي وهذا يقلل من الافتراضات. يمكن للمطور معرفة سبب تغيير الخطوة. يمكن لفريق الدعم الاستعداد للأسئلة التي قد تظهر بعد الإصدار. ## تجنب الاختصار الذي يؤدي إلى المزيد من العمل غالبًا ما يكون النهج الأسرع هو بناء كل شيء قبل التحدث مع المستخدمين. يمكن أن ينتج هذا المسار منتجًا مصقولًا بتدفق ضعيف. لقد وجدت أن النموذج الأولي البسيط القابل للنقر غالبًا ما يعطي اتجاهًا أفضل من مستند مميز طويل. يمكن للمستند أن يصف ما يجب أن يفعله المنتج. يتيح النموذج الأولي للأشخاص التفاعل مع ما سيفعلونه بالفعل. الهدف ليس إنشاء المزيد من الشاشات. الهدف هو معرفة ما يكفي لاتخاذ قرار سليم بشأن المنتج. إن عملية إنشاء النماذج الأولية القوية تجعل مهمة المستخدم صغيرة، والأسئلة واضحة، والتعليقات قريبة من أعمال التصميم. أتحرك بشكل أسرع عندما أختبر الأجزاء الخطرة مبكرًا، وأستخدم محتوى عاديًا، وأغير فقط ما تدعمه الأدلة. اتصل بنا على lingchao: mr.xu@lingchaopcb.com/WhatsApp +8613780181891.

1. ستيف كروج، 2000، لا تجعلني أفكر: نهج منطقي لقابلية الاستخدام على الويب 2. إريك ريس، 2011، The Lean Startup: كيف يستخدم رواد الأعمال اليوم الابتكار المستمر لإنشاء أعمال تجارية ناجحة بشكل جذري 3. جاكوب نيلسن، 1993، هندسة قابلية الاستخدام 4. جيف جوتهلف وجوش سايدن، 2013، Lean UX: تطبيق المبادئ اللينة لتحسين تجربة المستخدم 5. كلايتون إم كريستنسن، تادي هول، كارين ديلون وديفيد إس دنكان، 2016، تعرف على وظائف عملائك التي يجب القيام بها 6. دونالد أ نورمان، 2013، تصميم الأشياء اليومية