أفضل ممارسات تصميم النماذج: 10 قواعد للويب والجوال
10 قواعد لتصميم نماذج تُحوِّل الزوار. تحليل حقيقي لنماذج تسجيل Notion وTally وMercury، بالإضافة إلى أنماط تصميم الجوال أولاً التي تعمل فعلاً.
أفضل ممارسات تصميم النماذج: 10 قواعد للويب والجوال
تكلفة النموذج السيئ
النموذج السيئ ضريبة استراتيجية على كل دولار أنفقته لإيصال شخص ما إلى الصفحة. تبلغ معدلات إتمام نماذج التسجيل والدفع والتأهيل نحو 12% عندما يكون الاحتكاك موجوداً. أزِل الاحتكاك وسيرتفع هذا الرقم إلى ما يتجاوز 50%.
الفجوة ليست في النصوص أو الهوية البصرية تقريباً. إنها في العشر قواعد، مطبَّقة باتساق.
نماذج جذب العملاء بأسلوب Salesforce ذات الـ30 حقلاً موجودة لأن شخصاً ما رسم مخطط قاعدة البيانات على صفحة وسماها نموذجاً. المستخدم لم يشترك لهذا. وصل من أجل المنتج، ومنطق التأهيل هذا أضاع منك العميل المحتمل.
القاعدة 1: عمود واحد، مهمة واحدة في كل شاشة
عمود واحد دائماً. التخطيطات متعددة الأعمدة تبدو فعّالة في شبكة Figma وتقتل معدلات الإتمام على الشاشة.
العين تقرأ من اليسار إلى اليمين وتتوقع الاستمرارية. عندما تنقسم الحقول إلى عمودين، يضطر المستخدم إلى تحديد أي مسار يتبع، وهذا القرار الدقيق يضيف احتكاكاً قبل أن يكتب حرفاً واحداً.
تدفق تسجيل Notion عمود واحد في المنتصف مع حقل واحد بارز في كل مرة على الجوال. النموذج يبدو سريعاً لأنه يطلب شيئاً واحداً. هذه هي القاعدة.
القاعدة 2: موضع التسمية أهم من أسلوبها
التسميات تعلو الحقل. ليست داخله، ليست بجانبه. فوقه، مرئية دائماً.
نص العنصر النائب المستخدم كتسمية يختفي لحظة بدء المستخدم في الكتابة. عندها يتعين عليه مسح الحقل لتذكر ما يملؤه. يستخدم تدفق تأهيل Mercury تسميات ثابتة فوق الحقل على كل مدخل حتى لا يضيع السياق في منتصف التعبئة.
التسميات العائمة، التي تتحرك للأعلى من موضع العنصر النائب عند التركيز، وسط مقبول، لكنها تتطلب تبايناً محكماً وتوقيتاً دقيقاً لتكون في متناول الجميع. في حالة الشك، ضع التسمية فوق الحقل واتركها هناك.
يُغطَّى بحث UX وراء موضع التسمية بعمق في دليلنا لأساليب أبحاث UX.
القاعدة 3: ترتيب الحقول يتبع واقع المستخدم، لا مخطط قاعدة البيانات
تسلسل حقولك يجب أن يتطابق مع كيفية تفكير الشخص في المهمة، لا مع كيفية هيكلة المهندسين لنموذج البيانات.
نموذج الدفع الذي يطلب عنوان الشحن قبل تأكيد السلة يُحمِّل المستخدم عبء السياق. Stripe Checkout، المرجع الأساسي لتجربة مستخدم نماذج الدفع المستضافة، يُرتِّب النموذج في ثلاث خطوات:
- البريد الإلكتروني (من أنت)
- الدفع (كيف ستدفع)
- العنوان (أين يذهب)
هذا هو التسلسل الذي سيستخدمه إنسان معقول شخصياً. عندما تقود قاعدة البيانات ترتيب الحقول، تحصل على نماذج تطلب الرمز البريدي قبل البلد، أو المسمى الوظيفي قبل اسم الشركة.
القاعدة 4: التحقق فورياً، لا عند الإرسال
تحقق من الحقل لحظة مغادرة المستخدم له، لا عند الضغط على إرسال.
التحقق عند الإرسال يعني أن المستخدم يملأ نموذجاً من عشرة حقول، يضغط الزر، ويحصل على جدار من الأخطاء الحمراء. كل خطأ مهمة تصحيح، وكل مهمة تصحيح تخاطر بفقدانه كلياً. التحقق الفوري، المُشغَّل عند مغادرة الحقل، يكشف الخطأ قبل انتقال المستخدم إلى التالي.
تسجيل دخول Apple ID يتحقق من صيغة البريد الإلكتروني عند مغادرة الحقل ويؤكد توفر الحساب قبل أن يصبح زر الإرسال نشطاً أصلاً. هذا التسلسل يمنع فئتين من الأخطاء دفعة واحدة. أنماط التفاعل وراء هذا مُغطاة في دليل تصميم microinteraction.
القاعدة 5: الجوال أولاً يعني لوحات مفاتيح الجوال
كل نوع حقل يجب أن يستدعي لوحة المفاتيح الصحيحة. هذا 80% من تصميم نماذج الجوال.
إذا طلب حقل رقم هاتف ولوحة مفاتيح النص الافتراضية ظهرت، فالنموذج معطوب قبل أن يكتب المستخدم شيئاً. استخدم inputmode="numeric" على الحقول الرقمية، وtype="email" لإظهار مفتاح @، وinputmode="decimal" للأسعار. iOS وAndroid يدعمان النطاق الكامل من أوضاع الإدخال.
لوحة المفاتيح هي جهاز الإدخال الأساسي على الجوال. تحديد الخاطئة يحوِّل نموذجاً مصمماً بشكل صحيح بصرياً إلى نموذج محبط.
| نوع الحقل | سمة HTML الصحيحة |
|---|---|
| البريد الإلكتروني | type="email" |
| الهاتف | type="tel" |
| رقم صحيح | inputmode="numeric" |
| عشري / سعر | inputmode="decimal" |
| رابط URL | type="url" |
| بحث | inputmode="search" |
للأساس الأوسع لتصميم الجوال أولاً الذي تستند إليه هذه الأنماط، انظر أساسيات تصميم الويب المتجاوب.
القاعدة 6: التقدم والنص الصغير ومشكلة النماذج الطويلة
إذا كان النموذج يتطلب أكثر من خمسة حقول، أرِ المستخدم أين هو في التدفق.
يُظهر تدفق حجز Airbnb متعدد الخطوات مؤشر تقدم بخطوات مسماة طوال الوقت. المستخدمون الذين يرون أنهم أتموا 60% أكثر قابلية للإنهاء قياساً من المستخدمين الذين لا يملكون نقطة مرجعية.
يتبنى Tally نهجاً مختلفاً لنماذجه القابلة للتضمين: سؤال واحد في كل مرة مع شريط تقدم ثابت في الأعلى، والذي يتفوق باستمرار على النماذج الطويلة أحادية الصفحة في اختبارات المستخدم الموثقة لديهم.
النص الصغير يؤدي العمل ذاته. "الخطوة 2 من 4" أكثر صدقاً من شريط تقدم مجرد. "نحتاج هذا للتحقق من هويتك" أكثر فائدة من حقل حساس بلا تسمية.
القاعدة 7: رسائل الخطأ تعليمات، ليست اتهامات
اكتب رسائل الخطأ بصيغة الأمر، لا الاتهام.
"هذا الحقل مطلوب" اتهام. "أدخل بريدك الإلكتروني للمتابعة" تعليمة. المستخدم يعرف بالفعل أن شيئاً ما أخطأ. ما يحتاجه هو الحل.
أفضل نصوص الأخطاء تُسمي الحالة بالضبط والإجراء بالضبط: "يجب أن تكون كلمة المرور 8 أحرف على الأقل وتحتوي على رقم واحد." يفعل Stripe Checkout هذا بدقة. تظهر الرسالة عند مغادرة الحقل، تُسمي المشكلة، وتختفي لحظة حل الحالة.
لا توجد حالة حمراء مستمرة. يعمل فقط.
القاعدة 8: الملء التلقائي ميزة، لا لمسة أخيرة
سمة autocomplete تُخبر المتصفح بالضبط بما يملؤه. استخدمها على كل حقل.
نموذج دفع بسمات ملء تلقائي صحيحة يستغرق حوالي 12 ثانية للإتمام على هاتف ببيانات محفوظة. بدونها، يستغرق النموذج نفسه دقيقتين لأن المستخدم يكتب كل شيء يدوياً. فجوة الـ108 ثانية هذه هي المكان الذي يعيش فيه معظم التخلي عن دفع الجوال، ولا تكلف شيئاً لإغلاقها. يُغطي دليل مكتبة مكونات UI كيفية دمج هذه السمات في مكونات النماذج لنظام التصميم الخاص بك حتى لا تغيب أبداً.
| الحقل | قيمة autocomplete |
|---|---|
| البريد الإلكتروني | email |
| الاسم الأول | given-name |
| اسم العائلة | family-name |
| الهاتف | tel |
| عنوان الشارع | street-address |
| المدينة | address-level2 |
| الرمز البريدي | postal-code |
| رقم البطاقة | cc-number |
| انتهاء البطاقة | cc-exp |
القاعدة 9: زر الإرسال يحسم كل شيء
زر الإرسال هو العقد. تسميته وحالته وموضعه تُشير إلى ما إذا كان بإمكان المستخدم الثقة بما سيحدث بعد ذلك.
زر رمادي بلا تفسير يُخبر المستخدم أن النموذج معطوب لكن ليس لماذا. هذا طريق مسدود. زر مُسمى "إرسال" لا يخبر المستخدم بشيء عما يوافق عليه.
"إنشاء حسابي" و"احصل على نسختي المجانية" و"ابدأ البناء" أكثر صدقاً جميعها. عطّل الزر فقط عندما تستطيع شرح السبب في الواجهة. يستخدم Tally نصاً خاصاً بالإجراء على كل زر في كل خطوة من منشئ نماذجه، وهو مساهم مباشر في معدلات إتمامه الأعلى من المتوسط لتدفقات B2B المضمنة.
القاعدة 10: اختبر بأصابع حقيقية، بيانات حقيقية، تأخير حقيقي
اختبار النموذج على متصفح سطح مكتب عبر واي-فاي سريع لا يُخبرك بشيء مفيد عما إذا كان يعمل.
اختبر على جهاز Android متوسط المدى على اتصال 4G ببيانات بطول حقيقي في كل حقل:
- اسم يحتوي على حرف مميز
- عنوان برقم شقة في السطر الثاني
- بريد إلكتروني من 22 حرفاً
- اسم أول من حرف واحد
الحالات الحدية في العالم الحقيقي تكسر نماذج تبدو نظيفة في Figma. التأخير الحقيقي يكشف ما إذا كانت استدعاءات التحقق تحجب الإدخال أو تعمل بشكل غير متزامن. هذا الفرق غير مرئي في محاكي المتصفح وكارثي على هاتف بشريطين من الإشارة.
هل تحتاج مراجعة نموذج لتدفق التسجيل أو الدفع أو التأهيل؟ Brainy تُجري المراجعة الكاملة بالعشر قواعد على شاشات حقيقية، بيانات حقيقية، وأرقام تحويل حقيقية.
أين لا يزال المصممون يُصدِرون أسوأ النماذج
أسوأ النماذج في الإنتاج اليوم تشترك في ثلاثة أنماط:
- نماذج جذب عملاء المبيعات المؤسسية: شاشات تأهيل بأسلوب Salesforce ذات الـ30 حقلاً مع محددات "الإيرادات السنوية" الإلزامية وبدون تحقق فوري
- تدفقات التأهيل متعددة الخطوات التي لا تحفظ التقدم: مكالمة هاتفية في الخطوة 7 من 9 ترسل المستخدم إلى الخطوة 1
- تدفقات الدفع المبنية قبل أن يكون الجوال أساسياً، ولم تُعاد كتابتها أبداً: كل حقل رقمي لا يزال يستخدم
type="text"لأنه "يعمل بشكل جيد على سطح المكتب"
خيارات حالة الأخطاء في الحالات الثلاث تميل أيضاً إلى إخفاق متطلبات التباين؛ أنماط تباين الألوان في متناول الجميع تُصلح نقطة الإخفاق هذه تحديداً.
القاسم المشترك بين الثلاثة: النموذج صُمم للنظام، لا للشخص الذي يملؤه. الحل واحد.
طبِّق العشر قواعد. ابدأ بالجوال. دع قاعدة البيانات تُرتب مخططها بنفسها.
الأسئلة الشائعة
كم عدد الحقول التي يجب أن يحتوي عليها النموذج؟
أقل ما تتطلبه النتيجة. العدد الصحيح هو الذي يؤدي حذف حقل واحد منه إلى كسر المنتج. كل حقل تضيفه يقلل من معدل الإتمام. ابدأ من الصفر وأضف فقط ما هو إلزامي.
هل أستخدم نماذج متعددة الخطوات أم أحادية الصفحة؟
لأكثر من خمسة حقول، متعدد الخطوات يتفوق تقريباً دائماً على أحادي الصفحة. الشرط هو التقدم المرئي. بدونه، النماذج متعددة الخطوات تؤدي أداءً أسوأ من أحادية الصفحة لأن المستخدم لا يعرف طول الرحلة. سمِّ الخطوات وأرِه موقعه في التسلسل.
ما أفضل طريقة لتمييز الحقول المطلوبة؟
ميِّز الحقول الاختيارية، لا المطلوبة. إذا كانت معظم الحقول مطلوبة (كما ينبغي، بالنظر إلى القاعدة أعلاه)، فتمييز كل حقل بنجمة حمراء ضجيج بصري.
ميِّز الاستثناءات. "اختياري" بجانب حقل معلومة ذات مغزى. نجمة بجانب كل حقل ليست كذلك.
كيف أتعامل مع متطلبات كلمة المرور دون معاقبة المستخدم؟
اعرض المتطلبات قبل أن يبدأ المستخدم في الكتابة، لا بعد فشله. قائمة تحقق صغيرة تتفعَّل مع تحقق كل شرط تؤدي أداءً أفضل من جدار الأخطاء عند الإرسال. Apple ID ومعظم تدفقات المصادقة الحالية تستخدم هذا النمط. التغذية الراجعة فورية وإيجابية ولا تعاقبية قط.
هل عرض الحقل يُوصل شيئاً؟
نعم، والمستخدمون يقرؤونه. عرض الحقل يُشير إلى طول الإدخال المتوقع. حقل قصير يُشير إلى إجابة قصيرة. حقل بعرض كامل يُشير إلى إجابة أطول.
طابق عرض الحقل مع طول الإدخال المتوقع حيث يسمح التخطيط. حقل الرمز البريدي بعرض كامل يبدو كخطأ. منطقة نص لعنوان الشارع تبدو مبالغاً فيها. طابق الحاوية مع المحتوى المتوقع.
ما الذي يسبب أكثر التخلي عن نماذج الجوال؟
نوع لوحة المفاتيح الخاطئ هو الأول. الملء التلقائي غير العامل هو الثاني. كلاهما إخفاقات صامتة: النموذج يبدو صحيحاً، المستخدم لا يستطيع إتمامه بكفاءة فقط.
أصلح كليهما بسمتين لكل حقل. الاستثمار 15 دقيقة. العائد قابل للقياس في تحويل الدفع خلال نفس الدورة.
Need a form audit on your sign-up, checkout, or onboarding flow? Brainy runs the full ten-rule audit on real screens, real data, and real conversion numbers.
Get Started
