المسافة بين ملف Figma مصقول والتطبيق الذي يثبّته المستخدم فعلًا هي المكان الذي تتحوّل فيه المنتجات الجيدة بهدوء إلى منتجات عادية. تنحرف المسافات ببضعة بكسلات، ويُحذف تأثير حركي "مؤقتًا"، ويُقدَّر وزن الخط تقديرًا. لا شيء من ذلك كارثي بمفرده، لكنه مجتمعًا هو الفارق بين تطبيق يبدو مصنوعًا بإتقان وآخر يبدو مجمّعًا.
التصميم والهندسة يتحدثان لغة واحدة
ينجح التسليم لدينا لأن المصمّمين والمهندسين يتفقون على لغة مشتركة قبل رسم أي شاشة. المرجع هو الرموز التصميمية (Tokens)، لا لقطات الشاشة. لا يكون اللون أبدًا #1F2E5B في التصميم ورقمًا عشوائيًا في الكود؛ بل يكون navy في الاثنين.
- سلّم المسافات. مجموعة ثابتة من درجات المسافات يرجع إليها الطرفان، فيصبح لعبارة "مسافة داخلية أكبر قليلًا" معنى دقيق.
- سلّم الخطوط. أنماط نصوص مسمّاة تقابل كلٌّ منها عنصرًا واحدًا في الكود.
- رموز الحركة. مُدد ومنحنيات تسارع تُعرَّف مرة واحدة ويُعاد استخدامها، كي تبدو الانتقالات متّسقة في أنحاء التطبيق.
إذا وُجدت قيمة في التصميم ولم توجد كرمز، فستنحرف في الكود. الرموز هي ما يحفظ النية عبر التسليم.
تطابق المكوّنات، شاشة بشاشة
نبني عنصر Flutter لكل مكوّن في نظام التصميم قبل تجميع الشاشات: الأزرار والحقول والبطاقات والشارات. فتصبح الشاشات تركيبات من أجزاء موثوقة بدلًا من قطع مصنوعة لمرة واحدة. وحين يتغيّر نظام التصميم، تتحدّث كل شاشة معه.
نضع التطبيق أثناء تشغيله فوق إطار Figma بنسبة 100% ونبحث عن أي اختلاف. إذا انحرف شيء ولو ببضعة بكسلات، فهو خلل يجب إصلاحه، لا خطأ تقريب نتجاوزه.
لا تتجاهل الحالات البينية
تميل التصاميم إلى إظهار المسار المثالي. أما التطبيقات الحقيقية فتعيش في الحالات البينية: التحميل، والفراغ، والخطأ، وانقطاع الاتصال، والاسم الطويل جدًا الذي يكسر التخطيط. نصمّم هذه الحالات ونبنيها عن قصد، لأنها المواضع التي يعيش فيها المستخدمون أكثر لحظاتهم إحباطًا.
الخلاصة
التسليم الأمين لا يقوم على بطولات في النهاية، بل على نظام مشترك منذ البداية. الرموز التصميمية وتطابق المكوّنات والاهتمام الصادق بالحالات الطرفية هي ما يجعل تطبيق Flutter مدروسًا تمامًا مثل ملف Figma الذي خرج منه.