يظهر حقل الموعد في ثلاث شاشات، لكن رسالة الخطأ تختلف في كل واحدة، ولا يعرف المطور أي شكل يعتمد. تسليم صور الشاشات لا يجيب دائمًا عن سؤال المكون المشترك: ما قواعده، وما حالاته، ومن يملك تحديثه عندما تتغير حاجة المنتج؟
إذا تضمن عرض تصميم UI/UX «نظام تصميم»، فاطلب وصف المخرج بدل قبول الاسم وحده. هل ستتسلم مكتبة في أداة التصميم، أم مكونات برمجية أيضًا، أم دليل استخدام؟ هذه أعمال مترابطة، لكنها ليست شيئًا واحدًا، وقد تكون مسؤوليتها موزعة على أكثر من فريق.
ابدأ بمكون يحتاجه المنتج فعلًا
في مثال افتراضي، تبني مؤسسة نظامًا لطلب تجهيز قاعات. يستخدم موظف الطلبات ومدير القاعة نموذجين يتكرران فيهما حقل الموعد وحقل الملاحظات. المطلوب ألا يعيد كل مطور استنتاج أسلوب المساعدة والخطأ والتعطيل من صورة منفصلة. لم نُنشئ هذا النظام أو نختبر مستخدميه؛ المثال لتحديد نطاق الشراء.
اختر حقلًا واحدًا واطلب تتبعه عبر التصميم والدليل والمثال المنفذ إذا كان التطوير مشمولًا. جرّب محتوى قصيرًا وآخر طويلًا وحالة فارغة وأخرى خاطئة. الهدف أن يعرف الفريق كيف يعيد استخدام القرار، لا أن تتضخم المكتبة بعناصر لا يستعملها أحد.
بطاقة المكون التي ترسلها للمصمم والمطور
- الغرض: ما المشكلة التي يعالجها المكون، ومتى تستخدمه أو تختار نمطًا آخر؟ اذكر مثالًا من المسار المطلوب.
- الحالات: الشكل العادي والتركيز والخطأ والتعطيل وما يرتبط بكل منها من رسالة وسلوك؛ لا تعتمد اللون وحده لشرح المعنى.
- المحتوى: حدود التسميات والمساعدة والنص الطويل، وما يتغير مع العربية والإنجليزية، مع أمثلة تناسب بيانات المنتج.
- قيم التصميم: أسماء الألوان والمسافات والخطوط المستخدمة وصلتها بقيم التنفيذ، بدل قيم متفرقة يصعب تحديثها بصورة متسقة.
- مراجع التسليم: رابط المكون القابل للتحرير ونسخته ودليل استخدامه، ومثال الكود وواجهته إذا شمله الاتفاق، مع بيان ما يزال تصميمًا فقط.
- الملكية: من يعتمد التغيير ومن يحدّث التصميم والكود والتوثيق، وكيف يعرف المستعملون أن نسخة جديدة تحتاج مراجعة؟
البطاقة مقترحة للمثال، ولا تفرض أداة أو إطار واجهة معينًا. يمكن أن يكون النطاق صغيرًا: مكونات النموذج المتكررة في المسار الأول مثلًا. المهم أن يبين العرض العدد والنوع والحالات المشمولة، وما يحتاج طلب تطوير مستقلًا، دون تحويل كل اختلاف محتوى إلى مكون جديد.
لماذا يهم اسم القيمة المشتركة؟
تشرح وثائق USWDS التوكنات بوصفها خيارات محددة للألوان والمسافات والخطوط تسهل التواصل بين التصميم والتنفيذ. على مستوى الشراء، اطلب خريطة مفهومة للأسماء والقيم وكيف تُستخدم. لا تحتاج نسخ أسماء ذلك النظام أو أدواته، ولا تعتبر وجود ملف توكنات دليل إتاحة.
في حقل الموعد الافتراضي، اسأل ماذا يحدث إذا عُدلت مسافة المساعدة أو لون الحد. هل يتغير كل استخدام مقصود، أم توجد نسخ مستقلة خفية؟ اطلب تجربة تعديل محدود في بيئة مناسبة، وبيان المواضع التي تتأثر والتي احتفظت باختلاف مقصود وموثق.
المكتبة تحتاج أدلة استخدام وحدودًا
تضع معايير مساهمة GOV.UK قابلية الاستخدام والاتساق وتنوع السياقات ضمن مراجعة مكوناتها. نستفيد من هذه الأسئلة دون نقل إجراءاتهم أو آجال دعمهم إلى عقد خاص. اسأل عما اختُبر فعلًا وعلى أي أجهزة وسياقات، وما يحتاج تحققًا بعد التنفيذ.
نجاح نموذج داخل أداة التصميم لا يثبت وحده سلوك لوحة المفاتيح أو قارئ الشاشة في المتصفح. وحالة إنجليزية قصيرة لا تغطي المحتوى العربي المختلط. ضع المسؤولية والمرحلة المناسبة لكل فحص، وسجل النتيجة وحدودها بدل ختم المكتبة كلها بأنها متاحة أو متوافقة تلقائيًا.
اتفق على حياة المكون بعد التسليم
ماذا يفعل المطور إذا احتاج حالة غير موجودة؟ اطلب قناة اقتراح ومراجعة توضح هل يوسع المكون أم ينشئ استثناءً. وحين يتغير المكون، احفظ سبب التغيير والنسخ المتأثرة وخطوة تحديث استخدامها؛ وإلا قد يتطابق ملفا التصميم والكود يوم التسليم فقط.
يفصل دليل مخرجات UI/UX النطاق العام، ويعرض قبول التصميم العربي اختبارات الاتجاه. عند طلب تصميم تجربة وواجهة من نكست ويف، أرفق بطاقة مكون متكرر حتى يتضح ما ستشتريه وكيف سيتابعه فريق التطوير.
مصادر الفكرة
فُتحت معايير مساهمة GOV.UK ووثائق توكنات USWDS في 4 نوفمبر 2026. البطاقة والمثال أصليان، بلا مكتبة أُنشئت أو دراسة استخدام أو شهادة إتاحة. أُعد المحتوى بمساعدة الذكاء الاصطناعي مع مراجعة المعلومات والترجمة.