Resizing | تغییر اندازه
تعریف دقیق
تغییر اندازه (resizing) در طراحی رابط، مجموعه رفتارهایی است که UI هنگام تغییر فضای available adapt می‌کند: از drag کردن لبه پنجره desktop تا rotation موبایل و split-screen. شامل resize handle در panel، fluid typography، و min/max width component.
در design tool، auto-layout و constraints نحوه resize در dev را پیش‌بینی می‌کند. در CSS، flex، grid، clamp و container queries ابزار resizing مدرن‌اند.
تعریف عملی: هر component باید spec داشته باشد «از عرض A تا B چگونه رفتار می‌کند».
چرا مهم است
کاربران همه viewport یکسان ندارند؛ ignore resize accessibility و power user را اذیت می‌کند. B2B dashboard اغلب در monitor wide و laptop narrow استفاده می‌شود.
چگونه کار می‌کند
design: min/max، breakpoint، stack order. dev: relative units، overflow rules، resize observer در JS در صورت نیاز.
test: manual resize، device lab، visual regression در widths کلیدی.
اجزا و انواع
layout resize، text wrap، image، table، split pane، textarea user-resizable.
کاربرد در محصول و UX
sidebar collapsible در عرض کم. chart reflow legend. form دو ستونه → یک ستون.
RTL: resize نباید mirroring logic را بشکند.
مثال‌های عملی
panel قابل drag در analytics. بد: modal wider than viewport بدون scroll.
اشتباهات رایج
فقط طراحی mobile و desktop بدون between. vw font بدون cap. disable user zoom.
نکات پیاده‌سازی
breakpoint token در design system. storybook viewport addon. document resize در component spec.
ارتباط با مفاهیم مرتبط
با responsive design، fluid layout، breakpoints، و responsive grids مرتبط است.
جمع‌بندی کاربردی
تغییر اندازه part of respectful UI است. constrain، test و specify رفتار در تمام widths رایج.
نگاه از داخل تیم محصول
در عمل، این مفهوم وقتی به درد می‌خورد که تیم بتواند آن را به یک تصمیم مشخص وصل کند، نه فقط در اسلاید تعریف کند. یک تمرین ساده این است: سه سناریوی واقعی از محصول خودتان بنویسید و بپرسید اگر این ایده را جدی بگیریم، چه چیزی در طراحی، بک‌لاگ یا فرآیند عوض می‌شود؟ اگر جواب «هیچ» بود، یا هنوز درست فهمیده نشده، یا الان اولویتش نیست. وقتی جواب روشن است، می‌توانید معیار پذیرش کوتاه بنویسید: چه رفتاری باید بهتر شود، چه ریسکی باید کم شود، یا چه سوءبرداشتی باید بسته شود. این کار زبان مشترک بین طراحی، محصول و مهندسی می‌سازد و جلوی بحث‌های تکراری «به نظرم» را می‌گیرد.
برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.
چطور در جلسه تصمیم بگیریم
در عمل، این مفهوم وقتی به درد می‌خورد که تیم بتواند آن را به یک تصمیم مشخص وصل کند، نه فقط در اسلاید تعریف کند. یک تمرین ساده این است: سه سناریوی واقعی از محصول خودتان بنویسید و بپرسید اگر این ایده را جدی بگیریم، چه چیزی در طراحی، بک‌لاگ یا فرآیند عوض می‌شود؟ اگر جواب «هیچ» بود، یا هنوز درست فهمیده نشده، یا الان اولویتش نیست. وقتی جواب روشن است، می‌توانید معیار پذیرش کوتاه بنویسید: چه رفتاری باید بهتر شود، چه ریسکی باید کم شود، یا چه سوءبرداشتی باید بسته شود. این کار زبان مشترک بین طراحی، محصول و مهندسی می‌سازد و جلوی بحث‌های تکراری «به نظرم» را می‌گیرد.
برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.
بعد از انتشار چه ببینیم
در عمل، این مفهوم وقتی به درد می‌خورد که تیم بتواند آن را به یک تصمیم مشخص وصل کند، نه فقط در اسلاید تعریف کند. یک تمرین ساده این است: سه سناریوی واقعی از محصول خودتان بنویسید و بپرسید اگر این ایده را جدی بگیریم، چه چیزی در طراحی، بک‌لاگ یا فرآیند عوض می‌شود؟ اگر جواب «هیچ» بود، یا هنوز درست فهمیده نشده، یا الان اولویتش نیست. وقتی جواب روشن است، می‌توانید معیار پذیرش کوتاه بنویسید: چه رفتاری باید بهتر شود، چه ریسکی باید کم شود، یا چه سوءبرداشتی باید بسته شود. این کار زبان مشترک بین طراحی، محصول و مهندسی می‌سازد و جلوی بحث‌های تکراری «به نظرم» را می‌گیرد.
برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.
وقتی کاربر واقعی وارد می‌شود
در عمل، این مفهوم وقتی به درد می‌خورد که تیم بتواند آن را به یک تصمیم مشخص وصل کند، نه فقط در اسلاید تعریف کند. یک تمرین ساده این است: سه سناریوی واقعی از محصول خودتان بنویسید و بپرسید اگر این ایده را جدی بگیریم، چه چیزی در طراحی، بک‌لاگ یا فرآیند عوض می‌شود؟ اگر جواب «هیچ» بود، یا هنوز درست فهمیده نشده، یا الان اولویتش نیست. وقتی جواب روشن است، می‌توانید معیار پذیرش کوتاه بنویسید: چه رفتاری باید بهتر شود، چه ریسکی باید کم شود، یا چه سوءبرداشتی باید بسته شود. این کار زبان مشترک بین طراحی، محصول و مهندسی می‌سازد و جلوی بحث‌های تکراری «به نظرم» را می‌گیرد.
برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.
نگاه از داخل تیم محصول
در عمل، این مفهوم وقتی به درد می‌خورد که تیم بتواند آن را به یک تصمیم مشخص وصل کند، نه فقط در اسلاید تعریف کند. یک تمرین ساده این است: سه سناریوی واقعی از محصول خودتان بنویسید و بپرسید اگر این ایده را جدی بگیریم، چه چیزی در طراحی، بک‌لاگ یا فرآیند عوض می‌شود؟ اگر جواب «هیچ» بود، یا هنوز درست فهمیده نشده، یا الان اولویتش نیست. وقتی جواب روشن است، می‌توانید معیار پذیرش کوتاه بنویسید: چه رفتاری باید بهتر شود، چه ریسکی باید کم شود، یا چه سوءبرداشتی باید بسته شود. این کار زبان مشترک بین طراحی، محصول و مهندسی می‌سازد و جلوی بحث‌های تکراری «به نظرم» را می‌گیرد.
برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.
سوالات متداول
رفتار عناصر و layout وقتی viewport، پنجره، یا container کاربر بزرگ و کوچک می‌شود—شامل reflow، scale، truncate و حفظ usable touch target.
responsive استرategie کلی breakpoint است؛ resizing رفتار لحظه‌ای و component-level در fluid layout را پوشش می‌دهد.
محتوا نباید clip شود؛ horizontal scroll اجتناب؛ modal و table باید در عرض کم still usable باشند.
srcset، aspect-ratio، object-fit، و art direction برای crop در breakpoint مختلف—نه stretch بی‌کیفیت.
fixed width در rem نادرست؛ متن زیر target لمسی ۴۴px؛ جدول بدون scroll یا stack در موبایل.