قانون 0 ، 1 و n در طراحی تجربه و Policy محصول

وقتی در یک صفحه میخواهیم یک المان تکرارشونده (مثل یک لیست، اسلایدر یا ترکیبی از بلوکها) قرار دهیم، باید صفحه را برای سه حالت طراحی کنیم:
- زمانیکه هیچ رکوردی در صفحه نیست: 0
- زمانیکه فقط یک رکورد هست: 1
- وقتی چندین رکورد هست: n

مثلا در طراحی صفحه قبوض در یک اپ پرداخت، اگر هنوز کاربر هیچ قبضی ندارد، باید پیامی جهت دعوت از کاربر به افزودن اولین قبض به او نشان دهیم. زمانیکه یک قبض دارد، همان یک قبض را طراحی می‌کنیم. و وقتی چندین قبض دارد باید فاصله بین قبوض و سیاست‌های صفحه بندی (المانهای pagination یا LazyLoad) را نیز طراحی کنیم (مساله اصلی این است که هنگامی که n تا موجودیت داریم، درگیر طراحی روابط بین آن موجودیت ها نیز می شویم.)

قانون 0، 1 و n در طراحی دیتابیس و entityها نیز وجود دارد:
وقتی دو entity رابطه ای با هم ندارند
وقتی رابطه 1 به 1 دارند
وقتی رابطه 1 به n دارند

و در طراحی Policy محصول:
مثلا در گوگل درایو: هر فایل امکان share دارد. یا فایل x را با هیچکس شیر نکرده‌اید. یا با یک نفر (یا چند تا تک نفر) با ایمیل شخصیشان شیر کردید. یا با n نفر (پابلیک شیر) کرده‌اید. هر یک از این یوزکیس‌ها، طراحی فرایند جداگانه ای را نیاز دارد.

مثال دیگر :
مثلا یک سرویس ارسال پیام طراحی میکنید. همراه هر پیام یا هیچ فایلی قابل ارسال نیست. یا یک فایل قابل ارسال است و یا n فایل. این مدل تفکر، کلیه فرایندهای طراحی (از یوزر استوری تا رابط کاربری) را تحت الشعاع قرار میدهد.

مثلا دیگر:
وقتی کاربر در سبد خریدش دکمه پرداخت را میزند و کالایی ندارد چه کنیم؟ (شاید در اینجا تصمیم بگیرید که دکمه را غیرفعال کنید) وقتی یک کالا دارد چه؟ و زمانیکه چندین (n) کالا دارد چطور؟

مثال دیگر:
شما یا مجرد هستید. یا یک همسر دارید. یا چند همسره اید! (در این آخری، علاوه بر مدیریت هر همسر بصورت جدا، باید روابط بین آنها را نیز مدیریت کنید. مثلا padding و margin بین آنها تا بهم دیگر برخورد نکنند?)