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

السياق

كان على التطبيق الوصول إلى App Store وGoogle Play ضمن خط منتجات يُسلّم خلال مدة المشروع البالغة 16 أسبوعًا.

القرار

بنينا قاعدة Flutter مشتركة لـ iOS وAndroid، مع دعم كامل للعربية وRTL إلى جانب الإنجليزية.

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

السياق

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

القرار

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

يعمل الموظفون المسؤولون عن الفواتير والقيود بالعربية، لذلك سهّلت واجهة قريبة من منطق دفاترهم اليومية التبنّي والتدريب مقارنة بترجمة تُضاف بعد اكتمال التصميم.

السياق

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

القرار

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

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

السياق

كان يمكن تعريف تطبيق العميل وتطبيق الفني ولوحة التحكم والموقع كأربعة مشاريع، لكل منها جزؤه من الـ Backend. وعندها تُكتب قواعد التسعير والحالات والصلاحيات أربع مرات.

القرار

بنينا Laravel API واحدًا فوق مخطط MySQL واحد كمصدر للحقيقة، وجعلنا كل سطح عميلًا له — بما في ذلك الموقع، الذي يقرأ الخدمات والأسعار الحية من نفس المسارات التي يستهلكها التطبيق.

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

السياق

كان من الممكن إضافة العربية بعد اكتمال الموقع الإنجليزي، وهو ما يؤدي غالبًا إلى تخطيطات RTL غير متوازنة وخطوط لا تخدم القراءة العربية جيدًا.

القرار

صممنا تجربتي اللغتين معًا منذ اليوم الأول: تخطيطات معكوسة RTL، وتوجيهًا مدركًا للغة عبر next-intl، وخطوط Cairo للعربية إلى جانب Poppins للإنجليزية.

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

السياق

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

القرار

بنيت الموقع بالعربية فقط من المستند نفسه — تُقدَّم الصفحة بـ `lang=ar` و`dir=rtl`، وكل تخطيط واتجاه أيقونة ومسار نموذج مكتوب من اليمين إلى اليسار.

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

السياق

يستعد المرشحون في مراحل مختلفة وباحتياجات متفاوتة، لذلك لم يكن عرض ثابت واحد مناسبًا للمبتدئ ومرشح الجولة النهائية معًا.

القرار

حوّلنا رحلة المرشح إلى أربعة مسارات — Fundamentals وIntermediate وAdvanced وFitment السلوكي — بتسعير لكل جلسة.

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

السياق

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

القرار

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

هذا الترتيب يقلّل الغموض حول عرض مركّب ويمنح الزائر سياقًا كافيًا قبل اتخاذ الخطوة التالية.

السياق

تقدم الشركة خدمات استراتيجية وتقنية وتشغيلية وتعليمية، وتحت كل منها عروض متخصصة متعددة.

القرار

جمعنا الخدمات تحت Consulting وTechnology وOutsourcing وInstitute، مع وصول مباشر للخدمات الفرعية.

يجعل التقسيم العرض الكبير سهل الفهم ويحافظ على مسار قصير لمن يعرف احتياجه مسبقًا.