Flat، Glassmorphism و Neumorphism؛ انتخاب سطح در طراحی UI

یک کارت پرداخت را می‌توان با سطح تخت، شفافیت شیشه‌ای یا سایه نرم طراحی کرد. اگر اطلاعات مبلغ، دکمه پرداخت و وضعیت خطا در هر سه نسخه یکی باشد، تفاوت اصلی ظاهر سطح است. ولی همین ظاهر می‌تواند روی تشخیص مرز کنترل و خواندن متن اثر بگذارد. انتخاب سبک باید با کاری که کاربر انجام می‌دهد و شرایط نمایش مرتبط باشد؛ نام یک Trend پاسخ آماده‌ای برای طراحی محصول نیست.

این مقاله Flat Design، Glassmorphism و Neumorphism را به‌عنوان سه رویکرد بصری مقایسه می‌کند. ادعای «سبک غالب همه رابط‌ها در سال ۲۰۲۶» بدون داده مشخص قابل دفاع نیست. نمونه‌های محبوب یک پلتفرم هم وضعیت همه وب‌سایت‌ها را نشان نمی‌دهند. برای پروژه خود، بهتر است بدانید هر رویکرد چه وابستگی‌هایی ایجاد می‌کند و چه قواعدی لازم دارد تا کنترل‌ها قابل تشخیص و متن قابل استفاده بماند.

Flat به معنی حذف همه نشانه‌های عمق نیست

در رویکرد Flat، معمولاً سطح‌ها و عناصر با رنگ، فاصله، خط و Typography از هم جدا می‌شوند و تقلید از جنس فیزیکی نقش کمتری دارد. این تعریف به معنی ممنوعیت هر سایه یا الزام به یک ظاهر بسیار ساده نیست. یک کارت تخت می‌تواند سلسله‌مراتب روشن داشته باشد و یک صفحه پر از رنگ تخت هم می‌تواند شلوغ و گیج‌کننده باشد. کیفیت ساختار را از جنس افکت جدا کنید.

برای یک فرم اداری، سطح مات و مرز روشن ممکن است انتخاب مناسبی باشد، چون کاربر چندین فیلد و وضعیت را دنبال می‌کند. اما اگر کنترل‌ها فقط شبیه متن معمولی باشند، Flat بودن هیچ کمکی به تشخیص قابلیت کلیک نمی‌کند. دکمه، لینک، انتخاب فعال و حالت غیرفعال باید قرارداد مشخص داشته باشند. نقش متن و رنگ را در راهنمای تایپوگرافی وب می‌توانید دقیق‌تر دنبال کنید.

Glassmorphism به پشت سطح وابسته است

ظاهر شیشه‌ای معمولاً از ترکیب شفافیت، Blur پس‌زمینه، مرز و گاهی سایه ساخته می‌شود. backdrop-filter روی ناحیه پشت عنصر اثر می‌گذارد؛ با filter که می‌تواند خود عنصر و محتوایش را تغییر دهد یکسان نیست. اگر پس‌زمینه عنصر کاملاً مات باشد، اثر پشت آن دیده نمی‌شود. بنابراین انتخاب Opacity و محتوای پشت سطح بخشی از طراحی است، نه تنظیمی مستقل از صفحه.

این وابستگی در کارت روی تصویر یا نوار شناور دیده می‌شود. وقتی تصویر عوض می‌شود، رنگ و شلوغی پشت نوشته هم تغییر می‌کند. خوانایی را فقط با یک پس‌زمینه آرام در فایل طراحی قضاوت نکنید. می‌توانید سطح متن را مات‌تر کنید یا استفاده از افکت را به محدوده کوچک‌تری محدود کنید. اگر متن مهم باید در همه شرایط دیده شود، سطح قابل پیش‌بینی معمولاً تصمیم ساده‌تری برای نگهداری است.

Neumorphism مرز را با سایه نرم نشان می‌دهد

در ظاهر Neumorphic، سطح عنصر اغلب به رنگ محیط نزدیک است و دو سایه روشن و تیره، حس برجسته یا فرورفته‌بودن می‌سازند. این قرارداد می‌تواند برای جزئیات تزئینی به کار رود. ولی اگر تنها نشانه دکمه همین سایه کم‌رنگ باشد، تشخیص آن در نمایشگر یا شرایط متفاوت دشوار می‌شود. راه‌حل الزاماً حذف کل سبک نیست؛ مرز، نوشته، نشانه انتخاب و Focus را مستقل از افکت طراحی کنید.

box-shadow امکان چند سایه و سایه داخلی را دارد، اما هیچ معنای تعاملی به عنصر اضافه نمی‌کند. یک div با سایه همچنان دکمه معنایی نیست. همچنین سایه نباید جای نشانگر وضعیت انتخاب را بگیرد. کاربر باید بداند کنترل فشار داده شده، انتخاب شده یا فقط تزئینی است. نام سبک نمی‌تواند این قراردادها را برای تیم اجرا تعیین کند.

دسترسی‌پذیری ویژگی خودکار هیچ سبک نیست

Flat را همیشه خواناتر و Neumorphism را همیشه غیرقابل دسترس معرفی نکنید. نتیجه به رنگ‌ها، اندازه، معنا، Markup و رفتار بستگی دارد. معیار Non-text Contrast به اطلاعات بصری لازم برای تشخیص کنترل‌ها و وضعیت‌ها می‌پردازد. این موضوع با کنتراست متن یکسان نیست. ممکن است متن دکمه خوانا باشد، ولی مرز لازم برای تشخیص فیلد یا حالت انتخاب نامشخص بماند.

Focus Visible نیز برای استفاده صفحه‌کلید مهم است. یک سایه Hover برای کاربری که ماوس ندارد کافی نیست. نشانگر Focus را با انیمیشن ظریف یا تفاوت رنگ خیلی کم جایگزین نکنید. وقتی چند کنترل کنار هم هستند، باید معلوم باشد کدام‌یک Focus دارد. در طراحی حالت‌ها، Default، Focus، Hover، Active، Disabled و Error را جدا مشخص کنید؛ هرکدام پیام متفاوتی دارد.

نمونه کامل: تغییر ظاهر یک کارت ثابت

کد زیر را با نام index.html ذخیره کنید و در مرورگر باز کنید. هیچ تصویر، فونت خارجی، Library یا Build لازم نیست. انتخاب‌گر، ظاهر همان کارت را میان سه حالت عوض می‌کند و محتوا ثابت می‌ماند. دکمه فقط پیام محلی نمایش می‌دهد؛ درخواست خرید یا پرداخت ارسال نمی‌شود. این نمونه برای فهم تغییر سطح است و به معنی تأیید کنتراست، عملکرد یا انطباق کامل با استاندارد دسترس‌پذیری نیست.

<!doctype html>
<html lang="fa" dir="rtl">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>مقایسه سطح‌های UI</title>
  <style>
    * { box-sizing: border-box; }
    body { margin: 0; padding: 1.5rem; font: 1rem/1.8 sans-serif; color: #172638;
      background: linear-gradient(120deg, #ccd9ea, #f2e2d5); min-block-size: 100vh; }
    main { max-inline-size: 38rem; margin-inline: auto; }
    .controls { padding: 1rem; background: white; border: 1px solid #65788e; border-radius: .5rem; }
    label { display: block; margin-block: .5rem; }
    select, button { font: inherit; min-block-size: 2.75rem; padding: .5rem .8rem; }
    .card { margin-block: 2rem 1rem; padding: 1.5rem; border: 1px solid #65788e;
      border-radius: 1rem; background: #fff; }
    .card h2 { margin-block-start: 0; }
    .card[data-style="soft"] { background: #e5eaf0;
      box-shadow: 12px 12px 24px #bcc6d2, -12px -12px 24px #fff; }
    button { color: white; background: #164c82; border: 2px solid #164c82; border-radius: .4rem; }
    :is(button, select, input):focus-visible { outline: 3px solid #853400; outline-offset: 4px; }
    @supports (backdrop-filter: blur(12px)) {
      .card[data-style="glass"] { background: rgb(255 255 255 / .82); backdrop-filter: blur(12px); }
    }
    @media (prefers-reduced-transparency: reduce) {
      .card[data-style="glass"] { background: white; backdrop-filter: none; }
    }
    .card.force-solid { background: white; backdrop-filter: none; }
    #status { padding: .5rem; }
  </style>
</head>
<body>
  <main>
    <h1>یک محتوا، سه سطح</h1>
    <div class="controls">
      <label for="style">ظاهر کارت</label>
      <select id="style"><option value="flat">Flat</option><option value="glass">Glass</option>
        <option value="soft">Soft / Neumorphic</option></select>
      <label><input id="solid" type="checkbox"> استفاده از سطح مات</label>
    </div>
    <article class="card" id="card" data-style="flat">
      <h2>بسته بازبینی رابط کاربر</h2>
      <p>محتوا و دکمه این کارت ثابت می‌مانند. انتخاب بالا فقط شکل سطح را تغییر می‌دهد.</p>
      <button id="action" type="button">نمایش پیام نمونه</button>
    </article>
    <p id="status" role="status">هیچ درخواست بیرونی ارسال نمی‌شود.</p>
  </main>
  <script>
    const card = document.getElementById('card');
    const styleSelect = document.getElementById('style');
    const solid = document.getElementById('solid');
    function updateSurface() {
      card.dataset.style = styleSelect.value;
      card.classList.toggle('force-solid', solid.checked);
    }
    styleSelect.addEventListener('change', updateSurface);
    solid.addEventListener('change', updateSurface);
    document.getElementById('action').addEventListener('click', () => {
      document.getElementById('status').textContent = 'پیام محلی نمایش داده شد؛ این نمونه فرم سفارش نیست.';
    });
    updateSurface();
  </script>
</body>
</html>

در نمونه، حالت Glass ابتدا یک سطح مات قابل استفاده دارد. فقط در صورت پشتیبانی CSS مربوط، شفافیت و Blur اضافه می‌شوند. این ترتیب، Fallback را بخشی از حالت پایه می‌کند. حالت Soft نیز مرز و دکمه روشن دارد و تشخیص اقدام به سایه وابسته نیست. با تغییر ظاهر، Label، Tagهای معنایی و عملکرد دکمه تغییر نمی‌کنند. برای محصول واقعی، وضعیت‌های بیشتری مانند خطا و Loading لازم خواهید داشت.

Fallback و ترجیح کاربر را در قرارداد بگذارید

@supports می‌تواند تشخیص دهد مرورگر یک Declaration را می‌پذیرد. این تشخیص تضمین سرعت مناسب یا خوانایی نتیجه نیست. در صورت نبود پشتیبانی، کاربر باید همان اطلاعات و کنترل را دریافت کند. افکت تزئینی نباید باعث شود دکمه یا نوشته حذف شود. تصمیم درباره نسخه بدون افکت را از ابتدا ثبت کنید؛ افزودن آن پس از پایان طراحی معمولاً اختلاف‌های ناخواسته ایجاد می‌کند.

prefers-reduced-transparency برای پاسخ به ترجیح کاهش شفافیت کاربرد دارد، ولی پشتیبانی آن را برای همه محیط‌ها فرض نکنید. نمونه یک انتخاب دستی «سطح مات» هم دارد تا رفتار فقط به Media Feature وابسته نباشد. در محصول، تغییر ترجیح باید روی اطلاعات لازم اثر منفی نگذارد. کاهش شفافیت با کاهش Motion دو نیاز جدا هستند و یکی جای دیگری را پوشش نمی‌دهد.

افکت را با محل استفاده و هزینه آن بسنجید

یک Blur کوچک در نوار ثابت و ده‌ها سطح شفاف بزرگ در یک صفحه، بار بصری و مسیر رندر یکسانی ندارند. هزینه را از نام خاصیت نتیجه نگیرید؛ اندازه ناحیه، تغییر محتوای پشت آن و ترکیب افکت‌ها مهم‌اند. اگر مشکل عملکرد دارید، علت را در سناریوی واقعی پیدا کنید. کم‌کردن Blur ممکن است کمک کند، ولی کندی درخواست داده یا تصویر بزرگ را خودکار اصلاح نمی‌کند.

برای یک صفحه محتوایی، شاید استفاده محدود از Glass در بخش معرفی کافی باشد و بدنه متن سطح ساده‌تری بخواهد. برای یک ابزار، کنترل‌های پرتکرار بهتر است قرارداد پایدار داشته باشند. این پیشنهادها قواعد قطعی نیستند؛ آن‌ها را با نیاز پروژه و بازخورد کاربران مقایسه کنید. در راهنمای Performance Budget می‌توانید بودجه را به سناریوهای مشخص متصل کنید تا افکت‌ها از محدودیت محصول جدا نباشند.

سبک را در Design System به قواعد تبدیل کنید

گفتن «سایت شیشه‌ای باشد» برای اجرا کافی نیست. مشخص کنید کدام سطح‌ها شفاف‌اند، مقدار Opacity در Themeها چگونه تغییر می‌کند، کدام مرز لازم است و متن روی چه پس‌زمینه‌ای قرار می‌گیرد. سایه‌ها و رنگ‌ها را با نام نقش ثبت کنید، نه فقط نام سبک. اگر هر Component تنظیم مستقل داشته باشد، صفحه به‌سرعت ناهمگون می‌شود. راهنمای Design System برای سازمان‌دهی این تصمیم‌ها مرتبط است.

برای انتخاب نهایی، سه نسخه را با محتوای یکسان و حالت‌های یکسان مقایسه کنید. عنوان طولانی، خطا، بزرگ‌نمایی متن و پس‌زمینه متفاوت را در برنامه بررسی قرار دهید. از تیم بخواهید دلیل انتخاب را با نیاز کاربر بیان کند: مثلاً جداسازی یک لایه یا نمایش ساختار کنترل. اگر دلیل فقط محبوبیت یک نام است، هنوز تصمیم محصول روشن نشده. یک ظاهر مشخص زمانی ارزش دارد که اطلاعات و اقدام کاربر را بهتر سازمان دهد.