كيف تبني موون ويلمنتجات تدوم.

تصل معظم المشاريع على شكل طلب واضح. موقع إلكتروني. تطبيق. منصة. هوية. نظام ذكاء اصطناعي.

لكن المخرج المطلوب غالبًا ليس المشكلة الحقيقية.

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

لهذا نصعد دائمًا خطوة فوق الطلب نفسه.

ما الذي يجب أن يغيره هذا المنتج؟ من يجب أن يهتم به؟ ما الذي لا يعمل الآن؟ كيف يبدو النجاح بصورة قابلة للقياس؟ ما الذي يحاول المستخدم إنجازه؟ أين توجد نقاط الاحتكاك؟ وما الذي سيجعل المنتج مفيدًا بما يكفي ليعود المستخدم إليه؟

هذه الأسئلة تصنع التوافق. والتوافق يصنع السرعة.

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

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

كل منتج قوي بنيناه بدأ بسؤال تمت الإجابة عنه بوضوح كافٍ ليقود ما جاء بعده.

تنظر فرق كثيرة إلى الوضوح باعتباره مسألة تتعلق بإدارة المشروع. نحن نراه أداة تصميم.

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

كلما كانت الاستراتيجية أوضح، قل عدد القرارات العشوائية لاحقًا.

ولهذا نهتم أيضًا بتحديد ما الذي لن يكونه المنتج.

ما الذي لن نبنيه؟ من ليس المستخدم الأساسي؟ ما حالات الاستخدام التي يمكن تأجيلها؟ ما التقنية التي لا تنتمي إلى هذا المشروع؟ وأي ميزة تبدو مثيرة لكنها لا تدعم الهدف الأساسي؟

غالبًا ما تتشكل المنتجات القوية بما تستبعده بقدر ما تتشكل بما تضيفه.

يقسم النموذج التقليدي للوكالات العمل بين أقسام منفصلة. تنتهي الاستراتيجية. ثم يبدأ التصميم. ثم التطوير. ثم ضمان الجودة. ثم الإطلاق.

كل عملية تسليم تخلق مسافة. وكل مسافة تخلق فرصة لفقدان جزء من السياق.

الاستراتيجي يعرف لماذا اتُخذ القرار. المصمم يستلم النتيجة. المهندس يستلم التصميم. وفريق الإطلاق يستلم المنتج. وفي النهاية قد يطابق المنتج الملفات من الناحية التقنية لكنه يفقد الفكرة الأصلية.

نحن نعمل بطريقة مختلفة.

الاستراتيجية والتصميم والهندسة والذكاء الاصطناعي تدخل في الحوار نفسه منذ البداية.

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

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

أسرع فريق ليس دائمًا الفريق الذي يعمل ساعات أطول. بل الفريق الذي يفقد أقل قدر من السياق.

قبل التفكير في الشاشات الفردية، نفكر في المنطق الموجود تحتها.

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

المنتج الذي يُصمم شاشة بعد شاشة قد يبدو جيدًا في البداية. لكنه يصبح هشًا بمجرد أن يبدأ بالنمو.

أما النظام فيتصرف بطريقة مختلفة.

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

ولهذا لا تتعلق أنظمة التصميم بالاتساق فقط. بل بالاستمرارية.

حد البطاقة. إيقاع المسافات. طريقة فتح النافذة. وزن العنوان. بنية الحالة الفارغة. يجب أن تشعر هذه التفاصيل بأنها مترابطة لأنها نابعة من المنطق نفسه.

عندما يكون النظام قويًا، يبقى المنتج متماسكًا حتى أثناء التوسع.

العمل عبر أربيل ودبي والولايات المتحدة، ومع عملاء في أسواق مختلفة حول العالم، علمنا أن المنتجات الرقمية لا تنتقل تلقائيًا من سوق إلى آخر.

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

منتج يبدو طبيعيًا في سوق قد يبدو محيرًا في سوق آخر. لهذا نهتم بالقدرة على التكيف منذ البداية.

نفكر في:

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

الاستعداد للأسواق الدولية لا يعني بناء كل منتج لكل دولة منذ اليوم الأول. بل يعني تجنب القرارات التي تجعل التوسع المستقبلي أصعب بلا داعٍ.

المنتج الذي يدوم يجب أن يستطيع تجاوز الظروف الدقيقة التي وُلد فيها.

MoonWhale استوديو AI-native. لكننا لا نعتقد أن كل منتج يحتاج إلى الإعلان باستمرار أنه "يستخدم الذكاء الاصطناعي".

بالنسبة لنا، AI جزء من البنية.

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

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

لكن المبدأ يبقى نفسه: الذكاء الاصطناعي يزيل الاحتكاك، والناس يتخذون القرارات.

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

أي اتجاه هو الصحيح فعلًا؟ وأي نتيجة تبدو عامة؟ وأي سير عمل يجب أن يوجد؟ وأي أتمتة مفيدة؟ وأي ميزة AI تحسن المنتج فعلًا، وأيها موجودة فقط لأن الذكاء الاصطناعي رائج؟

نحن لا نستخدم AI للهروب من التفكير. بل لخلق مساحة أكبر له.

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

النماذج تتحسن. واجهات API تتغير. الأسعار تتغير. والقدرات تتطور بسرعة.

بنية المنتج المرتبطة بشكل ضيق جدًا بمزود واحد قد تصبح مكلفة في التطوير لاحقًا.

عندما يكون ذلك منطقيًا، نصمم أنظمة AI على طبقات واضحة.

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

هذا لا يعني أن كل نظام يحتاج إلى طبقات تجريد معقدة. بل يعني أن المنتج يجب أن يمتلك منطقه.

مزود الذكاء الاصطناعي جزء من النظام، وليس النظام كله. وهذا يجعل المنتج أسهل في الصيانة مع تطور التكنولوجيا.

يمكن لأي فريق أن يجعل المنتج يعمل في يوم العرض. الاختبار الحقيقي يبدأ بعد الإطلاق.

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

نحن نهندس لهذه اللحظات.

وهذا يعني:

• بنية نظيفة
• شيفرة مفهومة
• اعتماد الأنواع الصارمة في الشيفرة عندما يكون ذلك مناسبًا
• التحكم بالإصدارات
• نشرًا آليًا
• مراقبة
• تتبع الأخطاء
• اختبارات
• توثيق
• صلاحيات منطقية
• وبنية تحتية قابلة للصيانة

نختار التقنية لأنها تناسب المنتج، لا لأنها رائجة.

قد يكون إطار عمل جديد مثيرًا للاهتمام. لكن هذا لا يعني أنه ينتمي إلى المشروع.

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

لذلك نبقي حزمة التقنيات صغيرة قدر ما يسمح المنتج. التعقيد يجب أن يستحق وجوده.

هذا مبدأ مهم بالنسبة لنا.

العمل التقني الجيد يجب أن يخلق استقلالية، لا اعتمادًا.

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

بالطبع، يمكن للتعاون طويل الأمد أن يكون مفيدًا. لكن يجب أن يستمر لأن العلاقة تخلق قيمة، لا لأن العميل غير قادر على المغادرة.

ننظر إلى ذلك باعتباره مسألة احترام. المنتج ملك للشركة التي استثمرت فيه. ويجب أن يُبنى النظام على هذا الأساس.

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

لا ينبغي أن يكون التلميع شيئًا تتم إضافته في النهاية. بل يجب أن يكون المعيار المستخدم طوال عملية البناء.

هذا يعني المراجعة المستمرة. حلقات صغيرة. تصحيحات مبكرة. واختبار العمل بينما لا يزال تغييره سهلًا.

نهتم بتفاصيل قد لا يذكرها المستخدم أبدًا بشكل واعٍ:

• سلوك التحميل
• توقيت الحركة
• الحالات الفارغة
• رسائل الخطأ
• سلوك النماذج
• المسافات على الهاتف
• تجاوز المحتوى
• الانتقالات
• الحالات المعطلة
• تحميل الصور
• سهولة الوصول
• الاستجابة
• اتجاه اللغة

هذه التفاصيل غالبًا ما تحدد ما إذا كان المنتج يشعر المستخدم بأنه احترافي أو غير مكتمل.

معظم الناس لا يستطيعون شرح لماذا تبدو واجهة أفضل من أخرى. لكنهم يشعرون بذلك. الجودة تعيش في هذه المساحة.

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

العنوان أطول من المتوقع. العربية تحتاج مساحة مختلفة. المستخدم يرفع صورة سيئة. السعر يحتوي على أرقام أكثر. الوصف فارغ. والجدول يحتوي على مئة صف بدل عشرة.

لهذا نختبر بمحتوى واقعي في وقت مبكر.

المنتجات يجب أن تتحمل المدخلات غير المثالية. التصميم لا يجب أن يعمل فقط داخل الصورة المثالية. بل في الإنتاج.

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

الاستمرارية تبدأ من التصميم للواقع، لا لصورة معرض الأعمال.

المنتج الجميل بصريًا لكنه بطيء ليس منتجًا جميلًا.

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

لهذا الأداء جزء من التصميم والهندسة، وليس مشكلة تقنية يتم التعامل معها في النهاية.

معالجة الصور. وزن الحركة. السكريبتات الخارجية. سلوك واجهات API. التخزين المؤقت. حالات التحميل. الأصول المتجاوبة. كل هذه القرارات تؤثر في شعور المنتج.

النظام الذي يبدو فاخرًا لكنه يتصرف ببطء يخلق تناقضًا.

المنتجات التي تدوم يجب أن تعمل جيدًا في ظروف حقيقية، لا على اتصال سريع داخل المكتب فقط.

أخطر افتراض في تطوير المنتجات هو أن المنتج سيبقى كما تم التخطيط له. لن يحدث ذلك.

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

ولهذا لا نرى الاستمرارية على أنها جمود. بل العكس.

المنتج المتين مصمم لكي يتغير.

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

القدرة على التغيير جزء من الجودة.

لا يصبح المنتج حقيقيًا عندما يقول فريق التطوير إنه انتهى. يصبح حقيقيًا عندما يبدأ الناس باستخدامه.

غالبًا ما تعلم الأسابيع الأولى بعد الإطلاق أكثر مما تعلم الأشهر السابقة.

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

ولهذا تهم التحليلات والملاحظات والمراقبة. فهي تحول الإطلاق إلى معلومات.

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

المنتج الذي يدوم هو منتج قادر على التعلم.

العمل من أربيل ودبي والولايات المتحدة، ومع عملاء حول العالم، يخلق نوعًا مهمًا من الانضباط.

تتوقف عن افتراض أن مستخدمًا واحدًا يمثل الجميع.

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

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

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

ونرى هذا ميزة. العمل العالمي يجعل العملية أكثر مرونة. والمرونة تجعل المنتجات أقوى.

بالنسبة للعملاء، يجب أن تبدو هذه العملية كثلاثة أشياء: وضوح. سرعة. هدوء.

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

عملية جيدة لا يجب أن تبدو فوضوية لمجرد أنها تتحرك بسرعة. بل العكس. كلما كانت البنية أفضل، أصبح العمل السريع أكثر هدوءًا.

وعندما يطلق المنتج، يجب أن يبقى العمل متماسكًا. يجب أن ينمو النظام مع العمل بدل أن يتقادم ضده.

هذا هو معنى بناء منتجات تدوم بالنسبة لنا.

ليست منتجات جامدة. وليست منتجات مليئة بالتقنية لمجرد التقنية. وليست منتجات صُممت لكي تبدو جيدة فقط يوم الإطلاق.

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

هذا هو المعيار الذي نعمل نحوه في MoonWhale.

لأن الاستمرارية في المنتجات الرقمية لا تأتي من مقاومة التغيير.

بل من البناء بشكل جيد بما يكفي ليصبح التغيير سهلًا.