حدد القرارات، وليس مجرد معرض أنماط
نظام التصميم أكثر من لقطات شاشة. يسجّل القرارات المتكررة: المسافة بين الأقسام، معالجة الإجراء الأساسي، كيف يعمل خطأ النموذج، واللغة المستخدمة بعد النجاح أو الفشل. يصف USWDS توكنات التصميم (design tokens) كلوحات منفصلة لقيم مثل الطباعة، التباعد، اللون، ارتفاع السطر، والتعتيم. وثّق القاعدة، والغرض، والمتغيرات المعتمدة، والمالك. ابدأ بالأساسيات وخمسة إلى ثمانية مكونات تُستخدم أكثر في الرحلات المهمة؛ محاولة توحيد كل الصفحات دفعة واحدة عادة ما تخلق ضجيجًا بدلًا من وضوح.
سجّل أدوار الألوان المعتمدة، الخطوط، التباعد، الحدود، نصف القطر، نقاط التوقف (breakpoints)، وخيارات الحركة التي يستخدمها موقعك فعليًا.
استخدم نمطًا لترتيب مهمة قابلة للتكرار، مثل إنشاء حساب أو نتائج البحث، بدلًا من استخدامه لتفصيل بصري لمرة واحدة.
استخدم التوكنات للتحكم في القيم المتكررة
التوكن التصميمي هو اسم قابل للقراءة البشرية مرتبط بقيمة. يصف Design Tokens Community Group التوكنات كطريقة مستقلة عن المنصة للتعبير عن قرارات التصميم؛ على الأقل، التوكن هو اسم وقيمة. استخدم أسماء غرضية مثل color-action-primary أو space-section بدلًا من نشر القيم الخام في القوالب. احتفظ بخريطة موثقة من توكنات الغرض إلى القيم الأساسية. التوكنات تجعل التغييرات المنسقة أسهل، لكنها لا تضمن التباين أو العلامة التجارية أو تسلسل هرمي جيد. تحقق من كل تركيبة مرئية وحالة صفحة.
انشئ توكنات للاختيارات المتكررة، لا لكل استثناء؛ وإلا فإن قائمة التوكنات ستحتفظ بعدم الاتساق.
بالنسبة لتوكن يستخدم على نطاق واسع، ادرج الصفحات المتأثرة، اختبر الشاشات التمثيلية، وقدّم إرشادات للهجرة أو التراجع عند الحاجة.
أنشئ مكوّنات ذات سلوك وحدود
المكوّن هو جزء واجهة قابل لإعادة الاستخدام وله سلوك، وليس مجرد شكل بصري. وثّق البنية الدلالية، المدخلات المطلوبة والاختيارية، المتغيرات، السلوك التكيّفي، وكل الحالات ذات الصلة: جارٍ التحميل، معطّل، خطأ، فارغ، ونجاح. ضمّن سلوك لوحة المفاتيح وإرشادات المحتوى. لا تجبر كل تخطيط داخل مكوّن. تقيم GOV.UK المكونات المشتركة من حيث الفائدة، التفرد، سهولة الاستخدام، الاتساق، والقدرة على التكيّف؛ هذا انضباط مفيد لتقرير ما يستحق صيانة مشتركة. المكوّن واسع الاستخدام يمكن أن ينشر خللاً على نطاق واسع، لذا اختبره في الصفحات التي يستخدمه الناس فيها.
اَلِحْ على سرد كل حالة مرئية للمستخدم وأظهر تسميات حقيقية، نص طويل، ورسائل خطأ حتى تكون حدود التنفيذ واضحة.
علّم المتغيرات القديمة بوضوح، سمّ البديل، وأزلها فقط بعد مراجعة الرحلات المتأثرة.
اجعل إمكانية الوصول شرطًا للإصدار
يجب إدراج إمكانية الوصول في النظام لأن الخيارات المتكررة قد تكرر الحواجز. تتطلب WCAG 2.2، على مستوى A، تشغيلية لوحة المفاتيح للوظائف باستثناء الحالات التي يكون فيها مسار الحركة جوهريًا، وتطلب ترتيب تركيز ذي معنى عندما تكون التسلسل مهمة. اجعل الضوابط الدلالية، التركيز المرئي، التسميات، حركة التركيز المنطقية، تعريف الأخطاء، وإتمام المهام بدون مؤشر جزءًا من إرشادات المكوّن. استخدم الفحوص الآلية مبكرًا، ثم الفحص اليدوي بلوحة المفاتيح، والتكبير، والاستجابة للشاشات، واختبار الصفحة. تحذر USWDS من أن المكوّنات القابلة للوصول لا تضمن خدمة قابلة للوصول؛ الشيفرة المخصصة، النص، التكاملات، والسياق لا تزال تحتاج مراجعة.
تأكد من أن الأشخاص يمكنهم الوصول إلى الضوابط، تشغيلها، فهمها، ومغادرتها دون فأرة أو دون الوقوع في فخ لوحة المفاتيح.
تختلف الواجبات القانونية حسب الاختصاص والعقد. اطلب مراجعة إمكانية الوصول والمراجعة القانونية المؤهلة عندما تكون الامتثال ذات أهمية مادية.
عامل معايير المحتوى كمعايير للواجهة
الكلمات هي مدخلات للمكوّن، وليست زخرفة تضاف بعد التصميم. ضع قواعد لتسميات الأفعال، تسميات النماذج، الأخطاء، العناوين، الروابط، المصطلحات، التواريخ، الأرقام، والاختصارات. تفضل إرشادات GOV.UK الصوت النشط ومخاطبة المستخدم بصيغة أنت حيثما أمكن؛ استخدم مبدأ اللغة الواضحة والمتسقة، مع تكييف الأسلوب لجمهورك. زوج القواعد مع نموذج محتوى: حدد الحقول المطلوبة، إرشادات طول معقولة، وماذا يحدث عندما تغيب المعلومات. ضع الإرشادات في وثائق المكوّن وتدفقات عمل نظام إدارة المحتوى حتى يمكن للمحررين استخدامها.
اشرح ما فشل، أين حدث، والإجراء التالي عندما يكون آمنًا ومفيدًا القيام به.
الحد هو إشارة لإعادة التصميم أو إعادة الصياغة، وليس إذنًا لإزالة المعنى الجوهرِي.
نظم النظام قبل أن ينمو أسرع من الثقة
الحوكمة هي العملية الخفيفة للملكية، الطلبات، المراجعة، الإصدارات، والتقاعد. سمّ مالكًا مسؤولًا ومجموعة مراجعة يمكنها جمع خبرات التصميم، الهندسة، المحتوى، وإمكانية الوصول. طابق الأدلة مع نطاق التأثير. قد يحتاج نمط محلي إلى بيان مشكلة واختبار صفحة. يجب أن تتضمن تغييرات زر مشترك أو توكن قائمة بالرحلات المتأثرة، فحوصات إمكانية الوصول، مقارنة بصرية، ملاحظات الهجرة، وتعليمات التراجع. تطلب GOV.UK من المساهمين إظهار أن المكوّن مفيد لفرق عدة، وليس مكررًا، ومختبرًا مع مستخدمين تمثيليين؛ استخدم ذلك كنموذج عملي بدلًا من قاعدة كلية.
احفظ المشكلة، الخيارات، القرار، المالك، النسخة المتأثرة، وتاريخ المراجعة في مكان يمكن للفرق البحث فيه.
وسم التغييرات كتصحيح (patch)، إضافة، أو كسر (breaking) حتى يعرف المستهلكون متى تكون هناك حاجة للهجرة وفترة توافق.
منع الانتكاسات قبل الإصدار
صل النظام بالتسليم. اجعل أي تغيير يحدد التوكنات والمكوّنات المتأثرة، ثم اختبر الحالات المتأثرة والصفحات التمثيلية. تقارن الفحص البصري، اختبارات التفاعل، مراجعة المحتوى، وفحوصات إمكانية الوصول لعثور على عيوب مختلفة. أعطِ أولوية للرحلات عالية العواقب بالإضافة إلى الرحلات ذات الحركة العالية؛ قد تكون الوصول إلى الحساب ونماذج الاتصال مهمة حتى عندما يكون الحجم المروري متواضعًا. يدعم هذا عمل Status Is UP للتهيئة الوقائية والتحسين والإصلاح بتقليص نطاق العيب وجعل الإصلاح المعتمد أسهل في التحقق. ليس ذلك مراقبة التوقف عن العمل أو بديلاً لخطة الحوادث.
احتفظ بإصدار المكوّن، نتائج الاختبار، النتائج، الموافقات، وأي مخاطر مقبولة مع سجل الإصدار.
احتفظ بالإصدار المستقر السابق واختبر خطوات الاستعادة والتحقق المكتوبة أثناء صيانة منخفضة المخاطر.