تصميم احترافي: وصول أسرع إلى السوق بمقدار 3 مرات.

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

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

تفقد العديد من الفرق الوقت قبل أن يبدأ العمل الفعلي. ينتقل الطلب عبر البريد الإلكتروني والدردشة والمجلدات المشتركة ومكالمات المراجعة. أصبحت الملفات قديمة. تؤدي التغييرات الصغيرة إلى إنشاء جولات جديدة من الموافقة. وبحلول الوقت الذي يصبح فيه الفريق جاهزًا للتسليم، يكون الموعد النهائي قد اقترب ويكون هناك مساحة أقل للميزانية. أرى هذا النمط غالبًا في التصميم وعمل المنتج. نادرا ما تكون المشكلة في نقص الموهبة. سير العمل يحمل الكثير من الاحتكاك. يمكن أن تساعد العملية الأكثر ذكاءً الفرق على التحرك بشكل أسرع مع الحفاظ على الجودة تحت السيطرة. قد يكون هدف التسليم الأسرع 3 مرات ممكنًا لبعض المشاريع، لكن ذلك يعتمد على النطاق وحجم الفريق وسرعة التعليقات والأدوات المستخدمة بالفعل. وينبغي التعامل معه كهدف للمشروع، وليس كنتيجة مضمونة. ## ابدأ بملخص واحد واضح أبدأ كل مشروع بملخص قصير يجيب على خمسة أسئلة: - ما الذي نقوم بإنشائه؟ - من سيستخدمه؟ - ما هي المشكلة التي يجب أن تحلها؟ - ما الذي يجب تسليمه؟ - كيف سيقوم الفريق بمراجعة العمل؟ الموجز الواضح يمنع قرارات التصميم من أن تصبح تفضيلًا شخصيًا. إنه يمنح الفريق نقطة مرجعية مشتركة عند ظهور أفكار جديدة. على سبيل المثال، قد يحدد ملخص الصفحة المقصودة العميل المستهدف، والإجراء الرئيسي، والأقسام المطلوبة، وقواعد العلامة التجارية، وتاريخ الإطلاق. وهذا أكثر فائدة من الرسالة التي تقول: "من فضلك اجعل الصفحة تبدو جديدة". ## تحويل الطلبات الغامضة إلى مهام مرئية غالبًا ما تخفي الطلبات الكبيرة العديد من المهام الصغيرة. أقوم بتقسيمها إلى خريطة تسليم بسيطة: 1. جمع المادة المصدر 2. تأكيد الصفحة أو بنية المنتج 3. إنشاء اتجاه التصميم الأول 4. مراجعة الاتجاه 5. إنشاء الإصدار المعتمد 6. اختبار النتيجة 7. إعداد الملفات النهائية تحتاج كل مهمة إلى مالك وتسليم واضح. عندما تكون الملكية غير واضحة، ينتظر العمل في المساحة بين الفرق. يمكن أن تعرض لوحة المشروع ما هو جاهز، وما يحتاج إلى مراجعة، وما هو محظور. الأداة لا تحتاج إلى أن تكون معقدة. يمكن أن يعمل الجدول المشترك إذا قام الجميع بتحديثه باستمرار. ## راجع الاتجاه قبل صقل التفاصيل يبدأ التأخير الشائع عندما يقضي الفريق ساعات في ضبط الألوان والأيقونات والمسافات قبل الاتفاق على التصميم الرئيسي. أفضّل مراجعة الاتجاه مبكرًا. في هذه المرحلة، أركز على مسار المستخدم وترتيب المحتوى وبنية الصفحة والرسالة الرئيسية. يمكن أن يظل التصميم قاسيًا. الهدف هو العثور على مشاكل كبيرة بينما لا تزال التغييرات سهلة. قد يقوم فريق صغير للتجارة الإلكترونية باختبار تخطيطين لصفحة المنتج مع خمسة مستخدمين قبل إنشاء الصفحة الكاملة. إذا لم يتمكن المستخدمون من العثور على تفاصيل الشحن أو فهم اختيار المنتج، فيمكن للفريق إصلاح البنية دون إعادة صياغة الواجهة بأكملها. وهذا النهج يوفر الجهد لأنه يقرب القرارات الرئيسية من بداية المشروع. ## تعيين قاعدة التعليقات تصبح التعليقات بطيئة عندما يرسل الأشخاص تعليقات متفرقة عبر قنوات مختلفة. أستخدم مساحة مراجعة واحدة وموعدًا نهائيًا واحدًا لكل جولة مراجعة. يجب أن تشير التعليقات إلى جزء معين من العمل وتشرح سبب التغيير. "اجعله أفضل" لا يساعد المصمم على التصرف. إن "نقل السعر بالقرب من اسم المنتج لأن المستخدمين يفتقدونه على الهاتف المحمول" يمنح الفريق مهمة واضحة. يمكن أن تتضمن قاعدة المراجعة ما يلي: - يقوم شخص واحد بجمع التعليقات - تبقى التعليقات في مكان واحد - لكل جولة غرض ثابت - لا يتم إعادة فتح الأقسام المعتمدة دون سبب واضح - يتم تسجيل الطلبات الجديدة كمهمة منفصلة، ​​مما يحافظ على تركيز الفريق دون حجب المدخلات المفيدة. ## بناء أجزاء قابلة لإعادة الاستخدام لا أبدأ كل مشروع من شاشة فارغة. تعمل الأزرار القابلة لإعادة الاستخدام وحقول النموذج والبطاقات وقواعد التباعد وأنماط المحتوى على تقليل العمل المتكرر. تساعد مكتبة المكونات المشتركة أيضًا في الحفاظ على اتساق المنتج. عندما يتغير الزر، يمكن للفريق تحديث المكون المعتمد بدلاً من البحث في كل صفحة. يجب أن تتوافق المكتبة مع المشروع. تقوم العديد من المكونات غير المستخدمة بإنشاء أعمال الصيانة الخاصة بها. أبقي المجموعة صغيرة، وأسمي كل جزء منها بوضوح، وأضيف أمثلة توضح متى يجب استخدامها. ## قياس سرعة التسليم بعناية: تحتاج العملية الأسرع إلى أكثر من مجرد ادعاء جريء. أتتبع بعض الأرقام العملية: - الوقت من الموافقة الموجزة إلى التوجيه الأول - عدد جولات المراجعة - الوقت المستغرق في انتظار التعليقات - عدد التغييرات بعد الموافقة - الوقت من الموافقة النهائية إلى التسليم تظهر هذه الأرقام أين يتباطأ العمل. وقد يكتشف الفريق أن التصميم نفسه يستغرق ثلاثة أيام، بينما يستغرق انتظار المحتوى ثمانية أيام. إن إضافة المزيد من المصممين لن يحل هذه المشكلة. سيكون للموعد النهائي للمحتوى وتعيين مالك المحتوى تأثير أكبر. ولهذا السبب يجب اختبار الرسالة "أسرع بثلاث مرات" مقابل خط أساس واضح. قارن بين المشاريع المماثلة ذات النطاق المماثل. سجل ما تغير. إبقاء المطالبة مقتصرة على الشروط التي تدعمها. ## حماية الجودة أثناء التسليم السريع للسرعة قيمة قليلة إذا أدت إلى حدوث أخطاء أو ملفات غير واضحة أو تجربة مستخدم سيئة. أقوم بإجراء فحص قصير للجودة قبل التسليم: - هل يعمل التصميم على أحجام الشاشة المطلوبة؟ - هل من السهل العثور على الإجراءات الرئيسية؟ - هل أنماط النص والمسافات متسقة؟ - هل يتم تغطية الروابط والنماذج والحالات؟ - هل أسماء الملفات وإصداراتها واضحة؟ - هل تم استخدام المحتوى المعتمد؟ الفحص لمدة عشر دقائق يمكن أن يمنع دورة تصحيح طويلة بعد الولادة. أفضل سير عمل ليس هو الذي يجعل الناس يتعجلون. وهو الذي يزيل الانتظار الذي يمكن تجنبه، والقرارات المتكررة، والملكية غير الواضحة. عندما أقوم بتوصيل مراجعة توجيهية مختصرة ومبكرة وملاحظات مركزة ومكونات قابلة لإعادة الاستخدام وتتبع بسيط، يكتسب الفريق المزيد من التحكم في التسليم. قد تصل بعض المشاريع إلى تحسين السرعة بمقدار 3x. قد يرى آخرون مكاسب أصغر. تكون كلتا النتيجتين مفيدتين عندما تصبح العملية أسهل في الفهم والتحسين. اتصل بنا على Grace: jialilong_grace@jialilong.com/WhatsApp +8613506667735.

1. دون نورمان 2013، تصميم الأشياء اليومية، الطبعة المنقحة والموسعة 2. إريك ريس 2011 The Lean Startup 3. مارتي كاجان 2017 مستوحى من كيفية إنشاء منتجات تقنية يحبها العملاء 4. ستيف كروج 2014 لا تجعلني أفكر في إعادة النظر في النهج السليم لسهولة الاستخدام على الويب 5. جيك كناب جون زيراتسكي وبرادن كويتز 2016 Sprint كيفية حل المشكلات الكبيرة واختبار الأفكار الجديدة في خمسة أيام فقط 6. آلان كوبر روبرت ريمان ديفيد كرونين كريستوفر نويسل 2014 عن الوجه أساسيات التصميم التفاعلي