كيفية تصميم أصغر شيء ممكن

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

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

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

لماذا نصمم أصغر شيء ممكن؟

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

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

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

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

سبب صعوبة تصميم الأشياء الصغيرة بطريقة صحيحة

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

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

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

وسائل تصميم الأشياء الصغيرة

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

ليست الأشياء الصغيرة سيئة

مثال عن ميزة عرض صغيرة ولكنها مهمة على موقع وهمي

يُسمَّى الإصدار الأول بالحد الأدنى من المنتج القابل للتطبيق Minimum Viable Product أو MVP اختصارًا في أغلب الأحيان، ولكن الأشخاص يفتقدون الجزء "القابل للتطبيق" المهم جدًا من هذا المصطلح. يمكن أن يكون الإصدار الأول لميزة أو منتج جديد صغيرًا، ولكن يجب أن يكون قابلًا للتطبيق، إذ لا ينبغي أن يحتوي على أخطاء أو لا يمكن استخدامه أو سيئًا بأي شكل آخر.

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

ليست الأشياء الصغيرة مزيجا غير مرتبط بالميزات

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

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

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

الأشياء الصغيرة مفيدة

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

كيفية تصميم الأشياء الصغيرة

هناك العديد من التقنيات لتصميم الأشياء الصغيرة التي لا تزال مفيدةً وقابلةً للاستخدام ويمكن تحسينها وتطويرها من خلال التكرار مثل التقنية التي سنوضّحها فيما يلي.

افهم الهدف

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

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

اختبر الأشياء الصغيرة

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

مثال عن لوحة تحكم إصدار التقارير الخاصة بموقع وهمي

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

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

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

إبدأ بدون شيفرة برمجية

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

حاوِل تصميم تجارب لتعلم أفضل طريقة لبناء شيء ما بدلًا من القفز مباشرةً إلى تصميم ميزات كاملة سيبنيها المهندسون مباشرةً. جرّب اختبار الكونسيرج Concierge Test أو تجربة الساحر أوز Wizard of Oz Experiment مثلًا لبناء بعض النماذج الأولية التفاعلية لاختبارها مع المستخدمين، إذ لا توجد قاعدة تنص على أن المصممين يمكنهم فقط تصميم واجهات مثالية، بل يمكنهم أن يكونوا مصممين تجارب أيضًا.

لا تطلق التصميم للجميع دفعة واحدة

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

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

تقبل بعض النقص

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

التزم بالتكرار

إذا تقبّلتَ النقص، فيُفضَّل أن يكون فريقك على استعداد للالتزام بالتكرار أيضًا، إذ تعمل فرق أجايل بجد لشحن الأشياء بسرعة، بعدها لا يعودون أبدًا لإعادة بناء أو تحسين الميزات، او يمكن ألّا يقيسوا نتائج الميزات.

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

الخلاصة

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

ترجمة وبتصرف للمقال Designing the Smallest Possible Thing لصاحبته Laura Klein.