حللت المشكلة الخطأ

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

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

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

الإطار يشكّل الإجابة

في عام 1983، كتب Donald Schön شيئًا كان ينبغي أن يغيّر طريقة تعليم التصميم، لكنه في الغالب لم يفعل. ميّز بين حل المشكلة وما سمّاه صياغة المشكلة. وصياغة المشكلة هي أن تقرر أي الأشياء ستعدّها إشكالية من الأساس: أن تسمّي الموقف، وتضع له إطارًا، وتقرر أي الوقائع ذات صلة.

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

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

بعض المشكلات تتغير وأنت تعمل عليها

سمّى Horst Rittel وMelvin Webber في عام 1973 فئة من المشكلات يتعامل معها معظم المصممين يوميًا من دون أن يكون لديهم اسم لها. على خلاف المشكلات القابلة للضبط، التي لها نهايات واضحة وحلول صحيحة، تتبدل هذه المشكلات حين تلمسها. فحل جانب منها يغيّر شروط الجوانب الأخرى كلها.

المشكلات الاجتماعية لا تُحل أبدًا. في أحسن الأحوال، يُعاد حلّها فحسب، مرة بعد أخرى.

— Rittel & Webber، ترجمة عن الإنجليزية

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

لم تكن فكرة Rittel وWebber أن هذه المشكلات ميؤوس منها. بل إنها تعاقب كل من يبحث عن إجابة واحدة مرتبة. فالمنظومة تواصل التحرك تحت قدميك.

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

حلّ Segway الشيء الخطأ

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

عمل الجهاز كما صُمّم. نقل الناس، وحافظ على توازنه، ولم يحتج تقريبًا إلى تدريب. توقع Kamen أن يُعاد تصميم المدن حوله. لم يُبَع سوى 140 ألف وحدة طوال عمر المنتج. وانتهى الإنتاج في عام 2020.

صاغ الفريق المشكلة بوصفها مشكلة جهاز: ابنِ طريقة أفضل للتنقل بين المباني. لكن المشكلة الحقيقية كانت أكبر من الجهاز.

كانت في المدن أرصفة لم تُصمَّم للمركبات. وحظرت اللوائح أجهزة Segway في مسارات الدراجات والطرق في معظم الأماكن. ووضع سعره البالغ 5,000 دولار الجهاز بعيدًا عن متناول كثيرين ممن كان يمكن أن يستخدموه للتنقل العملي. وكان انسجامه الاجتماعي مهتزًا أيضًا.

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

ابقَ مع المشكلة وقتًا أطول

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

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

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

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

حتى التصميم القوي يفشل إذا وُجّه إلى المشكلة الخطأ.