«القائمة تحتوي على عناصر كثيرة؛ يجب أن نُقلِّلها إلى سبعة». قد تسمع هذه العبارة أثناء مراجعة تصميم، ويُذكَر قانون ميلر لتبريرها. لكن ما الذي يحتاجه الشخص من التصميم فعلًا: هل عليه حِفْظ العناصر بعد اختفائها، أم يستطيع قراءتها والاختيار منها وهي أمامه؟
هذا الفرق مهم لفهم قانون ميلر (Miller’s Law). فالفكرة تتعلَّق بحدود الاحتفاظ بالمعلومات وتنظيمها في الذاكرة، ولا تضع حدًّا ثابتًا لعدد عناصر القوائم. ما يُفيدنا في التصميم هو تخفيف ما نُجبِر الشخص على تذكُّره، وتقديم المعلومات بطريقة يستطيع فَهْمَها والعودة إليها.
ما هو قانون ميلر؟
يرجع الاسم إلى ورقة جورج ميلر المنشورة عام 1956، بعنوان «العدد السحري سبعة، زائد أو ناقص اثنين: بعض حدود قدرتنا على معالجة المعلومات». ناقشت الورقة نتائج تتعلَّق بالتمييز بين مُنبِّهات وبالاحتفاظ المُؤقَّت بالمعلومات، وأبرزت أهمية تجميعها في وَحَدات ذات معنى.
اشتهر منها الرقم «7 ± 2»، لكنه لا يعني أن كل إنسان يستطيع دائمًا تذكُّر العدد نفسه من الأشياء، مهما كانت صعوبتها أو خبرته بها. كما أن البحث لم يكن تجربة لتحديد عدد الروابط المناسب في قائمة موقع.
ولفهم المقصود بالاحتفاظ المُؤقَّت، فكِّر في رمز تقرؤه ثم تكتبه في شاشة أخرى. أنت تحتاج إلى إبقائه في ذهنك مدة قصيرة. أما قراءة الخيارات الظاهرة في قائمة، فتُتيح لك الرجوع إلى النص بدل الاعتماد على ما حَفِظْتَه.
لذلك، حين تُراجِع شاشة، لا تبدأ بسؤال «كم عنصرًا فيها؟». اسأل أولًا: ما المعلومات التي يجب أن يَحمِلها الشخص في ذاكرته كي يُكمِل الخطوة التالية؟
هل الرقم الصحيح سبعة أم أربعة؟
قد تصادف تفسيرًا أحدث يقول إن العدد هو أربعة، ثم يتحوّل بدوره إلى توصية بوضع أربعة خيارات في كل واجهة. بهذه الطريقة نَستبدل رقمًا جامدًا بآخر دون فهم ما قِيسَ في البحث.
ناقش نيلسون كوان في مراجعته المنشورة عام 2001 سَعَةً تقارب أربع وَحَدات في ظروف تجريبية تُقيِّد عوامل مثل التكرار وتجميع العناصر في وَحَدات أكبر. النتيجة مرتبطة بطريقة الاختبار وتعريف الوحدة التي تُحسَب.
ما يهم المُصمِّم هنا أن قدرة ذاكرة الإنسان محدودة، وأن القياس يتأثَّر بطبيعة المعلومات وما يعرفه الشخص مسبقًا. لا نستنتج من هذه الدراسات أن أربع خيارات هي العدد الأمثل لكل صفحة، أو أن الخيار الخامس سيُربِك الجميع.
قد يكون أمامك نَمُوذج قصير بثلاثة حقول، لكنه يَطلب معلومات لا يعرف الشخص أين يجدها. وقد تكون أمامك قائمة طويلة بأسماء مألوفة يَعثر فيها بسرعة على ما يريد. اختلاف المهمة وطريقة عَرْض المعلومات يمنعنا من الحكم بالعدد وحده.
ما المقصود بتجميع المعلومات؟
التجميع، أو Chunking، هو التعامل مع معلومات مترابطة بوصفها وَحَدات مفهومة. وفي التصميم، نَستخدِم الفكرة لتنظيم المحتوى في مجموعات يستطيع الشخص تمييزها، كما يُوضِّح شرح تجميع المحتوى لدى Nielsen Norman Group.
خُذ سلسلة افتراضية من الأرقام مثل 48273196. عَرْضها على شكل 4827 3196 قد يُسهِّل قراءتها ومراجعتها. عدد الأرقام لم يتغيَّر، لكن العين تستطيع تتبُّع مقطعين بدل سلسلة متصلة. هذا لا يضمن أن الشخص حَفِظَها، لكنه يُحسِّن طريقة عَرْضها للمهمة.
والمجموعة المفيدة تحتاج إلى معنى أو ترتيب يُناسب ما يفعله الشخص. وضع أربع معلومات مختلفة داخل إطار واحد لا يجعلها تلقائيًا وحدة سهلة الفهم. اسم المُنتَج وتكلفته وموعد وصوله تنتمي إلى مُلخَّص الطلب، بينما إعدادات الإشعارات تُجيب عن سؤال مختلف.
كذلك، ما يبدو مجموعة واضحة لفريقك قد يكون غامضًا للعميل. عنوان مثل «بيانات تشغيلية» يحتاج إلى تفسير، بينما «موعد الزيارة وعنوانها» يُوضِّح مباشرة ما سيجده الشخص تحته.

لماذا لا نُحدِّد القوائم بسبعة عناصر؟
عندما يفتح الشخص قائمة، تبقى الخيارات أمامه ويمكنه قراءتها حتى يجد ما يريد. مثلًا، إذا كان يبحث عن «الإعدادات»، فلا يحتاج إلى حِفْظ بقية الخيارات ليختارها. لذلك، لا يكفي الاستناد إلى حدود الذاكرة لتحديد عدد عناصر القائمة بسبعة.
تُوضِّح Nielsen Norman Group الفرق بين التعرُّف والاسترجاع: التعرُّف يستفيد من وجود معلومات تُساعد الذاكرة، بينما يتطلَّب الاسترجاع تذكُّر المعلومة دون عَرْضها مباشرة. لذلك نُفضِّل عادةً جعل ما يحتاجه الشخص ظاهرًا أو سهل الوصول.
في متجر إلكتروني، قد تضمّ القائمة أكثر من سبعة تصنيفات، مثل الملابس والأحذية والأثاث والإلكترونيات. هذا لا يعني أنها صعبة الاستخدام، ما دامت أسماؤها واضحة ومرتّبة بطريقة تساعد الشخص على العثور على ما يريد. أما إخفاء بعض التصنيفات في صفحة أخرى لمجرد إبقاء سبعة منها، فقد يُضيف خطوة غير ضرورية للبحث.
لكن هذا لا يعني أن نَعرِض كل شيء في قائمة واحدة دون تنظيم. يمكن مثلًا جمع «الهواتف» و«الحواسيب» و«السماعات» تحت «الإلكترونيات». ما يهم هو أن يجد الشخص ما يبحث عنه بسهولة، وليس أن تحتوي القائمة على عدد مُحدَّد من العناصر.
مثال: طلب زيارة صيانة
لنفترض أنك تُصمِّم خدمة لحجز زيارة صيانة منزلية. يَختار الشخص نوع الجهاز، ويصف العُطل، ويُحدِّد العنوان والموعد. في النهاية، يحتاج إلى مراجعة الطلب قبل إرساله.
إذا كانت شاشة المراجعة تَعرِض اسم الخدمة وزرّ التأكيد فقط، فسيضطر الشخص إلى تذكُّر الموعد والعنوان الذي أدخله، أو الرجوع إلى الشاشات السابقة ليتأكّد. يمكنك مساعدته بمُلخَّص واضح يَجمع التفاصيل الضرورية.
قسِّم هذا المُلخَّص بحسب الأسئلة التي يُريد الإجابة عنها: ما الجهاز والمشكلة؟ أين ستتم الزيارة؟ ومتى؟ لا تحتاج إلى تقسيم متساوٍ في عدد البنود. قد تتطلَّب معلومات الجهاز سطرين، بينما يحتاج العنوان إلى تفاصيل أكثر.
اجعل تعديل كل مجموعة قريبًا منها. إذا كان العنوان خاطئًا، ينبغي أن يعرف الشخص كيف يُعدِّله دون إعادة وصف العُطل. وبعد عودته، أظهِر البيانات المُحدَّثة كي يتأكد مما حُفِظ.
أما التكلفة، فبيِّن ما يُعرَف منها في هذه المرحلة. إذا كانت رسوم الزيارة مُحدَّدة والتصليح يُسعَّر لاحقًا، فاعْرِض الفرق بوضوح. لا تعتمد على أن العميل يتذكَّر شرحًا قرأه قبل عدة خطوات.

أين يَظهَر العِبْء على الذاكرة؟
قد تكون المشكلة في تفاصيل صغيرة بين الشاشات. مثلًا، يَعرِض تطبيق الدعم رقم الطلب في رسالة قصيرة تختفي، ثم يطلب إدخاله في نَمُوذج التواصل. هنا نَطلب من الشخص الاحتفاظ بمعلومة كان يمكن للنظام نقلها أو إظهارها.
في حالة كهذه، يمكنك ملء رقم الطلب تلقائيًا عندما يبدأ التواصل من صفحة الطلب. وإذا احتاج الشخص إلى نسخه، فوفِّر طريقة واضحة لذلك، مع إبقائه متاحًا للرجوع إليه. لا تجعل نجاح المهمة يعتمد على سرعة الحِفْظ.
وقد تَظهَر المشكلة أثناء مقارنة مُنتَجَين. إذا احتاج الشخص إلى التنقّل بين صفحتين ليتذكَّر السِّعر والضمان والأبعاد، فجرِّب عَرْض المواصفات المهمة معًا. اخْتَر صفوف المقارنة بحسب ما يَستخدِمه الجمهور في القرار، لا بحسب كل البيانات المتاحة لديك.

وفي النماذج، أَبقِ تسمية الحَقْل ظاهرة بعد بدء الكتابة. إذا كانت المعلومة موجودة داخل الحَقْل ثم اختفت، فقد ينسى الشخص ما المطلوب أو الصيغة المناسبة. ويمكن وضع مثال قصير أو تعليمات ثابتة عندما تكون الإجابة غير واضحة.
هذه المعالجات لا تحتاج إلى افتراض أن كل شخص يستطيع حِفْظ مقدار مُحدَّد. هي تُعيد المعلومات إلى موضع الحاجة، بحيث يُصبِح التحقُّق منها جزءًا سهلًا من الاستخدام.
كيف تُطبِّق الفكرة دون مبالغة؟
ابدأ بمهمة واحدة في مُنتَجك، وتتبَّع المعلومات التي تَظهَر ثم تختفي أو تنتقل إلى مكان بعيد. بعد ذلك، راجِعها بخطوات عملية:
حَدِّد ما يحتاجه القرار التالي. اكتُب المعلومة التي يجب أن يعرفها الشخص كي يُكمِل، مثل الموعد أو السِّعر أو الخيار الذي اختاره.
أَبقِ هذه المعلومة متاحة. اعْرِضها في مُلخَّص مناسب أو بجانب الإجراء المرتبط بها.
اجْمَع ما ينتمي إلى السؤال نفسه. استخدم عناوين واضحة ومسافات تُبيِّن المجموعات، دون فرض عدد مُوحَّد لبنودها.
اختصر التكرار المطلوب من الشخص. إذا سبق أن أدخل معلومة، ففكِّر في إعادة استخدامها مع السماح بمراجعتها وتعديلها.
اختبر العودة والتصحيح. تحقَّق من أن تعديل جزء من الطلب لا يُضيِّع البيانات الأخرى أو يُجبِر الشخص على حِفْظِها مجددًا.
ولا تحوِّل كل سطر إلى بطاقة مُستقِلّة. كثرة الإطارات والعناوين قد تُفتِّت المعلومات المترابطة. كما أن إخفاء كل التفاصيل داخل أقسام مطوية قد يُجبِر الشخص على فتحها واحدًا واحدًا حتى يُكوِّن صورة عن الطلب.
راجِع خصوصًا المعلومات التي تُقارَن معًا. إذا كان اسم الباقة ظاهرًا والسعر في قِسم مُغلَق، فقد تكون قد نظّمت الشاشة بصريًا على حساب فَهْمِها. العلاقة بين المعلومات أهم من تساوي أحجام المجموعات.
كيف تَختَبِر أن التنظيم أفضل؟
في نَمُوذج الصيانة، اطلب من شخص مراجعة طلب جاهز وتعديل الموعد ثم التأكد من العنوان. راقِب إن كان يحتاج إلى الرجوع بحثًا عن معلومات، وإن كان يُميِّز بين ما غيّره وما بقي كما هو.
يمكنك أيضًا ملاحظة الاستخدام بعد انقطاع قصير إذا كان ذلك يشبه ظروف جمهورك. هل يعرف الشخص أين وصل؟ هل يستطيع رؤية اختياراته السابقة؟ لا تجعل الاختبار امتحانًا للذاكرة؛ أنت تَختَبِر مقدار الدعم الذي تُقدِّمه الواجهة.
وعند مقارنة نسختين، راجِع الأخطاء والرجوع المُتكرِّر والحاجة إلى المساعدة. قد تُقلِّل نسخة جديدة التمرير، لكنها تُخفِي معلومات فيزداد الرجوع بين الصفحات. عدد الشاشات أو طول الصفحة وحده لا يكفي للحكم.
الخبرة واللغة وظروف الاستخدام تختلف بين الأشخاص، لذلك اخْتَر مشاركين يُمثِّلون جمهورك. ولا تَستنتج قدرة شخص على التعامل مع المعلومات من عمره وحده؛ راقِب أداءه واحتياجاته في المهمة الفِعليّة.
المصادر
George A. Miller — The Magical Number Seven, Plus or Minus Two، 1956: الورقة الأصلية وحدات المعلومات والذاكرة.
Nelson Cowan — The Magical Number 4 in Short-Term Memory، 2001: مراجعة السعة في ظروف تجريبية محدّدة.
Nielsen Norman Group — How Chunking Helps Content Processing: تنظيم المحتوى في مجموعات مفهومة.
Nielsen Norman Group — Memory Recognition and Recall: الفرق بين التعرُّف والاسترجاع في الواجهات.
NN/g — 4 Principles to Reduce Cognitive Load in Forms، 2025: مصدر لقطة تجميع حقول Slack.
NN/g — The Mobile Checkout Experience، 2018: مرجع لتجربة الدفع على الهاتف، يتضمّن مثالًا من Jet.com.
NN/g — Comparison Tables for Products, Services, and Features، 2024: مصدر لقطة مقارنة شواحن Anker في Amazon.
تاريخ النشر
6 أكتوبر 2026
آخر تعديل
6 أكتوبر 2026



