في بعض الأحيان عندما تقوم بإجراء طلب من متجر إلكتروني قد يُطلَب منك كتابة العنوان مرتين: مرة للتوصيل، ومرة للفاتورة. وقد يَطلُب منك حساب تكلفة الشحن من جدول منفصل قبل إكمال الطلب. هذه الخطوات سهلة على فريق يعرف الخدمة، لكنها تترك للعميل عملًا كان يمكن للمتجر إنجازه عنه.
هنا تأتي فائدة قانون تِسْلَر (Tesler’s Law). فهو يدعونا إلى النظر في التفاصيل التي تتطلَّبها المُهِمّة، وتحديد ما يستطيع النظام معالجته بدل تحميله للمُستخدِم. ولتطبيق قانون تِسْلَر، نحتاج إلى فهم سبب كل خطوة، وليس الاكتفاء بحذف الحقول حتى تبدو الشاشة أبسط.
ما هو قانون تِسْلَر؟
قانون تِسْلَر، المعروف أيضًا باسم قانون الحفاظ على التعقيد، يَفترض أن في كل نظام قَدْرًا من التعقيد لا يمكن إزالته بالكامل. ويمكن للفريق أن يختار كيف يتعامل معه: هل يتركه للمُستخدِم، أم يجعل المُنتَج يتولّى جزءًا منه؟ يُنْسَب هذا المبدأ إلى لاري تِسْلَر، كما يَرِد في شرح القانون لدى Laws of UX.
في طلب التوصيل مثلًا، لا بد من معرفة المكان الذي ستصل إليه الشُّحنة. حذف سؤال العنوان لا يُلغي هذه الحاجة، لكنه قد يؤجِّلها إلى مكالمة من مُوظَّف التوصيل. أما إتاحة اختيار عنوان محفوظ، فتُبقي المعلومة المطلوبة وتُخفِّف الجهد اللازم لإدخالها.
نتعامل مع القانون هنا بوصفه مبدأً يساعدنا على مراجعة قرارات التصميم. فهو لا يُعطينا معادلة لحساب صعوبة الواجهة، ولا يعني أن كل خطوة موجودة ضرورية. قد يكون التعقيد ناتجًا عن إجراء قديم أو سؤال مُكرَّر يمكن الاستغناء عنه أصلًا.
ما الذي يمكن حذفه فعلًا؟
قبل أن تبحث عن طريقة لتنفيذ خطوة تلقائيًا، اسأل لماذا تحتاج إليها. إذا كان المتجر يَطلُب تاريخ الميلاد لإرسال كتاب، ولا توجد حاجة مرتبطة بالطلب لهذه المعلومة، فالأجدى مراجعة سبب جمعها. مَلْء الحَقْل تلقائيًا لا يُجيب عن هذا السؤال.
وبالمثل، قد تُجبِر الخدمة الشخص على إنشاء حساب قبل معرفة تكلفة التوصيل، رغم إمكان حسابها باستخدام المدينة. هنا يمكنك إعادة ترتيب الخطوات، أو إتاحة الشراء دون حساب إذا كانت الخدمة تسمح بذلك، بدل اعتبار تسجيل الدخول جزءًا لا يمكن تغييره.
لكن هناك معلومات مرتبطة بالنتيجة نفسها. يجب معرفة الكتاب المطلوب، وعدد النُّسَخ، وعنوان المُستلِم. التبسيط في هذه الحالة يكون بتسهيل اختيارها وإدخالها ومراجعتها. لذلك ميِّز بين ما يحتاجه الطلب فعلًا، وما اعتاد الفريق طلبه دون مراجعة.
قد تكتشف أيضًا أن الحَقْل موجود فقط لأن أحد الموظفين يَنسَخ منه البيانات إلى برنامج آخر. ناقِش معه استخدام المعلومة ومصدرها؛ ربما يستطيع النظام نَقْلها مباشرة، وربما تحتاجون إلى تغيير الإجراء نفسه. رَسْم نَمُوذج أقصر وحده لن يَحُلّ المشكلة.
مثال: شراء كتاب وإرساله هدية
لنفترض أنك تُصمِّم طلب شراء من متجر كُتُب. اختار العميل كتابًا، ويريد إرساله هدية إلى صديق في مدينة أخرى. هنا يحتاج العميل إلى معرفة السِّعر الكامل، وتحديد المُستلِم والعنوان، واختيار طريقة التوصيل المناسبة.
في نسخة أولى، يَعرِض المتجر جدولًا لشركات الشحن، ويَطلُب من العميل معرفة المنطقة التي ينتمي إليها العنوان، ثم اختيار التكلفة المناسبة. وقد يَطلُب منه العودة إلى صفحة الكتاب لمعرفة وَزْنه. بهذه الطريقة يُنفِّذ العميل حسابات تعتمد على معلومات يملكها المتجر أصلًا.
يمكن تصميم التجربة بحيث يُدخِل الشخص مدينة التوصيل، فيَستخدِم النظام وَزْن الطلب وقواعد الشحن لحساب الخيارات المتاحة. يَعرِض بعدها تكلفة كل خيار وموعد الوصول المُتوقَّع. يبقى على العميل أن يُقرِّر إن كانت السرعة تستحق الزيادة في السِّعر، وهو قرار يرتبط بحاجته.
لاحظ الفرق: النظام تولّى البحث في جدول الشحن والحساب، بينما بقي الاختيار للعميل. لم نَحذف معلومات التوصيل أو نفترض أن أرخص خيار يناسب الجميع. أعدنا توزيع العمل بحيث يُؤدِّي كل طرف ما يملك المعلومات اللازمة له.
وإذا كان للعميل عنوان محفوظ، فيمكن عَرْضه مع خيار واضح لإضافة عنوان آخر. لكن لأن الطلب هدية، لا ينبغي اعتماد عنوانه الشخصي بصمت. السؤال المناسب هنا هو «إلى أي عنوان تريد إرسال الطلب؟»، مع إظهار العنوان الذي سيُستخدَم قبل التأكيد.
متى تصبح الأَتْمَتة عبئًا؟
الأَتْمَتة تعني أن يُنفِّذ النظام إجراءً دون أن يضطر الشخص إلى تكراره يدويًا، مثل حساب التكلفة أو تعبئة بيانات معروفة. لكنها تحتاج إلى التعامل مع الحالات التي تكون فيها البيانات ناقصة أو غير صحيحة.
إذا لم يجد الشخص عنوانه ضمن نتائج البحث، يجب أن يستطيع كتابته بنفسه ليُكمِل الطلب. وهذا ما تُوصي به إرشادات العناوين في نظام تصميم GOV.UK. ورغم أنها مُخصَّصة للعناوين البريطانية، فإن الفكرة بسيطة: ساعد الشخص في العثور على عنوانه، لكن اسمح له بإدخاله يدويًا إذا لم يجده.
وفي متجر الكُتُب، اعْرِض العنوان المحفوظ بوضوح، واترك تعديله ممكنًا. وإذا غَيَّر العميل المدينة، أَعِد حساب الشحن وبيِّن السِّعر الجديد. لا تجعل سرعة إكمال الطلب تُخفِي تغييرًا في التكلفة أو موعد الوصول.
كذلك، لا تطلب من الشخص إصلاح أخطاء الأَتْمَتة من البداية. إذا عَدَّل رقم المبنى، فاحْتَفِظ ببقية بياناته. وإذا تَعذَّر حساب الشحن، وضِّح ما حدث وما الخيارات المتاحة، بدل رسالة عامة مثل «البيانات غير صحيحة» توحي بأن المشكلة في العنوان.
هل إخفاء الخيارات يكفي؟
قد تبدو الواجهة أبسط بعد وضع تفاصيل كثيرة داخل قائمة مُغلَقة، لكن العمل المطلوب قد يبقى كما هو. إذا كان العميل يحتاج إلى فتح ثلاثة أقسام لمعرفة السِّعر وموعد الوصول والعنوان، فالتفاصيل اختفت عن النظر فقط، ولم يصبح الطلب أوضح.
يمكن استخدام الكشف التدريجي لإظهار التفاصيل الأقل استخدامًا عند الحاجة، كما تشرح Nielsen Norman Group. في مثال الهدية، قد يناسب ذلك حَقْل رسالة إضافية للمُستلِم، بشرط أن يكون الوصول إليه واضحًا. أما تكلفة الشحن، فتحتاج إلى الظهور قبل تأكيد الشراء.
وتُشير إرشادات تصميم التطبيقات المُعقَّدة إلى إمكانية تخفيف ازدحام الواجهة مع الحفاظ على الوظائف التي يحتاجها الناس. وهذا مهم عندما يَستخدِم المُنتَج أشخاص تختلف خبرتهم؛ ما يبدو خيارًا زائدًا للمبتدئ قد يكون ضروريًا لمن يُنفِّذ المُهِمّة يوميًا.
لذلك، لا تجعل عدد الأزرار معيارك الوحيد. راجِع ما يتطلَّبه إكمال المُهِمّة، بما فيه التنقّل والبحث وتصحيح الأخطاء. زِرّ إضافي بعنوان واضح قد يختصر خطوات كثيرة داخل قوائم يصعب اكتشافها.
من سيتولّى العمل داخل الفريق؟
حين تجعل المتجر يَحسُب تكلفة الشحن، فأنت تحتاج إلى بيانات صحيحة وربطها بالطلب وتحديثها عند تَغيُّر الأسعار. هذه مسؤولية يجب مناقشتها مع فريق التطوير والتشغيل، حتى يَعرِض التصميم نتيجة يستطيع النظام تقديمها فعلًا.
وقد تكون البداية أصغر من أَتْمَتة العملية كاملة. يمكن مثلًا حساب الشحن تلقائيًا للمناطق التي تَتوفَّر عنها بيانات موثوقة، مع توضيح أن المناطق الأخرى تحتاج إلى مراجعة. المهم أن يعرف العميل ما الذي تأكَّد، وما الذي لا يزال تقديريًا.
وانتبه إلى ما يحدث بعد إرسال الطلب. إذا حذفت سؤالًا من الواجهة ثم أصبح مُوظَّف الدعم يتصل بكل عميل للحصول على إجابته، فقد نَقَلْت الجهد إلى شخص آخر دون تحسين الخدمة. قيِّم وقت الفريق وأخطاء التنفيذ، إلى جانب سهولة استخدام الشاشة.
هذا يربط القانون بعمل تصميم تجربة المُستخدِم عمومًا: فهم المُهِمّة والظروف المحيطة بها قبل اختيار الحل. فقد يبدأ التحسين بتعديل طريقة تبادل البيانات بين فريقين، ثم يَظهَر أثره في واجهة أبسط.
كيف تُطبِّق قانون تِسْلَر؟
اخْتَر مهمة مُحدَّدة في مُنتَجك، مثل شراء كتاب أو تعديل عنوان توصيل، ثم تتبَّعها من البداية إلى النتيجة. يمكنك مراجعتها بهذه الخطوات:
اكتُب ما يفعله الشخص. هل يُدخِل معلومة، أم يَحسُب تكلفة، أم يبحث عن تفسير، أم يَتَّخِذ قرارًا؟
راجِع سبب كل خطوة. احْذِف ما لا تحتاجه الخدمة، وميِّز ما يمكن معرفته من بيانات موجودة.
حَدِّد ما يستطيع النظام إنجازه. مثل استرجاع عنوان محفوظ أو حساب الخيارات المتاحة، مع التحقُّق من دِقّة النتيجة.
أَبقِ القرار الشخصي واضحًا. اختيار المُستلِم أو دفع تكلفة إضافية مقابل السرعة يحتاج إلى معرفة رغبة العميل.
صَمِّم طريقة للتعديل والفشل. حَدِّد ما يراه الشخص إذا لم يجد عنوانه، أو تَغيَّرت التكلفة، أو احتاج إلى تصحيح معلومة.
بعد ذلك، ناقِش الاقتراح مع من سيُنفِّذه ويُتابِع الطلبات. السؤال الذي تحتاج إلى إجابته هو: هل أزلنا عملًا غير ضروري، أم جعلنا جهة أَقدَر تتولّاه، أم نقلناه فقط إلى مرحلة يصعب ملاحظتها؟
كيف تعرف أن التجربة تحسَّنت؟
جرِّب نَمُوذجًا يسمح بطلب كتاب هدية إلى عنوان جديد، ثم اطلب من أشخاص من جمهورك إكمال المُهِمّة. راقِب هل يفهمون عنوان المُستلِم وطريقة التوصيل والتكلفة، وهل يستطيعون تعديلها دون فقدان ما أدخلوه.
واختبر حالة لا ينجح فيها الحل التلقائي، مثل عنوان غير موجود في الاقتراحات. قد تعمل التجربة جيدًا في المسار المعتاد، ثم تَتعطَّل تمامًا عند أول استثناء. معرفة طريقة التصحيح جزء من تقييم التبسيط.
عند مقارنة نسختين، راجِع صِحّة الطلبات والحاجة إلى المساعدة والعودة لتعديل البيانات، إلى جانب الوقت. إكمال الطلب بسرعة لا يكفي إذا وصلت الهدية إلى عنوان خاطئ. ويمكن لفريق الدعم مساعدتك في معرفة المشكلات التي تَظهَر بعد إغلاق الصفحة.
ابدأ بخطوة واحدة يُكرِّرها الناس في مُنتَجك، واسأل إن كانت ضرورية، ومن يملك المعلومات اللازمة لإنجازها. بهذه الطريقة يصبح قانون تِسْلَر أداةً لاتخاذ قرار واضح: ما الذي نُزيله، وما الذي يتولّاه النظام، وما الذي يبقى اختيارًا للمُستخدِم؟
المصادر
Laws of UX — Tesler’s Law: تعريف القانون ونسبته إلى لاري تِسْلَر.
GOV.UK Design System — Addresses: البحث عن العنوان، والإدخال اليدوي عند الحاجة.
Nielsen Norman Group — Progressive Disclosure: إتاحة التفاصيل تدريجيًا وحدود إخفائها.
Nielsen Norman Group — 8 Design Guidelines for Complex Applications: تخفيف ازدحام الواجهة مع الحفاظ على قدراتها.
Baymard — Use Shipping Address as Billing Address: مصدر لقطة إعادة استخدام عنوان الشحن في Apple.
Baymard — Use Delivery Date Not Shipping Speed: مصدر لقطة تكلفة التوصيل وموعده في Apple على الحاسوب.
Baymard — Provide Fully Automatic Address Lookup: مصدر لقطة الإدخال اليدوي في Everlane عند عدم ظهور العنوان المناسب.
تاريخ النشر
14 أكتوبر 2026
آخر تعديل
14 أكتوبر 2026
