فيرست ستريت برجرز

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

المنافس الحقيقي ليس مطعماً آخر

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

هذا يرفع سقف المطلوب كثيراً. لا يكفي أن يكون التطبيق جيداً؛ يجب أن يكون الطلب منه أقلّ خطوات وأقلّ احتكاكاً من البديل المألوف. لذلك قِست كل قرار تصميمي بمعيار واحد: كم نقرة تفصل بين فتح التطبيق وتأكيد الطلب؟ وكل ما زاد هذا العدد دون مقابل واضح، حُذف.

المنيو المصوّر: الصورة هي البائع

في تطبيقات الطعام الصورة ليست توضيحاً بل هي المنتج. القائمة النصّية مهما كانت أوصافها بليغة لا تُنتج الرغبة التي تنتجها صورة واحدة جيدة لطبق.

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

تخصيص الطلب: أصعب شاشة في التطبيق

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

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

من الطبق إلى السلة دون فقدان السياق

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

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

الطلب المتكرر: أقوى ورقة يملكها التطبيق

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

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

التصميم لحالة استعجال

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

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

الحالات التي تحدث كثيراً

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

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

هوية المطعم داخل التطبيق

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

احتفظت باللون الأساسي للعلامة كلمسة تمييز في الأزرار والعناصر الفاعلة، وبنيت الأساس على قاعدة محايدة تدع صور الطعام تتصدّر. في تطبيق مطعم، أي لون ينافس صور الطعام على الانتباه يعمل ضد الهدف — الطعام هو البطل، وكل ما عداه خلفية له.

الهوية داخل شاشة صغيرة

نقل هوية مطعم إلى شاشة هاتف ليس نسخاً للألوان. الألوان القوية التي تعمل على لافتة أو عبوة تصبح مرهقة على شاشة تُحدَّق فيها من مسافة قريبة لدقائق.

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

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

حالة الطلب بعد التأكيد

ما يحدث بعد الضغط على «تأكيد الطلب» يُهمَل في معظم تطبيقات المطاعم، وهو أكثر لحظة يشعر فيها العميل بالقلق: هل وصل طلبي؟ ومتى سيجهز؟

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

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

اختبار المنيو بمحتوى حقيقي

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

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

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

أسئلة عن تطبيقات المطاعم

لماذا يحتاج مطعم تطبيقاً خاصاً؟

لسببين: العمولة التي تقتطعها تطبيقات الوساطة من كل طلب، وملكية العلاقة مع العميل. التطبيق الخاص يجعل بيانات الطلبات والعملاء مملوكة للمطعم لا للوسيط.

ما أهم عنصر في تطبيق مطعم؟

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

لماذا يُؤجَّل طلب التسجيل؟

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