در یک صفحه شلوغ، راهحل همیشه حذف محتوا نیست؛ گاهی رابطه میان اجزا خوانده نمیشود. عنوان به توضیح خودش نزدیک نیست، خطهای متن به هم میچسبند، دکمه و هشدار یک وزن بصری دارند و کارتها روی موبایل فضای قابلاستفاده را میبلعند. «فضای سفید» ابزاری برای طراحی این رابطههاست، نه چند پیکسل خالی برای زیباترکردن ماکاپ.
این راهنما فضای سفید در طراحی وب را به یک سیستم قابلپیادهسازی و قابلآزمون تبدیل میکند: از Micro و Macro spacing، تایپوگرافی فارسی و RTL تا Design token، Responsive layout، دسترسپذیری، فرم، CTA، حالتهای خطا، CLS و سنجش نتیجه. هیچ عددی نسخه جهانی نیست؛ مقادیر نمونه باید با فونت، محتوا، دستگاه و کاربران واقعی محصول شما اعتبارسنجی شوند.
پاسخ کوتاه: فضای سفید در طراحی وب چیست؟
فضای سفید یا Negative space ناحیهای است که عنصر محتوایی یا کنترل فعال ندارد و برای جداسازی، گروهبندی، ریتم، تمرکز و امکان تعامل استفاده میشود. این فضا لازم نیست سفید باشد؛ میتواند رنگ پسزمینه، بافت یا بخشی آرام از تصویر باشد. ارزش آن از «خالیبودن» نمیآید، بلکه از رابطهای میآید که میان عناصر قابلدرک میکند.
فضای سفید نتیجه مجموعهای از تصمیمهاست: gap در Grid/Flex، padding داخل Component، margin میان Blockها، line-height، فاصله پاراگرافها، عرض ستون، اندازه Target و حتی فضای رزروشده برای محتوای دیررس. بنابراین بهتر است آن را بخشی از معماری رابط بدانیم، نه تزئین مرحله آخر.
| مفهوم | نمونه | کار اصلی | ریسک استفاده نادرست |
|---|---|---|---|
| Micro spacing | فاصله Icon و Label، خطها و Fieldها | خوانایی و تشخیص جزء | ازدحام یا گسست کوچک |
| Macro spacing | فاصله Sectionها، ستونها و لبه صفحه | ساختار و ریتم کل صفحه | ابهام گروهبندی یا Scroll بیدلیل |
| Active white space | فضای عمدی دور CTA یا Hero | اولویت و مسیر نگاه | تمرکز مصنوعی بدون پیام خوب |
| Passive white space | فضای طبیعی حروف و محتوای تصویر | تنفس پایه | نادیدهگرفتن در Export یا Crop |
فضای سفید با ویژگی CSS white-space یکی نیست
در زبان طراحی، White space همان فضای منفی اطراف و میان اجزاست. در CSS، ویژگی white-space تعیین میکند فاصلهها و شکست خط داخل متن چگونه Collapse یا Preserve شوند. این دو همناماند اما یک مسئله را حل نمیکنند. برای ساخت فاصله چیدمان، از gap، padding، margin و اندازههای Flow-relative استفاده کنید؛ از فاصله یا های تکراری بهعنوان ابزار Layout استفاده نکنید.
| نیاز | ابزار مناسب | ابزار نامناسب |
|---|---|---|
| فاصله آیتمهای Flex/Grid | gap | Margin تصادفی روی Childها |
| فضای داخل Button/Card | padding | Space داخل متن |
| فاصله دو Block مستقل | Stack token یا margin-block | <br>های متعدد |
| رفتار شکست متن | white-space و Wrap policy | عرض ثابت و بریدن متن |
| جهت فارسی | dir در HTML و Logical properties | تعویض دستی left/right در هر صفحه |
فضای سفید چه مسئلههایی را حل میکند؟
Spacing میتواند فهم رابطه، اسکن محتوا، تفکیک کنترلها و لمس دقیقتر را آسان کند؛ اما خودِ فاصله کیفیت پیام، معماری اطلاعات یا قابلیت محصول را جبران نمیکند. اگر کاربر نمیداند CTA چه میکند، بزرگکردن حاشیه دور آن فقط یک ابهام برجستهتر میسازد.
گروهبندی و Proximity
عناصر نزدیک معمولاً مرتبطتر برداشت میشوند. فاصله Label تا Field باید کمتر از فاصله آن گروه با Field بعدی باشد. همین نسبت برای عنوان/پاراگراف، قیمت/دوره پرداخت و Error/کنترل مربوط صدق میکند. Semantic HTML و DOM order باید همان رابطه را پشتیبانی کنند؛ نزدیکی بصری بهتنهایی برای Screen reader کافی نیست.
سلسلهمراتب و ریتم
تفاوت منظم میان فاصلههای کوچک، متوسط و بزرگ به کاربر میگوید کجا یک جزء، گروه یا Section تازه شروع میشود. اگر همه فاصلهها برابر باشند، صفحه Flat به نظر میرسد؛ اگر هر فاصله مقدار یکتایی داشته باشد، الگو آموختنی نیست. ریتم باید از Type scale و Component hierarchy مشتق شود.
تمرکز، بدون وعده Conversion
فضای آرام اطراف عنصر میتواند رقابت بصری را کاهش دهد، اما «Whitespace بیشتر = Click بیشتر» قانون نیست. Click ممکن است بهدلیل پیام، قیمت، محل قرارگیری، اعتماد یا Segment تغییر کند. نتیجه را با Task success، Quality و Guardrail آزمایش کنید؛ نه با سلیقه تیم یا یک Case study بیزمینه.
مقدار بهینه جهانی وجود ندارد
فضای کم الزاماً بد و فضای زیاد الزاماً لوکس یا حرفهای نیست. داشبورد عملیاتی، فرم اضطراری، فروشگاه و مجله نیازهای متفاوت دارند. فرهنگ بصری، سن کاربر، توانایی بینایی/حرکتی، فونت، زبان، اندازه صفحه، چگالی اطلاعات و فوریت Task بر تصمیم اثر میگذارند. طراحی مینیمال نیز با «بیشترین فضای خالی» تعریف نمیشود؛ مقاله طراحی مینیمال با حداقل پیچیدگی مؤثر این مرز را دقیقتر باز میکند.
| عامل | پرسش تصمیم | پیامد برای Spacing |
|---|---|---|
| Task | اسکن، مطالعه، مقایسه یا عملیات سریع؟ | ریتم و Density متفاوت |
| Content | طول Label و داده در بدترین حالت چیست؟ | فضای رشد و Wrap |
| Input | Touch، Mouse، Keyboard یا Voice؟ | Target و جداسازی کنترل |
| Viewport | عرض، Zoom و Orientationهای واقعی؟ | Responsive token و Reflow |
| Risk | خطای لمس یا برداشت چه هزینهای دارد؟ | فاصله و تأیید بیشتر برای عمل پرخطر |
| Brand | ریتم برند با کاربردپذیری سازگار است؟ | Optical adjustment کنترلشده |
Spacing brief: پیش از پیکسل، Context را بنویسید
برای صفحه یا Component یک Brief کوتاه بسازید: کاربر و Task، Device و Input، زبان و جهت، محتوای حداقل/حداکثر، Priority، Stateها، سطح Density، معیار دسترسپذیری، Outcome و Guardrail. این سند اختلاف «به نظرم شلوغ است» را به تصمیم قابلآزمون تبدیل میکند.
| فیلد | نمونه برای فرم ثبت درخواست |
|---|---|
| Task | ارسال درخواست با کمترین خطای قابلاصلاح |
| Context | موبایل، اینترنت متوسط، فارسی RTL |
| Content extremes | Label دوخطی، Error سهخطی، نام طولانی فایل |
| Density | Comfortable؛ بدون پنهانکردن فیلد ضروری |
| Accessibility | Zoom/Reflow، Text spacing، Focus و Target QA |
| Outcome | Task completion معتبر |
| Guardrail | خطای فیلد، زمان، Abandonment و شکایت |
ممیزی وضع موجود را با Screenshot تنها انجام ندهید
Screenshot یک Viewport و یک State را ثبت میکند. ممیزی باید DOM، CSS computed values، Token usage، Content extremes، Zoom، Keyboard، Touch، زبان، خطا، Loading و داده واقعی Device را نیز ببیند. در Inventory، هر Pattern را به Component و مالک نگهداری متصل کنید.
| شاهد | چه چیزی نشان میدهد؟ | محدودیت |
|---|---|---|
| Spacing inventory | مقادیر یکتا و Drift | چرایی استفاده را نمیگوید |
| Heatmap/Click map | الگوی تعامل ثبتشده | Intent و موفقیت را ثابت نمیکند |
| Session replay | نمونه اصطکاک و Context | Privacy و سوگیری نمونه |
| Usability test | مسئله و علت محتمل | نرخ جمعیت را برآورد نمیکند |
| Analytics | فراوانی Event/Outcome | بدون تعریف و Instrumentation گمراهکننده است |
| Accessibility QA | شکست در Zoom/Focus/Override | آزمون خودکار همه تجربه را نمیبیند |
سیستم فاصلهگذاری را با Design token بسازید
بهجای مقادیر پراکنده مثل ۱۳، ۱۹ و ۲۷ پیکسل، مجموعه کوچکی از Tokenها بسازید و آنها را به معنا و Component وصل کنید. مقیاس ۴ یا ۸ پیکسلی نقطه شروع رایج است، نه قانون طبیعی. USWDS از واحدهای عمدتاً مضرب ۸ استفاده میکند و GOV.UK مقیاس Responsive و Static خود را دارد؛ اینها نمونه سیستماند، نه عدد اجباری برای محصول شما.
سه لایه Token
Primitive مقدار خام مثل space-2 است؛ Semantic کاربردی مثل space-content-gap؛ و Component تصمیمی مثل button-padding-inline. Component نباید بهطور گسترده Primitive را مستقیم مصرف کند، چون تغییر Density یا Brand دشوار میشود.
| لایه | نمونه | مالک | قاعده تغییر |
|---|---|---|---|
| Primitive | --space-3: 0.75rem | Design system | کمتغییر و Versioned |
| Semantic | --space-group-gap | System + Product | بر اساس معنی و Density |
| Component | --field-message-gap | Component owner | با State و Content test |
| Exception | --promo-optical-offset | Design review | محدود، مستند و تاریخدار |
:root {
--space-1: .25rem;
--space-2: .5rem;
--space-3: .75rem;
--space-4: 1rem;
--space-6: 1.5rem;
--space-section: clamp(2rem, 5vw, 4.5rem);
--field-stack-gap: var(--space-4);
}
.section {
padding-block: var(--space-section);
padding-inline: var(--space-4);
}
.field-group {
display: grid;
gap: var(--field-stack-gap);
}Margin، Padding و Gap را بر اساس مالکیت انتخاب کنید
Padding بخشی از سطح قابلکلیک و فضای داخل Component است؛ Gap رابطه Children را در Layout تعریف میکند؛ Margin فاصله بیرونی یک Block را میسازد. قاعده عملی این است که Parent تا حد ممکن فاصله میان Children را مالک باشد و Component درباره فضای داخلی خودش تصمیم بگیرد.
Margin collapse و استثناهای پنهان
Margin عمودی Blockها ممکن است Collapse شود و نتیجه با جمع ساده مقادیر فرق کند. Flex/Grid gap چنین رفتاری ندارد. Negative margin نیز میتواند Focus، Hit area، Overflow یا همپوشانی را خراب کند. استفاده از آن باید استثنا، مستند و در Zoom/RTL/Stateهای پویا آزمایش شود.
| رابطه | مالک پیشنهادی | Primitive | تست |
|---|---|---|---|
| Icon ↔ Label | Component | Gap کوچک | Wrap و Bidi |
| Label ↔ Input | Field | Gap کوچک/متوسط | Error و Help text |
| Field ↔ Field | Form stack | Gap متوسط | Touch و Zoom |
| Card ↔ Card | Grid/List | Responsive gap | یک تا چند ستون |
| Section ↔ Section | Page template | Semantic section gap | Hierarchy و Fold |
تایپوگرافی فارسی: فضای خط، پاراگراف و ستون
خوانایی فقط از فاصله خطوط نمیآید. Font، وزن، اندازه، طول خط، Contrast، کیفیت Hinting، نمایش اعداد و عرض ستون با هم کار میکنند. فونت فارسی ممکن است Ascender/Descender و ارتفاع دیداری متفاوتی از فونت لاتین هماندازه داشته باشد؛ بنابراین یک line-height واحد برای Font fallbackها نتیجه یکسان نمیدهد.
Line-height را Ratio ثابت جهانی نکنید
عددهای ۱٫۵ یا ۱٫۸ میتوانند نقطه شروع برای متن بدنه باشند، اما قانون همه متنها نیستند. Heading کوتاه، Button، جدول و متن چندخطی نیاز متفاوت دارند. با محتوای واقعی، Bold، لینک، اعراب، عدد، متن فارسی/لاتین و Zoom آزمایش کنید. از Box با Height ثابت که خط دوم را میبُرد پرهیز کنید.
WCAG ۱.۴.۱۲ توصیه تایپوگرافی ثابت نیست
معیار Text Spacing میگوید کاربر باید بتواند Line-height را دستکم ۱٫۵ برابر Font، فاصله پس از پاراگراف را ۲ برابر، Letter spacing را ۰٫۱۲ و Word spacing را ۰٫۱۶ برابر Font تغییر دهد بدون از دسترفتن محتوا یا عملکرد. این اعداد الزام طراحی پیشفرض صفحه نیستند؛ آزمون مقاومت Layout در برابر Override کاربرند. در خط فارسی، تغییر Letter spacing را بهعنوان جلوه بصری تحمیل نکنید و اتصال حروف و Wrap را بررسی کنید.
| جزء متن | تصمیم Spacing | شکست محتمل | QA |
|---|---|---|---|
| متن بدنه | Line-height + Measure + Paragraph gap | گمکردن خط یا ستون بیشازحد عریض | مطالعه و Zoom |
| Heading | فاصله قبل بیشتر از بعد | تعلق مبهم به Section | اسکن بدون Style |
| Link inline | فضای طبیعی متن | Touch کوچک یا Wrap عجیب | Keyboard/Touch |
| عدد و واحد | Bidi isolate و عدم شکست لازم | جابجایی تومان/درصد | RTL/LTR mix |
| جدول | Cell padding و Line wrap | Scroll دوبعدی یا Cutoff | ۳۲۰ CSS px و Zoom |
RTL و محتوای دوزبانه: از Logical property استفاده کنید
برای فارسی، جهت پایه را در Markup با dir="rtl" مشخص کنید و برای قطعه مستقل لاتین، عدد پیچیده یا کد از dir="ltr" یا bdi متناسب استفاده کنید. W3C توصیه میکند اطلاعات جهت تا حد ممکن در Markup باشد؛ چون Style sheet ممکن است در دسترس نباشد.
Start/End بهجای Left/Right
margin-inline-start، padding-inline و inset-inline-end با Writing mode تطبیق مییابند. این رویکرد Fork جداگانه RTL/LTR را کم میکند، اما Iconهای جهتدار، ترتیب Stepper، نمودار، Carousel و حرکت Transition همچنان باید معنایی بررسی شوند؛ همه چیز صرفاً Mirror نمیشود.
.notice {
border-inline-start: .25rem solid var(--color-accent);
padding-inline-start: var(--space-4);
margin-block: var(--space-6);
}
.price {
display: inline-flex;
gap: var(--space-1);
align-items: baseline;
}Responsive spacing: Breakpoint را از شکست محتوا بگیرید
Desktop spacing را با ضریب ثابت کوچک نکنید. ابتدا Layout را با متن واقعی باریک کنید و نقطهای را پیدا کنید که رابطه، Target یا خوانایی خراب میشود. در آن نقطه Grid، Density یا Stack تغییر کند. clamp() میتواند فاصله سیال بسازد، ولی Min/Max باید محدود و قابلتست باشد.
| شرایط | تغییر محتمل | آنچه نباید قربانی شود |
|---|---|---|
| Viewport باریک | کاهش Section gap و تکستونهشدن | Target، Grouping و Edge space |
| Zoom 200%/400% | Reflow و Wrap بیشتر | محتوا، عملکرد و Focus |
| Landscape موبایل | کاهش ارتفاع Hero | CTA و Context ضروری |
| Label طولانی | رشد ارتفاع Component | متن کامل و Touch area |
| Keyboard باز | Scroll/Viewport adjustment | Field، Error و Submit قابلمشاهده |
Spacing باید همه Stateهای Component را پوشش دهد
کامپوننت در Figma اغلب فقط Default است، اما محصول Loading، Empty، Error، Success، Disabled، Selected، Expanded، Hover و Focus دارد. پیام خطا میتواند سه خط شود، Badge اضافه شود یا ترجمه طولانیتر گردد. Token و Container باید این تغییر را بدون بریدگی یا همپوشانی تحمل کنند.
| State | نیاز فضایی | خطر | پذیرش |
|---|---|---|---|
| Loading | ابعاد رزروشده نزدیک خروجی | Layout shift | جایگزینی پایدار |
| Error | فضای پیام و Action اصلاح | هلدادن CTA یا جدایی از Field | رابطه Programmatic/Visual |
| Focus | فضای Indicator و عدم پوشاندن | Clip یا Obscure | Keyboard traversal |
| Selected | Border/Check بدون تغییر ابعاد | پرش Grid | Box sizing ثابت |
| Empty | پیام، راه بعدی و Context | فضای عظیم بدون راهنما | Task recovery |
| Expanded | Flow طبیعی محتوا | Overlay روی کنترل بعدی | Zoom و Scroll |
Target لمسی و Focus: فضای خالی جای سطح تعامل نیست
فاصله میان دو Icon احتمال لمس اشتباه را کم میکند، اما اگر خود Target فقط Glyph کوچک باشد، فضای اطراف لزوماً Clickable نیست. WCAG ۲.۲ در معیار AA «Target Size (Minimum)» حد ۲۴×۲۴ CSS pixel یا Spacing کافی میان Targetهای کوچک را با استثناهایی تعریف میکند؛ معیار AAA اندازه ۴۴×۴۴ را مطرح میکند. این حداقلها را سقف کیفیت نگیرید و برای کار پرتکرار یا پرخطر فضای بیشتری در نظر بگیرید.
Focus ring نباید با overflow: hidden بریده یا زیر Header چسبان پنهان شود. فاصله اطراف کنترل باید Indicator را در همه Stateها جا دهد. راهنمای طراحی فراگیر و WCAG ۲.۲ معیارهای Keyboard، Focus، Contrast و Target را یکجا پوشش میدهد.
فرمها: فاصله باید رابطه و خطا را توضیح دهد
در فرم، فاصله Label→Input، Help→Input و Error→Field باید تعلق را روشن کند. گروه آدرس، روش تماس یا رضایت باید با fieldset/legend یا ساختار معنایی مناسب نیز مشخص شود. فقط با فاصله، Grouping را به کاربر Screen reader منتقل نمیکنید.
فاصله زیاد میان Label و Input میتواند تعلق را مبهم کند؛ فاصله کم میان دو Field نیز آنها را یک گروه نشان میدهد. Button اصلی و ثانویه باید هم از نظر Label و هم فاصله قابلتفکیک باشند. «کوتاهتر نشاندادن» فرم با حذف فاصله، Completion را تضمین نمیکند؛ تعداد/ضرورت Field، ترتیب و خطای قابلاصلاح مهمترند.
| رابطه فرم | نسبت پیشنهادی | معیار پذیرش |
|---|---|---|
| Label → Input | نزدیکتر از Input → Field بعدی | تعلق در نگاه و DOM روشن |
| Help → Input | داخل گروه Field | قبل از ورود قابلفهم |
| Error → Field | نزدیک و بدون پوشاندن محتوا | Programmatic association و Focus |
| Group → Group | بزرگتر از فاصله داخلی | Section بدون Border اضافه فهمیده شود |
| Submit → Secondary | متناسب با خطر و جهت | خطای عمل و بازگشت قابلاندازهگیری |
CTA و Conversion: فرضیه بسازید، نسخه عمومی نه
فضای بیشتر اطراف CTA ممکن است Salience را افزایش دهد، اما Conversion تابع Source، Message match، Offer، Evidence، قیمت، Form friction و Intent است. CTA جداافتاده حتی میتواند Context لازم برای تصمیم را دور کند. در صفحه فرود، فاصله را همراه وعده، شاهد و Action بسنجید؛ راهنمای لندینگ پیج، فرم و A/B تست این زنجیره را کامل میکند.
Outcome را «Click دکمه» نگیرید اگر ارزش واقعی بعدتر ایجاد میشود. Qualified lead، Purchase، Activation یا Task completion را بهعنوان Outcome و Error، Refund، Lead quality یا Complaint را Guardrail قرار دهید.
صفحات پرتراکم و Density mode
داشبورد، جدول مالی و پنل عملیات به تراکم بیشتری نیاز دارند. راهحل، حذف بیقاعده فاصله نیست؛ Density mode با Tokenهای Semantic است. حالت Compact میتواند Row height و Gap را کم کند، اما Label، Target، Focus و مرز گروهها باید قابلاستفاده بمانند. ترجیح کاربر را ذخیره کنید و برای صفحه کوچک حالت جداگانه بسازید.
| Mode | مناسب برای | تغییر | ثابت |
|---|---|---|---|
| Comfortable | مطالعه، فرم، کاربر عمومی | Gap و Row بزرگتر | Hierarchy و Semantics |
| Compact | کاربر خبره و داده زیاد | Gap/Height کمتر | Keyboard، Focus و اطلاعات |
| Touch | تبلت/موبایل یا محیط لمسی | Target و جداسازی بیشتر | ترتیب و Label |
| Large text | Zoom یا ترجیح دسترسپذیری | Wrap و ارتفاع سیال | عملکرد و محتوای کامل |
فروشگاه اینترنتی و فهرست محصول
در Product grid، فاصله زیاد میتواند مقایسه را سخت و تعداد گزینه قابلمشاهده را کم کند؛ فاصله کم نیز نام، قیمت، تخفیف و Action کارتها را مخلوط میکند. نسبت فضای داخل Card به Gap میان Cardها باید مالکیت اطلاعات را روشن کند. روی موبایل، Sticky action نباید محتوای آخر یا Focus را بپوشاند.
فیلتر، Variant، موجودی، قیمت تومان/ریال و پیام ارسال طولهای متفاوت دارند. با Dataset بدترین حالت تست کنید. برای Journey کامل از Browse تا Checkout، به راهنمای UX فروشگاه اینترنتی رجوع کنید.
صفحه اصلی و Hero
Hero بزرگ با فضای خالی فراوان لزوماً پیام Premium نمیسازد. اگر Category، Outcome، Mechanism، Evidence یا Route در Viewportهای رایج پنهان شود، فضای تزئینی هزینه دارد. تصویر پسزمینه نیز ممکن است از نظر رنگ خالی به نظر برسد اما از نظر Attention شلوغ باشد.
در صفحه اصلی، فاصله باید Routeهای اصلی را از Promotion جدا و Hierarchy را برای ورودیهای مختلف حفظ کند. راهنمای طراحی صفحه اصلی بر اساس پیام، مسیر و تبدیل الگوی Brief و تست پنجثانیهای را توضیح میدهد.
کارت، تصویر، جدول و محتوای Rich
Padding کارت مرز مالکیت را میسازد؛ Gap بیرون کارت، رابطه با کارت بعدی را. اگر هر Card چند Card داخلی داشته باشد، عمق بصری و فاصلههای تودرتو سریعاً زیاد میشوند. ابتدا ساختار محتوا را ساده کنید. Border و Shadow را جایگزین خودکار فضای سفید ندانید.
برای تصویر، فضای منفی داخل خود Asset نیز مهم است. Crop خودکار ممکن است سوژه یا متن را به لبه ببرد. Safe area را در Asset spec نگه دارید. جدول داده به Cell padding کافی نیاز دارد، اما در موبایل باید Reflow، Scroll با Label یا نمایش جایگزین متناسب با معنی داشته باشد؛ صرفاً کوچککردن Font راهحل نیست.
محتوای پویا و CLS: فضا را پیشاپیش رزرو کنید
تصویر، تبلیغ، Embed، Banner رضایت، Font و پیام خطای دیررس میتوانند پس از Render فضا بگیرند و محتوا را جابهجا کنند. این «فضای ناگهانی» ریتم را خراب و حتی باعث Click اشتباه میشود. برای Media ابعاد یا aspect-ratio تعیین کنید، Placeholder نزدیک به خروجی بسازید و محتوای پویا را بالای چیزی که کاربر در حال خواندن است تزریق نکنید.
CLS بیثباتی دیداری را میسنجد، نه زیبایی Spacing. هدف خوب Core Web Vitals برای CLS، حداکثر ۰٫۱ در صدک ۷۵ Visitهاست؛ داده Field و Segment صفحه/Device را بررسی کنید. برای اتصال Performance به Task و Business outcome، راهنمای سرعت سایت، UX، سئو و تبدیل مفید است.
دسترسپذیری: چهار آزمون ضروری Spacing
Spacing خوب باید با تغییر نیاز کاربر نشکند. حداقل این چهار سناریو را دستی آزمایش کنید: Zoom و Reflow تا عرض معادل ۳۲۰ CSS pixel؛ Override معیار Text spacing؛ پیمایش کامل Keyboard با Focus قابلمشاهده؛ و Targetهای Pointer در صفحه لمسی. Contrast و ساختار Heading/Label نیز مستقل از فاصله کنترل شوند.
| آزمون | انتظار | شکست رایج |
|---|---|---|
| Reflow | بدون از دسترفتن محتوا/عملکرد و Scroll دوبعدی عمومی | ستون ثابت یا Sticky پوشاننده |
| Text spacing override | متن کامل، بدون Overlap/Cutoff | Height ثابت و Badge باریک |
| Keyboard/Focus | Indicator واضح و پنهاننشده | Overflow clip یا Header ثابت |
| Target | اندازه/فاصله مطابق معیار و Context | Icon کوچک با فضای غیرقابلکلیک |
| RTL/Bidi | ترتیب و Start/End درست | Mirror صوری و واحد جابهجا |
فضای سفید و سئو: سیگنال مستقیم اعلامشده نیست
Google برای مقدار Margin، Padding یا White space امتیاز مستقیمی اعلام نکرده است. همچنین Bounce rate یا Dwell time را نمیتوان از GA4 برداشت و بهعنوان علت رتبه معرفی کرد. Google میگوید یک «سیگنال واحد Page experience» وجود ندارد و Core Web Vitals خوب نیز رتبه بالا را تضمین نمیکند. هدف اول باید تجربه قابلاستفاده باشد.
Spacing میتواند بهطور عملی خواندن، تشخیص Main content، Mobile use و جلوگیری از CLS را کمک کند؛ اینها ارزش کاربری دارند. اما اگر محتوا نامرتبط، صفحه غیرقابل Crawl یا هدف جستوجو اشتباه باشد، فضای بیشتر آن را حل نمیکند. Engagement rate و Bounce rate در GA4 تعریف تحلیلی خود را دارند و ابزار تشخیصاند، نه مهر کیفیت یا Ranking factor.
تست کاربردپذیری برای تشخیص مسئله
برای سنجش رابطههای بصری، از کاربر بخواهید Task واقعی انجام دهد: «خطای این فرم را پیدا و اصلاح کن» یا «قیمت سالانه این دو گزینه را مقایسه کن». فقط نپرسید صفحه خلوت است یا نه. موفقیت، زمان، خطا، مسیر نگاهِ گزارششده، فهم Grouping و Confidence را ثبت کنید.
نمونه کوچک میتواند مسئله جدی را کشف کند اما نرخ جمعیت را دقیق تخمین نمیزند. یافته را با Severity، Evidence و Context بنویسید و به Component/Token مالک وصل کنید. راهنمای طراحی و اجرای تست کاربردپذیری برای Recruitment، Task، مشاهده و تصمیم قابل استفاده است.
A/B تست برای برآورد اثر
وقتی دو نسخه قابلقبول دارید و اثر تجاری نامطمئن است، آزمایش کنترلشده طراحی کنید. یک Hypothesis بنویسید: «افزایش فاصله میان گروههای فرم، تشخیص بخشها را بهتر و خطای Field را کم میکند، بدون افت Completion واجدشرایط.» سپس Primary metric، Guardrail، Unit assignment، MDE، توان، بازه، SRM check و Stop rule را پیش از مشاهده نتیجه تعیین کنید.
| لایه | نمونه | تفسیر مجاز |
|---|---|---|
| Exposure | کاربر واقعاً Variant را دید | سلامت اجرای آزمایش |
| Diagnostic | Field error و Scroll | علت محتمل، نه Outcome نهایی |
| Primary outcome | ارسال معتبر درخواست | اثر بر Task تعریفشده |
| Quality guardrail | Qualified rate | جلوگیری از Click کمارزش |
| Risk guardrail | خطای لمس، شکایت، Accessibility | مهار آسیب جانبی |
| Segment | Mobile/RTL/New user | فقط اگر از پیش تعریف و توان کافی باشد |
برنامه اندازهگیری و Instrumentation
پیش از تغییر UI، Baseline و تعریف Event را ثابت کنید. Viewport، Density mode و Component version را بدون PII ثبت کنید. Client event را با Backend outcome آشتی دهید و Consent/Privacy را رعایت کنید. Heatmap و Replay فقط با کنترل داده و هدف مشخص استفاده شوند.
برای تغییرهای کوچک، نتیجه آماری ممکن است ارزش هزینه آزمایش را نداشته باشد؛ QA و تست کاربردپذیری کافی است. برای Template پرترافیک یا Checkout پرارزش، آزمایش اثر ارزش بیشتری دارد. معماری سنجش از Event تا Warehouse در راهنمای تحلیل داده بازاریابی تشریح شده است.
بومیسازی برای رابط فارسی و کاربران ایران
فونت فارسی، نیمفاصله، کشیده، اعداد فارسی/لاتین، تومان/ریال، تاریخ جلالی/میلادی و متن دوزبانه طول و Wrap را تغییر میدهند. Design QA را با Lorem ipsum یا نسخه انگلیسی تمام نکنید. روی دستگاههای میانرده، Browserهای واقعی، اینترنت کند و Keyboard موبایل آزمایش کنید.
در قیمت، فاصله دیداری نباید عدد را از واحدش جدا کند. در OTP، شماره تلفن، کد رهگیری و URL از Bidi isolation و ترتیب منطقی استفاده کنید. Skeleton سنگین و Animation غیرضروری روی اتصال کند میتواند فاصله ظاهراً آرام را به تجربه ناپایدار تبدیل کند.
| مورد فارسی | Fixture آزمون | شکست محتمل |
|---|---|---|
| عنوان طولانی | سه خط با نیمفاصله و Bold | Overlap یا فاصله نامتناسب |
| قیمت | ۱۲٬۵۰۰٬۰۰۰ تومان / IRR | جابجایی واحد یا شکست خط |
| تاریخ | ۱۴۰۵/۰۵/۱۸ و ۲۰۲۶-۰۸-۰۹ | ترتیب Bidi مبهم |
| شماره/کد | +۹۸، OTP و UUID | نمایش معکوس یا Copy نادرست |
| خطای فرم | پیام دو/سهخطی واقعی | دورشدن پیام از Field |
| اینترنت کند | Font/Image/Embed دیررس | CLS و Placeholder نادرست |
مثال فرضی: فرم درخواست دموی SaaS ایرانی
فرض کنید فرم موبایل یک نرمافزار حسابداری شش Field دارد. Audit نشان میدهد همه فاصلهها ۱۶px هستند؛ Label و Field بعدی به یک اندازه نزدیکاند، Error زیر Field فضای رزروشده ندارد و دکمه تماس کنار Submit Target کوچکی دارد. نرخ Abandonment بالا مشاهده شده، اما هنوز نمیدانیم Spacing علت است.
بازطراحی سیستم
تیم Tokenهای field-label-gap، field-help-gap، field-stack-gap و section-gap میسازد. فاصله داخل گروه کمتر از فاصله میان گروهها میشود؛ Error در Flow طبیعی میآید؛ Target تماس بزرگتر و از Submit جدا میشود؛ Layout در ۳۲۰ CSS pixel، Zoom، Keyboard باز و پیام سهخطی تست میشود.
آزمایش و تصمیم
در تست کاربردپذیری، تشخیص تعلق Label/Error و اصلاح خطا مشاهده میشود. سپس برای Template پرترافیک A/B test اجرا میشود: Outcome ارسال معتبر، Diagnostic خطای Field و Guardrail کیفیت Lead است. اگر Error کم اما Qualified completion ثابت باشد، تصمیم میتواند حفظ نسخه بهدلیل دسترسپذیری و کاهش اصطکاک باشد؛ اگر Scroll زیاد و Completion افت کند، فاصله Sectionها بازتنظیم میشود.
| قبل | تغییر | شاهد پذیرش |
|---|---|---|
| یک مقدار برای همه رابطهها | Token معنایی بر Group | Hierarchy در اسکن و DOM روشن |
| Error با Position مطلق | Flow طبیعی و ID/description | بدون Overlap در Override |
| Icon کوچک تماس | Target کامل با Label | Touch و Keyboard موفق |
| عدد فرضی Conversion | Baseline و Experiment | Outcome/Guardrail معتبر |
برنامه ۳۰، ۶۰ و ۹۰روزه
| بازه | کار | خروجی | Gate |
|---|---|---|---|
| روز ۱–۳۰ | Inventory، Screenshot matrix، داده و تست اولیه | Spacing map، مشکلهای Severityدار، Baseline | کدام رابطه واقعاً میشکند؟ |
| روز ۳۱–۶۰ | Token، Component state و Prototype | Primitive/Semantic/Component tokens و Fixtures | RTL/Zoom/Focus/Content extremes قبولاند؟ |
| روز ۶۱–۹۰ | Pilot، rollout مرحلهای و Measurement | Version، Decision log و Migration backlog | Scale، Adjust یا Rollback؟ |
مهاجرت را صفحهبهصفحه و با Regression test انجام دهید. تغییر Root token میتواند صدها Component را همزمان خراب کند؛ نسخه، Changelog، Visual regression، Owner و Rollback plan لازم است.
اشتباهات رایج در طراحی فضای سفید
- یکسانگرفتن «زیبایی خلوت» با موفقیت Task یا Conversion.
- استفاده از فاصله و
<br>برای Layout بهجای CSS. - اعمال یک نسبت Line-height به همه Fontها و Componentها.
- فاصله یکسان داخل گروه و میان گروهها؛ در نتیجه Hierarchy نامعلوم.
- تبدیل مقیاس ۸px به قانون و ساخت Exceptionهای بینام در هر صفحه.
- Mirror کردن Physical marginها برای RTL بدون آزمون Bidi و معنی Icon.
- کوچککردن Target و تصور اینکه فضای غیرقابلکلیک اطراف کافی است.
- نادیدهگرفتن Error، Loading، Zoom، متن طولانی و Keyboard موبایل.
- رزرو نکردن ابعاد Media/Embed و ایجاد Layout shift.
- نسبتدادن Bounce، Dwell یا رتبه Google به تغییر Spacing بدون طراحی علّی.
چکلیست تحویل Spacing
- Task، Context، Density، Content extremes، Outcome و Guardrail در Brief ثبت شدهاند.
- Primitive، Semantic و Component tokenها نام، Owner و Version دارند.
- Parent فاصله Children و Component فضای داخلی خود را مالک است.
- نسبت فاصله داخل گروه از فاصله میان گروهها قابلتشخیص است.
- Typography با Font واقعی فارسی، عدد، Bold، Link و متن دوزبانه تست شده است.
dirو Logical propertyها درستاند و Physical exception مستند است.- Default، Hover، Focus، Error، Loading، Empty، Expanded و Disabled بررسی شدهاند.
- Reflow، Text-spacing override، Keyboard/Focus و Target size قبولاند.
- Media و محتوای دیررس فضای پایدار دارند و CLS Field کنترل میشود.
- Usability finding، Experiment و Analytics با محدودیت استنباط گزارش میشوند.
- تغییر با Visual regression، rollout محدود، Changelog و Rollback پوشش دارد.
پرسشهای متداول درباره فضای سفید در طراحی وب
آیا فضای سفید حتماً باید سفیدرنگ باشد؟
خیر. منظور ناحیهای بدون عنصر فعال یا محتوای رقابتکننده است. رنگ، Gradient، بافت یا تصویر آرام میتواند زمینه باشد؛ مهم این است که رابطه، خوانایی و تمرکز را خراب نکند و Contrast لازم حفظ شود.
بهترین مقیاس فاصلهگذاری ۴px است یا ۸px؟
هیچکدام قانون جهانی نیست. مقیاسی کوچک و منسجم انتخاب کنید که با Typography، Brand، Component و Density شما سازگار باشد. ۴/۸px نقطه شروع رایجاند؛ مقادیر خروجی بهتر است با rem، Token معنایی و آزمون Zoom/Responsive مدیریت شوند.
Line-height متن فارسی را چند بگذاریم؟
عدد ثابت عمومی نداریم. Font، اندازه، وزن، طول خط و Context تعیینکنندهاند. برای متن بدنه میتوان از Ratio حدود ۱٫۵ بهعنوان Hypothesis شروع کرد، سپس با Font واقعی و کاربر آزمود. مهمتر اینکه Layout با Overrideهای Text spacing در WCAG ۱.۴.۱۲ نشکند.
آیا فضای سفید بیشتر نرخ تبدیل را بالا میبرد؟
تضمینی نیست. ممکن است Salience و فهم را بهتر کند یا Context را از CTA دور و Scroll را زیاد کند. فرضیه را با Usability test و در صورت توجیه A/B test بسنجید؛ Outcome واقعی و Guardrail کیفیت را جای Click تنها قرار دهید.
فضای سفید چه اثری بر سئو دارد؟
مقدار Spacing سیگنال مستقیم اعلامشده Google نیست. طراحی مناسب میتواند استفاده موبایل، خواندن، تشخیص محتوای اصلی و ثبات Layout را بهتر کند، اما رتبه را تضمین نمیکند. Bounce/Dwell را فاکتور قطعی یا علت رتبه معرفی نکنید.
جمعبندی: فاصله را مثل یک قرارداد رابط مدیریت کنید
فضای سفید، نبودن طراحی نیست؛ تصمیم درباره تعلق، اولویت، ریتم و امکان عمل است. این تصمیم باید از Context و Task شروع شود، با Token به کد برسد، در فارسی/RTL و Stateهای واقعی دوام بیاورد و با Accessibility QA، تست کاربردپذیری و Outcome سنجیده شود.
برای شروع، یک Template پرتکرار را انتخاب کنید. مقادیر پراکنده و رابطههای مبهم را Inventory کنید، Tokenهای Semantic محدود بسازید، Content extremes و Zoom/Focus را تست کنید و Rollout را مرحلهای انجام دهید. اگر تغییر، فقط Screenshot را زیباتر کرده اما Task یا نگهداری سیستم را بهتر نکرده است، هنوز مسئله حل نشده است.
منابع رسمی و راهنماهای مرجع
- W3C: Web Content Accessibility Guidelines 2.2
- W3C WAI: Understanding Text Spacing
- W3C WAI: Understanding Reflow
- W3C WAI: Understanding Target Size (Minimum)
- W3C: CSS Logical Properties and Values
- W3C: CSS Writing Modes و Bidirectionality
- U.S. Web Design System: Spacing unit tokens
- GOV.UK Design System: Responsive و Static spacing
- Google Search Central: Page experience در نتایج جستوجو
- web.dev: بهینهسازی Cumulative Layout Shift
- Google Analytics: Engagement rate و Bounce rate






