ژورنال طراحیمیکروکپی در طراحی رابط وب

ژورنال طراحی

میکروکپی در رابط وب؛ نوشتن کلماتی که کاربر را جلو می‌برند

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

متن رابط را بر اساس اقدام بنویسید

در این بخش، فعل و نتیجه را نه به‌عنوان یک تکنیک جدا، بلکه در نسبت با کل تجربه صفحه بررسی می‌کنیم.

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

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

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

ترکیب سه‌بعدی اختصاصی برای توضیح میکروکپی در رابط وب نوشتن کلماتی که کاربر را جلو می‌برند در میانه مقاله
01

این صحنه، رابطه اجزای اصلی در متن رابط و لحن انسانی را به‌صورت یک ساختار واحد نشان می‌دهد.

دکمه باید مقصد را پیش‌بینی‌پذیر کند

در این بخش، CTA را نه به‌عنوان یک تکنیک جدا، بلکه در نسبت با کل تجربه صفحه بررسی می‌کنیم.

در جلسه نقد معمولاً کسی می‌گوید «یک چیزی اینجا کم است». این جمله اغلب به معنای نیاز به عنصر تازه نیست. شاید فاصله، وزن، نام‌گذاری یا ترتیب محتوا نتوانسته رابطه اجزا را توضیح دهد. پیش از افزودن هر چیز، بهتر است همان چیزهای موجود را از نظر نقش، ریتم و رفتار دوباره ببینیم. در موضوع «دکمه باید مقصد را پیش‌بینی‌پذیر کند»، بهتر است از خود CTA شروع کنیم. این زاویه تصمیم را از پسند شخصی جدا می‌کند و به نقشی که باید در تجربه صفحه داشته باشد برمی‌گرداند؛ جایی که می‌توان درباره نتیجه حرف زد، نه فقط درباره زیبا یا نازیبا بودن.

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

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

  • نقش CTA را پیش از شکل آن تعریف کنید
  • نمونه را با محتوای واقعی فارسی بسنجید
  • رفتار موبایل و حالت‌های غیرایده‌آل را جدا ببینید

راهنمای فرم را پیش از خطا مفید کنید

در این بخش، helper text را نه به‌عنوان یک تکنیک جدا، بلکه در نسبت با کل تجربه صفحه بررسی می‌کنیم.

طراحی وب در تصویر ثابت بسیار بخشنده است. همه منابع حاضرند، متن‌ها کامل‌اند و هیچ‌کس با انگشت خیس، اینترنت کند یا نور شدید صفحه را نمی‌بیند. محصول واقعی این‌طور رفتار نمی‌کند. برای همین هر تصمیم بصری باید یک بار در زمان، یک بار در عرض و یک بار در زمینه استفاده واقعی بازبینی شود. در موضوع «راهنمای فرم را پیش از خطا مفید کنید»، بهتر است از خود helper text شروع کنیم. این زاویه تصمیم را از پسند شخصی جدا می‌کند و به نقشی که باید در تجربه صفحه داشته باشد برمی‌گرداند؛ جایی که می‌توان درباره نتیجه حرف زد، نه فقط درباره زیبا یا نازیبا بودن.

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

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

نمای سه‌بعدی دوم از جزئیات اجرایی میکروکپی در رابط وب نوشتن کلماتی که کاربر را جلو می‌برند
02

نمای دوم از فرم کلی فاصله می‌گیرد و روی اتصال تصمیم‌های ریز به تجربه نهایی تمرکز می‌کند.

پیام خطا باید راه اصلاح بدهد

در این بخش، error copy را نه به‌عنوان یک تکنیک جدا، بلکه در نسبت با کل تجربه صفحه بررسی می‌کنیم.

بعضی انتخاب‌ها در ابتدا کوچک‌اند اما در صد صفحه تکثیر می‌شوند. یک اندازه تیتر، یک فاصله اشتباه یا یک الگوی کارت بی‌دلیل، به‌تدریج به لحن کل سایت تبدیل می‌شود. حرفه‌ای‌بودن یعنی همین تصمیم‌های کوچک را پیش از تکثیر ببینیم و برایشان قاعده‌ای روشن بسازیم. در موضوع «پیام خطا باید راه اصلاح بدهد»، بهتر است از خود error copy شروع کنیم. این زاویه تصمیم را از پسند شخصی جدا می‌کند و به نقشی که باید در تجربه صفحه داشته باشد برمی‌گرداند؛ جایی که می‌توان درباره نتیجه حرف زد، نه فقط درباره زیبا یا نازیبا بودن.

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

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

  • نقش error copy را پیش از شکل آن تعریف کنید
  • نمونه را با محتوای واقعی فارسی بسنجید
  • رفتار موبایل و حالت‌های غیرایده‌آل را جدا ببینید

لحن انسانی با شوخی اجباری فرق دارد

در این بخش، voice و tone را نه به‌عنوان یک تکنیک جدا، بلکه در نسبت با کل تجربه صفحه بررسی می‌کنیم.

بیایید این بخش را با یک صحنه آشنا شروع کنیم. صفحه روی مانیتور کامل به نظر می‌رسد، اما وقتی نگاه از بالا تا پایین حرکت می‌کند، معلوم نیست کدام تصمیم واقعاً مهم‌تر است. در چنین لحظه‌ای مشکل کمبود زیبایی نیست؛ مشکل این است که طراحی هنوز ترتیب دیدن و فهمیدن را مشخص نکرده. راه‌حل از افزودن یک افکت تازه نمی‌آید، از روشن‌کردن مسئولیت هر لایه می‌آید. در موضوع «لحن انسانی با شوخی اجباری فرق دارد»، بهتر است از خود voice و tone شروع کنیم. این زاویه تصمیم را از پسند شخصی جدا می‌کند و به نقشی که باید در تجربه صفحه داشته باشد برمی‌گرداند؛ جایی که می‌توان درباره نتیجه حرف زد، نه فقط درباره زیبا یا نازیبا بودن.

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

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

برچسب منو را با زبان مخاطب انتخاب کنید

در این بخش، navigation labels را نه به‌عنوان یک تکنیک جدا، بلکه در نسبت با کل تجربه صفحه بررسی می‌کنیم.

در جلسه نقد معمولاً کسی می‌گوید «یک چیزی اینجا کم است». این جمله اغلب به معنای نیاز به عنصر تازه نیست. شاید فاصله، وزن، نام‌گذاری یا ترتیب محتوا نتوانسته رابطه اجزا را توضیح دهد. پیش از افزودن هر چیز، بهتر است همان چیزهای موجود را از نظر نقش، ریتم و رفتار دوباره ببینیم. در موضوع «برچسب منو را با زبان مخاطب انتخاب کنید»، بهتر است از خود navigation labels شروع کنیم. این زاویه تصمیم را از پسند شخصی جدا می‌کند و به نقشی که باید در تجربه صفحه داشته باشد برمی‌گرداند؛ جایی که می‌توان درباره نتیجه حرف زد، نه فقط درباره زیبا یا نازیبا بودن.

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

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

  • نقش navigation labels را پیش از شکل آن تعریف کنید
  • نمونه را با محتوای واقعی فارسی بسنجید
  • رفتار موبایل و حالت‌های غیرایده‌آل را جدا ببینید

empty state را به بن‌بست تبدیل نکنید

در این بخش، حالت خالی را نه به‌عنوان یک تکنیک جدا، بلکه در نسبت با کل تجربه صفحه بررسی می‌کنیم.

طراحی وب در تصویر ثابت بسیار بخشنده است. همه منابع حاضرند، متن‌ها کامل‌اند و هیچ‌کس با انگشت خیس، اینترنت کند یا نور شدید صفحه را نمی‌بیند. محصول واقعی این‌طور رفتار نمی‌کند. برای همین هر تصمیم بصری باید یک بار در زمان، یک بار در عرض و یک بار در زمینه استفاده واقعی بازبینی شود. در موضوع «empty state را به بن‌بست تبدیل نکنید»، بهتر است از خود حالت خالی شروع کنیم. این زاویه تصمیم را از پسند شخصی جدا می‌کند و به نقشی که باید در تجربه صفحه داشته باشد برمی‌گرداند؛ جایی که می‌توان درباره نتیجه حرف زد، نه فقط درباره زیبا یا نازیبا بودن.

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

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

متن را کنار رفتار واقعی تست کنید

در این بخش، prototype و اصلاح را نه به‌عنوان یک تکنیک جدا، بلکه در نسبت با کل تجربه صفحه بررسی می‌کنیم.

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

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

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

  • نقش prototype و اصلاح را پیش از شکل آن تعریف کنید
  • نمونه را با محتوای واقعی فارسی بسنجید
  • رفتار موبایل و حالت‌های غیرایده‌آل را جدا ببینید

قدم بعدی

برای پروژه شما، از پرسش‌های درست شروع کنیم.

شرح کوتاهی از وضعیت، هدف و محدودیت‌ها بفرستید تا مسیر مناسب را روشن کنیم.