چند تصویر خوش‌رنگ از طراح تحویل گرفته‌اید، اما هنوز نمی‌دانید خطای فرم، نسخه موبایل و پایان مسیر خرید چطور ساخته می‌شوند. همین‌جاست که پرسش «طراحی رابط کاربری چیست» برای مدیر کسب‌وکار جدی میشود. جواب کوتاهش این است: طراحی رابط کاربری یعنی تعیین شکل و رفتار هر بخشی از محصول که کاربر با آن کار میکند. خروجی‌اش مجموعه‌ای از تصمیم‌های قابل اجراست، نه چند تصویر.
- UI/UX را با مسیر قابل استفاده و خروجی قابل پذیرش بسنجید، نه فقط زیبایی صفحه‌ها.
- پیش از طرح بصری، مسئله، کاربران و مسیرهای ضروری را روشن کنید.
- حالت‌های خطا، انتظار و نمایش موبایل بخشی از دامنه طراحی‌اند.
- تأیید نمونه تعاملی به معنی تأیید عملکرد محصول ساخته‌شده نیست.
- هزینه را بر اساس پیچیدگی مسیرها و عمق کار مقایسه کنید، نه صرفاً تعداد صفحه‌ها.
طراحی رابط کاربری چیست و چه خروجی‌هایی پیش از کدنویسی دارد؟
به زبان ساده، طراح شکل و رفتار بخشهایی از محصول را مشخص میکند که کاربر با آن‌ها سروکار دارد؛ دکمه‌ها، فرم‌ها و صفحه‌ها. پیش از کدنویسی، تیم طراحی بسته به دامنه پروژه ساختار صفحات، مسیرهای کاربر، طرح اولیه، نمونه تعاملی و طرح نهایی را آماده میکند. مشخصات اجزا و حالت‌های مختلفشان را هم برای توسعهدهنده می‌نویسد.
اگر بخواهیم ساده بگوییم رابط کاربری چیست: هر جایی که کاربر و محصول با هم روبه‌رو می‌شوند. صفحه ورود، فهرست کالا، پیام «پرداخت ناموفق بود» و دکمه‌ای که منتظر جواب سرور می‌ماند، همه رابط کاربری‌اند. به همین دلیل طراحی آن به انتخاب رنگ و فونت خلاصه نمی‌شود. طرح خوب به کاربر می‌گوید قدم بعدی چیست و بعد از کلیک چه اتفاقی می‌افتد.
برای مثال، دکمه‌ای با برچسب «ادامه» چیزی درباره نتیجه نمی‌گوید. «پرداخت و ثبت سفارش» همان دکمه است، اما کاربر می‌داند با کلیکش پولی جابه‌جا میشود. پس وقتی می‌پرسید طراحی رابط کاربری چیست، در واقع می‌پرسید کدام تصمیم‌ها باید پیش از ساخت روشن شوند.
خروجیهای رایج پیش از کدنویسی این‌هاست:
ساختار صفحات: فهرست صفحه‌ها و رابطه‌شان با هم، مثل نقشه یک ساختمان.
مسیرهای کاربر: ترتیب قدم‌هایی که کاربر برای رسیدن به یک هدف برمی‌دارد.
طرح اولیه (وایرفریم): چیدمان ساده صفحه بدون رنگ و جزئیات.
نمونه تعاملی (پروتوتایپ): صفحه‌های به‌هم‌وصلی که میشود رویشان کلیک کرد.
طرح نهایی: ظاهر کامل صفحه‌ها با رنگ، تایپوگرافی و تصویر.
مشخصات اجزا و حالت‌ها: رفتار هر دکمه و فرم در حالت عادی، خطا، انتظار و غیرفعال.
با این حال، این فهرست منوی ثابت نیست؛ قرارداد است. جواب دقیق اینکه طراحی رابط کاربری چیست، در هر پروژه کمی فرق میکند. صفحه معرفی یک محصول تازه شاید به پژوهش عمیق و مستندسازی کامل اجزا نیاز نداشته باشد. اما سامانه سفارش‌گیری با چند نقش کاربری، بدون مسیرهای دقیق و حالت‌های خطا عملاً ساختنی نیست. پیش از امضای قرارداد بپرسید دقیقاً کدام‌یک از این خروجی‌ها را تحویل می‌گیرید.
رابط کاربری و تجربه کاربری چه تفاوتی دارند؟
خلاصه‌اش این است: رابط کاربری (UI) با ظاهر و رفتار عناصری سروکار دارد که کاربر می‌بیند و لمس میکند. تجربه کاربری (UX) کل تجربه او در مسیر رسیدن به هدفش است. این دو از هم جدا نیستند و در عمل هم‌پوشانی زیادی دارند؛ به همین دلیل هر کس بپرسد طراحی رابط کاربری چیست، دیر یا زود به تجربه کاربری هم می‌رسد.
جواب «طراحی تجربه کاربری چیست» با یک خرید فرضی روشن‌تر میشود. کاربر باید کالایش را پیدا کند، هزینه نهایی را پیش از پرداخت بفهمد و اگر اشتباه کرد، راحت برگردد. این‌ها پرسش‌های تجربه کاربری‌اند. اما اینکه فرم سفارش چه شکلی دارد و پیام خطا کجا و با چه لحنی می‌آید، بیشتر به رابط کاربری برمی‌گردد.
پرسش | بیشتر به UX مربوط است | بیشتر به UI مربوط است |
|---|---|---|
کاربر کالا را پیدا میکند؟ | دسته‌بندی، جست‌وجو و ترتیب مراحل | ظاهر فیلترها و فهرست نتایج |
هزینه نهایی روشن است؟ | زمان و جای اعلام هزینه | شیوه نمایش مبلغ و توضیح کنار آن |
اشتباه قابل جبران است؟ | امکان بازگشت بدون از دست رفتن داده | متن، رنگ و جای پیام خطا |
پس اگر کسی پرسید طراحی ui ux چیست، جواب طبیعی این است: طراحی مشترک ساختار تعامل و نمایش آن. معمولاً یک تیم هر دو را با هم پیش میبرد، چون تصمیم درباره ترتیب مراحل بدون دیدن صفحه ناقص می‌ماند. فروختن این دو در قالب دو بسته کاملاً مستقل اغلب بین منطق و ظاهر شکاف می‌اندازد.
یک قاعده ساده برای تصمیم: اگر کاربر نمی‌فهمد قدم بعدی کجاست، تغییر رنگ دکمه چیزی را حل نمی‌کند و مسیر باید بازبینی شود. اما اگر مسیر منطقی است و فقط دکمه‌ها دیده نمی‌شوند یا متن‌ها ناخواناست، اصلاح رابط شاید کافی باشد. در جلسه‌های اول معمولاً همین را می‌پرسم، چون نشان می‌دهد پاسخ اینکه طراحی رابط کاربری چیست در آن پروژه بیشتر به مسیر برمی‌گردد یا به ظاهر.
همچنین تجربه کاربر فقط داخل صفحه اتفاق نمی‌افتد. پیامک تأیید سفارش، تماس با پشتیبانی و حتی بسته‌بندی هم بخشی از آن‌اند. برای دیدن این نقاط، مطلب تحلیل سفر مشتری و نقاط تماس با کسب‌وکار نقطه شروع خوبی است.
اصول طراحی رابط کاربری خوب کدام‌اند؟
سه اصل پایه بیشترین اثر را دارند: وضوح، سازگاری و دسترس‌پذیری. اصول طراحی رابط کاربری بیشتر از این‌هاست، اما اگر این سه رعایت نشوند، بقیه هم نتیجه نمی‌دهند. اگر بخواهید در یک کلمه بگویم طراحی رابط کاربری چیست، می‌گویم «روشنی».
وضوح یعنی هر صفحه یک اقدام اصلی مشخص داشته باشد. وقتی سه دکمه هم‌وزن کنار هم نشسته‌اند، کاربر باید حدس بزند کدام مهم‌تر است. برچسب دکمه هم باید نتیجه کلیک را بگوید، نه فعلی کلی مثل «ثبت».
سازگاری یعنی کنترل‌های مشابه همه‌جا یک‌جور رفتار کنند. اگر دکمه حذف در یک صفحه قرمز است و پیش از حذف تأیید می‌گیرد، در صفحه دیگر هم باید همین‌طور باشد. تفاوت ظاهری باید معنای واقعی داشته باشد؛ وگرنه کاربر را به اشتباه می‌اندازد.
دسترس‌پذیری یعنی افراد با توانایی‌ها و ابزارهای مختلف بتوانند از محصول استفاده کنند. منظور فقط افراد نابینا نیست؛ کسی که با صفحه‌کلید کار میکند یا گوشی قدیمی‌اش را زیر آفتاب گرفته هم جزو همین گروه است. حداقل‌هایی که من همیشه بررسی می‌کنم:
متن با اندازه و کنتراست خوانا
امکان انجام کارهای اصلی فقط با صفحه‌کلید
نشانگر تمرکز (Focus) قابل مشاهده روی عنصر فعال
پیام خطایی که فقط به رنگ قرمز متکی نیست و متن روشن دارد
مرجع اصلی این حوزه راهنمای استانداردهای دسترس‌پذیری محتوای وب است که معیارها را سطح‌بندی کرده است.
برای نمونه، فرم نشانی را در نظر بگیرید. اگر عنوان فیلد فقط متن کم‌رنگی داخل خود فیلد باشد، با شروع تایپ محو میشود. در نتیجه کاربر وسط نوشتن یادش می‌رود این فیلد چه می‌خواست. برچسب ثابت بالای فیلد و پیامی مثل «کد پستی باید ۱۰ رقم باشد» خیلی قابل‌اتکاتر است. همین مثال کوچک نشان می‌دهد طراحی رابط کاربری چیست: تصمیم درباره رفتار، نه فقط ظاهر.
یک نکته مهم برای پذیرش کار: با دیدن تصویر طرح نمی‌توانید رفتار صفحه‌کلید یا صفحه‌خوان را تأیید کنید. تأیید طرح یعنی نیت درست است؛ اما دسترس‌پذیری واقعی را باید روی نسخه ساخته‌شده آزمود. اگر محصولتان اپلیکیشن است، اصول طراحی رابط و تجربه کاربری اپلیکیشن جزئیات بیشتری برای صفحه‌های لمسی دارد.
پیش از طراحی، مسئله کسب‌وکار چگونه تعریف میشود؟
مسئله را با تبدیل یک خواسته کلی به موقعیتی قابل مشاهده تعریف کنید. «سایت مدرن‌تر شود» مسئله نیست؛ سلیقه است. اما «خیلی از کاربران سبد را پر می‌کنند و سفارش را تمام نمی‌کنند» را میشود بررسی کرد. در واقع خیلی از مدیرانی که می‌پرسند طراحی رابط کاربری چیست، دنبال حل همین نوع مشکل فروش یا پشتیبانی‌اند.
با این حال، مراقب یک دام باشید. ناتمام ماندن سفارش هنوز نمی‌گوید مقصر طراحی است. شاید هزینه ارسال بالاست، درگاه پرداخت قطع میشود یا موجودی کالا درست نمایش داده نمی‌شود. پیش از بررسی، علت را گردن ظاهر صفحه نیندازید.
معمولاً اولین چیزی که از کارفرما می‌خواهم، یک جمله با این چهار جزء است:
چه کسی: مثلاً خریدار مهمانی که بار اول خرید میکند
در چه موقعیتی: با گوشی، در مسیر رفت‌وآمد
برای چه کاری: سفارش یک کالا برای نشانی شهرستان
با چه مانعی: تا آخر مسیر هزینه ارسال را نمی‌داند
بعد اطلاعات را در چهار دسته جدا بنویسید: هدف کسب‌وکار، نیاز کاربر، محدودیت فنی و فرضیه. قاطی شدن این‌ها دلیل رایج جلسه‌های طولانی و بی‌نتیجه است. فرضیه هنوز ثابت نشده، پس نباید کنار واقعیت‌ها بنشیند.
سپس معیار پایه را تعیین کنید؛ یعنی وضع فعلی را با چه می‌سنجید و تغییر را بعداً چطور می‌بینید. موفقیت در انجام کار، تعداد خطاها و جاهایی که کاربر گیر میکند معیارهای بهتری از «طرح را دوست داشتند» هستند. از این زاویه، طراحی رابط کاربری چیست؟ تغییری که بشود اندازه‌اش گرفت.
یک سؤال کلیدی هم از مجری بپرسید: «کدام فرض‌ها را پیش از طراحی بررسی می‌کنید و کدام‌ها را فعلاً با ریسک می‌پذیرید؟» تیم باتجربه برای این سؤال جواب مشخص دارد و هر دو گروه را نام میبرد.
کاربران و مسیرهای اصلی محصول چگونه شناخته می‌شوند؟
شناخت کاربر از شواهد رفتاری می‌آید، نه از توصیف خیالی. گفت‌وگو درباره آخرین باری که کاری را انجام داده‌اند، مشاهده کار واقعی‌شان و خواندن درخواست‌های پشتیبانی سه منبع ارزان و مفیدند. پرسونای «خانم ۳۵ ساله علاقه‌مند به خرید آنلاین» بدون این شواهد فقط حدس است.
مسیر کاربر یعنی توالی اقدام‌هایی که کسی برای رسیدن به یک هدف انجام می‌دهد. همه مسیرها هم‌وزن نیستند؛ بنابراین مسیر اصلی را با سه معیار انتخاب کنید: اهمیت برای کسب‌وکار، فراوانی تکرار و پیامد شکست.
همچنین نقشها را از هم جدا کنید. در یک سامانه خرید سازمانی، کسی که درخواست خرید ثبت میکند با مدیری که آن را تأیید میکند فرق دارد. هر نقش ممکن است دسترسی، صفحه‌ها و حتی دستگاه متفاوتی داشته باشد. یکی‌کردن آن‌ها به صفحه‌های شلوغ و گیج‌کننده می‌رسد.
مسیر موفق فقط نیمی از کار است و بخش زیادی از اینکه طراحی رابط کاربری چیست، در نیمه دیگر معنا پیدا میکند. برای هر مسیر اصلی این حالت‌ها را هم بنویسید:
قطع شدن اینترنت وسط کار
جست‌وجویی که هیچ نتیجه‌ای ندارد
بازگشت به مرحله قبل و سرنوشت داده‌های واردشده
نبود دسترسی کافی برای یک نقش
قاعده دامنه من ساده است: اول مسیرهای ضروری را با همه حالت‌هایشان کامل کنید. صفحه «درباره ما» یا تنظیمات کم‌استفاده می‌تواند بعداً بیاید. اما برعکسش، یعنی ده صفحه زیبا و یک مسیر خرید نیمه‌کاره، هزینه بیشتری روی دستتان می‌گذارد.
یک نمونه آموزشی فارسی از مسئله تا طرح نهایی
این نمونه فرضی و آموزشی است و پروژه واقعی هیچ مشتری نیاسا نیست. فرض کنید فروشگاهی فارسی با ۲۰۰ کالا دارید که خرید مهمان، یعنی خرید بدون ثبت‌نام، هم دارد. این مثال نشان می‌دهد طراحی رابط کاربری چیست وقتی از تعریف به عمل می‌رسد.
فرضیه اولیه این است: کاربران تا مرحله آخر هزینه ارسال را نمی‌دانند و به همین دلیل سفارش را رها می‌کنند. این فرضیه است، نه نتیجه. برای بررسی‌اش، تیم چند سفارش آزمایشی را با چند کاربر تماشا میکند و می‌پرسد کجا مردد شدند.
مسیر اصلی چهار قدم دارد:
انتخاب کالا و افزودن به سبد
ورود نشانی و انتخاب روش ارسال
دیدن هزینه نهایی همراه با ارسال
ثبت سفارش و پرداخت
اینجا پرسشی فنی پیش می‌آید که طراح به‌تنهایی جوابش را ندارد: هزینه ارسال از چه لحظه‌ای قابل محاسبه است؟ اگر به شهر و وزن بستگی دارد، پیش از انتخاب شهر عدد دقیقی وجود ندارد. پس طراح این محدودیت را از تیم فنی می‌پرسد. به نظر من همین گفت‌وگوی کوتاه بخش مهمی از جواب این است که طراحی رابط کاربری چیست.
بنابراین تغییر پیشنهادی دو بخش دارد. اول، فروشگاه هزینه ارسال را در اولین نقطه قابل محاسبه نشان دهد؛ مثلاً بلافاصله بعد از انتخاب شهر. دوم، پیش از آن، جمله‌ای مثل «هزینه ارسال پس از انتخاب شهر مشخص میشود» در سبد خرید بیاید.
سپس تیم از ساختار اولیه شروع میکند، به نمونه تعاملی می‌رسد و بعد طرح نهایی را می‌سازد. معیار پذیرش روشن است: کاربر آزمون بدون راهنمایی، هزینه نهایی را پیش از پرداخت بفهمد و مسیر را کامل کند. این معیار ادعای افزایش فروش ندارد. افزایش فروش را فقط بعد از اجرا و با داده واقعی میشود سنجید.
تصویر زیبا فقط وعده می‌دهد؛ مسیرها و حالت‌های خطا آن وعده را ساختنی می‌کنند.
فروشگاه این راهنما یک مثال فرضی برای توضیح تصمیم‌های طراحی است. تغییرهای پیشنهادی آن نتیجه اندازه‌گیری‌شده یا تضمین افزایش فروش ندارند.
معماری اطلاعات و وایرفریم چه چیزی را روشن می‌کنند؟
این دو مشخص می‌کنند محتوا کجا می‌نشیند و کاربر چطور به آن می‌رسد، پیش از آنکه ظاهر صفحه حواس را پرت کند. معماری اطلاعات یعنی شیوه دسته‌بندی، نام‌گذاری و پیدا کردن محتوا. وایرفریم (Wireframe) طرح ساده ساختار صفحه است، بدون رنگ، عکس و جزئیات بصری.
در همان فروشگاه فرضی، دو سؤال باید پیش از انتخاب رنگ جواب بگیرد. کالاها با چه منطقی دسته‌بندی شوند تا مشتری آن‌ها را با نام آشنای خودش پیدا کند؟ خلاصه هزینه سفارش در صفحه پرداخت کجا بنشیند؟ اگر این‌ها در وایرفریم حل نشوند، در طرح نهایی با هزینه بیشتری حل می‌شوند. به همین دلیل وقتی کسی از من می‌پرسد طراحی رابط کاربری چیست، اول از اسکلت حرف می‌زنم، نه از رنگ.
برای تأیید ساختار، این سه معیار را بسنجید:
کاربر اطلاعات لازم برای هر تصمیم را در همان صفحه می‌یابد.
ترتیب تصمیم‌ها منطقی است؛ مثلاً روش ارسال پیش از پرداخت می‌آید.
هیچ اقدام لازمی جا نیفتاده، مثل ویرایش سبد یا تغییر نشانی.
نکته‌ای که در پروژه‌های فارسی زیاد جا می‌ماند، متن واقعی است. وایرفریم با متن ساختگی یا عنوان‌های دوکلمه‌ای همیشه مرتب به نظر می‌رسد. اما عنوان یک کالای فارسی با نام مدل و ظرفیت ممکن است سه خط شود و کارت محصول را به هم بریزد. از همان ابتدا متن واقعی یا نزدیک به واقعیت بخواهید.
اشتباه رایج این است که وایرفریم تأییدشده را طرح نهایی بدانید. هنوز تصمیم‌های زیادی باز مانده‌اند: تایپوگرافی، رنگ، فاصله‌ها، تصویرها، حالت‌های خطا و رفتار در اندازه‌های مختلف. پس تأیید وایرفریم یعنی «اسکلت درست است»، نه «کار تمام است».
پروتوتایپ چه چیزی را پیش از ساخت آزمایش میکند؟
نمونه تعاملی رفتار مسیر را پیش از خرج برنامهنویسی آزمایش میکند. پروتوتایپ (Prototype)، یعنی همین نمونه تعاملی، مجموعه صفحه‌های به‌هم‌وصلی است که بخشی از مسیر کاربر را شبیهسازی میکند. لزوماً داده واقعی یا منطق کامل پشتش نیست.
برای مسیر سفارش فرضی، صفحه‌های سبد، نشانی، خلاصه هزینه و تأیید را به هم وصل کنید. چند حالت منتخب خطا را هم بیفزایید، مثل کد پستی نامعتبر یا ناموجود شدن کالا. همین حالت‌ها معمولاً ابهام‌هایی را رو می‌کنند که در تصویر ثابت پنهان می‌مانند؛ و دقیقاً اینجاست که معلوم میشود طراحی رابط کاربری چیست و چرا با چند تصویر تمام نمی‌شود.
عمق نمونه را بر اساس سؤالتان انتخاب کنید. اگر می‌خواهید ببینید ترتیب مراحل منطقی است، وایرفریم‌های سیاه‌وسفیدِ به‌هم‌وصل کافی است. اما اگر می‌خواهید بدانید کاربر پیام هزینه ارسال را می‌بیند یا نه، رنگ، اندازه و جای دقیق آن مهم میشود.
در واقع پروتوتایپ بعضی چیزها را اصلاً نمی‌تواند ثابت کند. این موارد خارج از اعتبار آزمون‌اند:
سرعت واقعی بارگذاری صفحه‌ها
امنیت پرداخت و رفتار درگاه بانکی
اتصال به انبار و موجودی لحظه‌ای
صحت محاسبه مالیات، تخفیف و هزینه ارسال
پیش از جلسه تأیید، از تیم طراحی بخواهید فهرستی بدهد: کدام مسیرها کلیک‌پذیرند و کدام بخش‌ها فقط نمایشی‌اند. بدون این فهرست، کارفرما روی دکمه‌ای کلیک میکند که کار نمی‌کند و جلسه به بحث درباره «خرابی» می‌گذرد.
دیزاین سیستم در چه مقیاسی به کار شما می‌آید؟
جواب کوتاه: وقتی چند صفحه، چند محصول یا چند نفر با اجزای مشترک کار می‌کنند. دیزاین سیستم (Design System) مجموعه اجزای تکرارشونده، قواعد استفاده از آن‌ها و تصمیم‌های مشترک طراحی است. یک فایل رنگ و فونت به‌تنهایی دیزاین سیستم نیست.
واحد اصلی آن جزء یا کامپوننت است؛ عنصری قابل استفاده دوباره مثل دکمه، فیلد متن یا کارت محصول. هر جزء باید حالت‌هایش را داشته باشد: فعال، غیرفعال، در حال انتظار و خطا. مثلاً دکمه «پرداخت» که بعد از کلیک هیچ نشانه‌ای از انتظار ندارد، کاربر را به کلیک دوباره وادار میکند.
به همین دلیل مقیاس مهم است. برای فروشگاه کوچک یا وبسایت معرفی، کتابخانه سبکی از اجزای پرتکرار کافی است. اما اگر چند محصول دارید یا چند تیم هم‌زمان کار می‌کنند، به قواعد مستند، نسخه‌بندی و نگهداری منظم نیاز دارید.
از نگاه من، که بیشتر وقتم با دیزاین سیستم می‌گذرد، بخش سخت ساختن اجزا نیست؛ نگه‌داشتن آن‌هاست. این سه مورد را از ابتدا روشن کنید:
چه کسی اجازه تغییر یک جزء را دارد
تغییرها کجا و چطور ثبت می‌شوند
نسخه طراحی و نسخه کدنویسی اجزا چطور هماهنگ می‌مانند
یک هشدار هم بدهم: از ساختن صدها جزء برای «روز مبادا» پرهیز کنید. اجزایی را بسازید که در مسیرهای واقعی محصول به کار می‌روند، چون مجموعه بزرگ و بی‌استفاده فقط هزینه نگهداری می‌سازد. دیزاین سیستم ابزار است؛ جواب اینکه طراحی رابط کاربری چیست را باید در مسیرهای کاربر پیدا کرد، نه در تعداد اجزا.
در طراحی فارسی و نسخه موبایل چه چیزهایی جا می‌ماند؟
بیشترین جاماندگی در جزئیات راست‌به‌چپ و رفتار صفحه در عرض‌های مختلف است. طراحی واکنش‌گرا (Responsive) یعنی چیدمان خودش را با فضای نمایش سازگار کند. نسخه موبایل تصویر کوچک‌شده دسکتاپ نیست؛ اولویت‌ها و ترتیب اجزا در آن فرق میکند. درباره دلایل کسب‌وکاری این موضوع، مطلب اهمیت طراحی واکنش‌گرا برای کسب‌وکار را ببینید.
در طراحی رابط کاربری سایت فارسی، این موارد را حتماً با محتوای واقعی بررسی کنید:
جهت راست‌به‌چپ متن و ترتیب ستون‌ها
شماره تلفن، ایمیل و نشانی لاتین که داخل متن فارسی می‌آیند
اعداد فارسی یا لاتین و یکدستی آن‌ها
واحد پول، یعنی ریال یا تومان، و جایش کنار مبلغ
همچنین آیکون‌ها را جدا بررسی کنید. فلش «بعدی» و «بازگشت» معنای جهت دارند و در رابط فارسی باید برعکس شوند. اما آیکون جست‌وجو یا ساعت جهت معنایی ندارد و آینه‌کردنش اشتباه است. برای جزئیات فنی، منابع بین‌المللی‌سازی وب مرجع مفیدی است.
در موبایل، این موارد را صریحاً در معیارهای پذیرش بنویسید:
جدول‌های عریض چطور نمایش پیدا می‌کنند: اسکرول افقی، کارت یا خلاصه
با باز شدن صفحه‌کلید، فیلد فعال و دکمه اصلی دیده می‌شوند یا نه
عنوان‌های بلند فارسی چطور می‌شکنند
اقدام اصلی بدون اسکرول طولانی در دسترس است یا نه
پس از تیم طراحی قواعد تبدیل چیدمان را بخواهید: اجزا در کدام عرض جابه‌جا یا جمع می‌شوند. سه تصویر برای موبایل، تبلت و دسکتاپ همه عرض‌های ممکن را پوشش نمی‌دهد. در نسخه موبایل، اینکه طراحی رابط کاربری چیست را قاعده‌ها تعریف می‌کنند، نه تصویرها.
تست کاربردپذیری چه زمانی به بازطراحی منجر میشود؟
وقتی مشاهده‌ها نشان دهند مشکل در منطق مسیر است، نه در یک جزء، تست به بازطراحی می‌رسد. تست کاربردپذیری یعنی تماشای کاربران مناسب هنگام انجام یک کار مشخص. نظرخواهی درباره زیبایی جای آن را نمی‌گیرد، چون آدم‌ها چیزی را که دوست دارند همیشه راحت‌تر به کار نمی‌برند.
سناریو باید بی‌طرف باشد و راه‌حل را لو ندهد. نمونه خوب: «این کالا را برای نشانی مشخص‌شده سفارش دهید و پیش از ثبت، مبلغ نهایی را بگویید.» نمونه بد: «روی دکمه سبز بالای صفحه بزنید و هزینه ارسال را ببینید.»
یادداشت‌ها را در سه ستون جدا بنویسید: آنچه دیدید، تفسیرتان و پیشنهاد اصلاح. «کاربر ۲۰ ثانیه روی صفحه نشانی مکث کرد» مشاهده است؛ «فیلد شهر گیج‌کننده است» تفسیر است. راهنمایی کاربر وسط آزمون هم خطرناک است، زیرا دقیقاً همان مشکلی را پنهان میکند که دنبالش بودید.
زیبایی را با یک نگاه میشود تأیید کرد؛ کاربردپذیری را فقط با تماشای کار کاربر.
شدت هر مشکل را با سه معیار بسنجید: جلوی انجام کار را می‌گیرد، چند بار تکرار شده و کاربر خودش توانسته برگردد یا نه. چند جلسه محدود مشاهده برای پیدا کردن مشکلات جدی خوب است. اما آمارش نماینده بازار نیست و نباید آن را مثل نظرسنجی گزارش کرد.
تصمیم بعدی بین اصلاح موضعی و بازطراحی مسیر است. اگر کاربران فقط یک دکمه را نمی‌بینند، اصلاح همان دکمه کافی است. اگر در چند مرحله پشت‌سرهم گیر می‌کنند یا ترتیب مراحل را نمی‌فهمند، مسیر باید از نو طراحی شود. و اگر مشکل از قیمت، سیاست ارسال یا خطای فنی است، تغییر ظاهر درمانش نیست. صادقانه بگویم، دانستن اینکه طراحی رابط کاربری چیست یعنی دانستن اینکه کجا کاری از دستش برنمی‌آید.
بعد از هر اصلاح مهم، همان هدف را با کاربران تازه دوباره بیازمایید. اصلاحی که آزموده نشده، فقط یک حدس تازه است.
مراحل پروژه و نقاط تأیید پیش از کدنویسی کدام‌اند؟
ترتیب پیشنهادی من پنج مرحله دارد و هر مرحله با یک تأیید بسته میشود. اگر بپرسید طراحی رابط کاربری چیست در قالب یک برنامه کاری، همین پنج قدم است:
تعریف مسئله و دامنه
ساختار: معماری اطلاعات، مسیرها و وایرفریم
نمونه تعاملی و آزمون آن
طرح بصری نهایی و حالت‌ها
آماده‌سازی تحویل برای تیم فنی
با این حال، این مسیر خط مستقیم نیست. گاهی آزمون نمونه تعاملی نشان می‌دهد یکی از فرض‌های مسئله غلط بوده و باید به عقب برگشت. این بازگشت نشانه شکست نیست؛ ارزان‌ترین جای اصلاح همین‌جاست.
برای هر نقطه تأیید سه چیز را مشخص کنید: چه تصمیمی قرار است گرفته شود، چه کسی آن را می‌گیرد و چه شواهدی لازم است. «تأیید وایرفریم توسط مدیر محصول با مرور سه مسیر اصلی» قابل پیگیری است. اما «نظر همه را بگیریم» نیست.
بازخوردها را یک‌جا و بر اساس سناریو جمع کنید. وقتی پنج مدیر جداگانه در پیام‌رسان نظر می‌دهند، طراح میان سلیقه‌های متناقض گیر می‌افتد. پیشنهاد من یک فایل یا جلسه مشترک است که هر نظر را به یک سناریو و یک معیار پذیرش وصل کند.
توسعهدهنده را از مرحله ساختار وارد گفت‌وگو کنید، نه بعد از طرح نهایی. چون او زودتر از همه می‌گوید کدام داده وجود ندارد، کدام اتصال بیرونی کند است و کدام فیلتر پیچیده هزینه زیادی دارد.
در پایان هر مرحله، تأیید را برای محدوده‌ای مشخص ثبت کنید. اگر بعد از تأیید طرح نهایی نیاز تازه‌ای پیدا شود، ممکن است دامنه، هزینه و برنامه زمانی عوض شود. این را از اول بدانید تا غافلگیر نشوید.
به‌جای «این صفحه را دوست ندارم»، بنویسید کاربر در کدام مرحله، برای انجام چه کاری، با چه مانعی روبه‌رو میشود. اگر بازخورد صرفاً ترجیح برند است، آن را جدا مشخص کنید.
برای هر مرحله چه خروجی و معیار پذیرشی لازم است؟
هر خروجی باید به یک تصمیم مشخص وصل باشد؛ وگرنه فقط یک فایل است. گزارش شناخت برای تأیید مسئله است، مسیر کاربر برای تأیید منطق و طرح اولیه برای تأیید ساختار. معیارها هم باید قابل مشاهده باشند. «حرفه‌ای و جذاب» معیار نیست، چون هر کس برداشت خودش را از آن دارد.
برای کارفرما، جواب عملی پرسش طراحی رابط کاربری چیست همین جدول است: مجموعه‌ای از خروجیهای قابل سنجش.
مرحله | خروجی | معیار پذیرش |
|---|---|---|
تعریف مسئله | گزارش شناخت و بیان مسئله | مسئله، کاربر هدف و فرضیه‌ها جدا از هم نوشته شدهاند |
مسیرها | نمودار مسیر کاربر | مسیرهای ضروری همراه حالت‌های خطا و بازگشت آمده‌اند |
ساختار | وایرفریم با متن واقعی | اطلاعات هر تصمیم در صفحه هست و اقدامی جا نیفتاده |
نمونه تعاملی | پروتوتایپ قابل کلیک | همه سناریوهای توافق‌شده قابل اجرا هستند |
طرح نهایی | صفحه‌ها و حالت‌ها در اندازه‌های هدف | متن خواناست و حالت‌های عادی، خطا، انتظار و خالی وجود دارند |
تحویل | فایل منظم و مستندات | تیم فنی بدون حدس زدن می‌تواند بسازد |
معیار خوب جزئی و آزمودنی است. برای نمونه: «اگر نشانی نامعتبر باشد، داده‌های قبلی حفظ می‌شوند و فیلد نیازمند اصلاح، با متن توضیح مشخص است.» هر کسی می‌تواند این جمله را روی نمونه تعاملی امتحان کند.
همچنین یک پیوست به بسته پذیرش اضافه کنید:
فهرست صفحه‌های منحصربه‌فرد، نه صفحه‌های تکراری با محتوای متفاوت
نقش‌های کاربری و آنچه هر نقش می‌بیند
حالت‌های طراحی‌شده برای هر صفحه
اندازه‌های هدف نمایش، مثلاً یک عرض موبایل و یک عرض دسکتاپ
یک مرز را هم روشن نگه دارید. تأیید طراحی یعنی رفتار و ظاهر مورد انتظار را پذیرفته‌اید. اما این به معنای پذیرش امنیت، کارایی یا صحت نسخه اجراشده نیست؛ آن‌ها آزمون‌های جداگانه دارند.
تحویل فایل طراحی به توسعهدهنده چگونه انجام میشود؟
کار وقتی خوب تحویل شده که توسعهدهنده بتواند بدون حدس زدن و بدون ده‌ها پیام پرسشی بسازد. دامنه تحویل را در قرارداد بنویسید: فایل قابل ویرایش، دسترسی مناسب، صفحه‌بندی روشن، نام‌گذاری اجزا و یک نسخه مرجع تأییدشده.
ابزارهای طراحی مشترک مثل فیگما (Figma) تحویل را خیلی راحت‌تر کرده‌اند. اما ابزار وسیله است، نه معیار کیفیت؛ فایل شلوغ در بهترین ابزار هم شلوغ می‌ماند. دو نکته حقوقی را هم فراموش نکنید: مالکیت فایل با کیست و مجوز فونت‌ها، آیکون‌ها و تصویرها چطور است.
آنچه باید مستند شود:
اندازه‌ها و فاصله‌ها، ترجیحاً بر پایه یک مقیاس ثابت
قواعد تغییر چیدمان بین اندازه‌های نمایش
متن‌های نهایی، از جمله پیام‌های خطا و تأیید
دارایی‌های قابل خروجی مثل آیکون و تصویر
رفتار تعامل‌ها: با کلیک، نگه‌داشتن یا کشیدن چه اتفاقی می‌افتد
در عمل، حالت‌های کمتر دیده‌شده بیشترین سؤال را در زمان ساخت ایجاد می‌کنند. برای حالت خالی مثل سبد بدون کالا، خطا، انتظار، نبود دسترسی و داده طولانی، نمونه طراحی‌شده یا قاعده قابل اجرا بخواهید. اگر از من بپرسید در مرحله تحویل طراحی رابط کاربری چیست، می‌گویم همین حالت‌های فراموش‌شده.
سرانجام یک جلسه مرور با توسعهدهنده بگذارید و مسیر پرسش‌وپاسخ بعد از تحویل را تعیین کنید. بازبینی نسخه ساخته‌شده توسط طراح کار ارزشمندی است، اما دامنه مستقل و مشخص لازم دارد. این بازبینی خودبه‌خود جزو تحویل نیست.
مرز مسئولیت طراحی و توسعه کجاست؟
طراحی رفتار مورد انتظار را تعیین میکند و توسعه آن را پیاده میکند. اما مرز دقیق به قرارداد و ترکیب تیم بستگی دارد و باید مکتوب باشد. همین تقسیم کار بخشی از جواب این پرسش است که طراحی رابط کاربری چیست و کجا تمام میشود.
خطای پرداخت مثال روشنی است. طراح پیام خطا و مسیر بازیابی را مشخص میکند: کاربر چه می‌بیند و دکمه «تلاش دوباره» کجاست. اما تشخیص اینکه تراکنش واقعاً ناموفق بوده یا پاسخ بانک دیر رسیده، به منطق اجرایی نیاز دارد. جلوگیری از ثبت دوباره سفارش هم کار توسعه است.
برخی مسئولیت‌ها مشترک‌اند، اما آزمونشان فرق دارد:
حوزه | سهم طراحی | سهم توسعه |
|---|---|---|
دسترس‌پذیری | کنتراست، ترتیب تمرکز و متن خطا | ساختار درست کد و کار با صفحه‌کلید و صفحه‌خوان |
عملکرد | تصاویر سبک و پرهیز از جلوه‌های سنگین | سرعت بارگذاری و بهینه‌سازی |
تطابق بصری | نسخه مرجع روشن و کامل | پیاده‌سازی دقیق و گزارش هر انحراف |
علاوه بر این، محدودیت سرویس‌های بیرونی و داده‌های ناقص را پیش از قطعی شدن طرح با تیم فنی بررسی کنید. مثلاً اگر سامانه انبار تصویر کالا را با کیفیت پایین می‌دهد، طرحی که روی عکس‌های بزرگ بنا شده در اجرا شکست می‌خورد.
این پرسش را در قرارداد جواب دهید: چه کسی اختلاف بین طرح تأییدشده و نسخه ساخته‌شده را بررسی میکند و چه کسی برای رفعش تصمیم می‌گیرد؟ بی‌جواب ماندن این سؤال، منشأ بسیاری از اختلاف‌های پایان پروژه است.
پیش از انتشار، نسخه ساخته‌شده باید با داده و شرایط واقعی بررسی شود. مسئولیت آزمون و رفع اختلاف با طرح را از ابتدا روشن کنید.
هزینه طراحی رابط کاربری به چه چیزهایی بستگی دارد؟
بیشتر از تعداد صفحه، پیچیدگی رفتار تعیین‌کننده است. وقتی بدانید طراحی رابط کاربری چیست و چه خروجی‌هایی دارد، برآورد هم قابل فهم‌تر میشود. عوامل اصلی این‌هاست:
تعداد مسیرهای منحصربه‌فرد
تعداد نقش‌های کاربری
حالتهایی که هر صفحه باید داشته باشد
میزان پژوهش و آزمون با کاربر
اندازه‌های نمایش هدف
سطح مستندسازی و تحویل
به همین دلیل شمارش صفحه معیار کافی نیست. ده صفحه محتوایی با قالب تکراری ممکن است کار کمتری از سه صفحه داشبورد با فیلتر، جدول و چند نقش داشته باشد.
دو دامنه فرضی را کنار هم بگذارید. اولی اصلاح یک فرم موجود است: مسئله روشن، دادهها مشخص و فقط یک نقش کاربری. دومی بازطراحی مسیر سفارش با سه نقش و اتصال‌هایی است که هنوز معلوم نیست چه داده‌ای می‌دهند. دومی فقط بزرگ‌تر نیست؛ عدم قطعیت بیشتری دارد و بخشی از کار صرف روشن کردن همین ابهام میشود.
چند مورد دیگر را هم در برآورد صریح کنید: تعداد دورهای بازخورد، نحوه برخورد با تغییر دامنه، آماده بودن محتوا و امکان دسترسی به کاربران واقعی برای گفت‌وگو و آزمون.
اگر بودجه محدود است، قاعده من این است: مسیرهای ضروری را اولویت دهید و بقیه را به فاز بعد بسپارید. اما حالت‌های خطا و تحویل قابل استفاده را حذف نکنید، چون صرفه‌جویی آنجا در زمان توسعه چند برابر پس گرفته میشود.
در ضمن، بودجه طراحی و توسعه را جدا ببینید. اگر دیزاین سیستم دارید، هزینه نگهداری اجزای مشترک را هم در نظر بگیرید؛ این کار با تحویل تمام نمی‌شود.
چگونه تیم طراحی مناسب انتخاب کنیم؟
تیمی را انتخاب کنید که بتواند دلیل تصمیم‌هایش را توضیح دهد، نه فقط تصویرهای زیبا نشان دهد. نمونه‌کار خوب شرح مسئله، محدودیت‌ها، دلیل انتخاب‌ها و خروجی قابل تحویل را نشان می‌دهد. تصویرهای نهایی فقط بخشی از شواهدند؛ تیمی که خودش بداند طراحی رابط کاربری چیست، از مسئله شروع میکند، نه از طرح.
در جلسه اول از تیم بخواهید روش بررسی یکی از مسیرهای واقعی محصول شما را توضیح دهد. بپرسید با توسعهدهنده چطور همکاری میکند. این با درخواست طرح رایگان اختصاصی فرق دارد، زیرا کار رایگان معمولاً بدون شناخت مسئله انجام میشود و از روش تیم چیز زیادی نمی‌گوید.
این پرسش‌ها را هم بپرسید:
چه کسی پژوهش و گفت‌وگو با کاربران را انجام می‌دهد؟
تصمیم‌گیر نهایی در طرف شما و طرف تیم کیست؟
فایل قابل ویرایش تحویل می‌گیرید؟
چند دور بازخورد در دامنه هست؟
هنگام اجرا، طراح برای سؤال‌های تیم فنی در دسترس است؟
عنوان‌هایی مثل «طراحی یو آی یو ایکس» یا «بسته کامل UX» را به خدمات قابل مشاهده تبدیل کنید. بپرسید دقیقاً چند جلسه آزمون، چه گزارشی و کدام خروجی‌ها در آن هست. عنوان بسته به‌تنهایی وجود پژوهش یا آزمون را تضمین نمی‌کند.
اگر می‌خواهید ببینید نیاسا این کار را چطور پیش میبرد، صفحه خدمات طراحی رابط کاربری UI/UX نیاسا را ببینید. پیشنهاد ما این است که دامنه، خروجی‌ها و نقاط تأیید در همان گفت‌وگوی اولیه روشن شوند تا هر دو طرف از یک چیز حرف بزنند.
چک‌لیست شروع پروژه و پرسش‌های رایج کارفرما
پیش از اولین جلسه با تیم طراحی، یک برگه یک‌صفحه‌ای با این موارد آماده کنید:
مسئله: یک جمله با قالب چه کسی، در چه موقعیتی، برای چه کاری، با چه مانعی
کاربران و نقشها
مسیرهای ضروری به ترتیب اولویت
محدودیت‌ها: فنی، زمانی، حقوقی و برند
محتوای موجود و محتوایی که هنوز نوشته نشده
تصمیم‌گیر نهایی
خروجیهای مورد انتظار
هرجا جوابی ندارید، پنهانش نکنید. بنویسید «نامشخص»، مسئول بررسی را تعیین کنید و زمان تصمیم بعدی را بگذارید. ابهام ثبت‌شده قابل مدیریت است؛ اما ابهام پنهان وسط پروژه سر باز میکند.
محصول کوچک من هم به طراحی UI/UX نیاز دارد؟ بله، اما با عمق کمتر. برای یک وبسایت ساده، پاسخ اینکه طراحی رابط کاربری چیست کوتاه‌تر است: چند مسیر اصلی، وایرفریم و طرح نهایی با حالت‌های کلیدی معمولاً کافی است.
طراحی جداگانه برای موبایل لازم است؟ اگر بخش مهمی از کاربرانتان با گوشی می‌آیند، بله. دست‌کم مسیرهای اصلی باید در عرض موبایل طراحی و بررسی شوند.
نمونه تعاملی چقدر قابل اعتماد است؟ برای سنجش فهم مسیر و ترتیب مراحل، خیلی مفید است. اما سرعت، امنیت و صحت محاسبات را نشان نمی‌دهد.
فایل طراحی را باید تحویل بگیرم؟ بله. فایل قابل ویرایش و مالکیت آن را در قرارداد بنویسید تا به یک نفر وابسته نمانید.
قدم بعدی عملی ساده است. همین برگه را برای دو یا سه تیم طراحی بفرستید و پاسخ‌هایشان را بر اساس دامنه یکسان مقایسه کنید. هر تیمی که درباره مسئله یا کاربرانتان سؤال تازه‌ای پرسید، نشانه خوبی از خودش نشان داده است.
اگر هنوز برایتان روشن نیست که در محصول خودتان طراحی رابط کاربری چیست و به کدام خروجی‌ها نیاز دارید، می‌توانید نیازهای UI/UX خود را با تیم نیاسا مرور کنید. هدف آن گفت‌وگو این است که پیش از هر تصمیمی بدانید دقیقاً چه چیزی لازم دارید.
مسئله محصول، کاربران اصلی و محدودیت‌های فعلی‌تان را با نیاسا در میان بگذارید تا درباره دامنه مناسب طراحی گفت‌وگو کنیم.
پرسش‌های پرتکرار
۵آیا کسب‌وکار کوچک هم به طراحی UI/UX نیاز دارد؟
بله، اما حجم کار باید با ریسک و پیچیدگی محصول متناسب باشد. برای یک سایت ساده، روشن کردن ساختار، اقدام اصلی و نمایش موبایل ممکن است کافی باشد؛ محصول چندنقشی بررسی عمیق‌تری می‌خواهد.
آیا طراحی رابط کاربری شامل برنامهنویسی هم میشود؟
معمولاً طراحی و برنامهنویسی دو بخش جدا از دامنه پروژه هستند، حتی اگر یک تیم هر دو را انجام دهد. در پیشنهاد همکاری باید مشخص شود تحویل شما فایل طراحی است یا محصول اجراشده و آزمودهشده.
آیا پروتوتایپ همان نسخه اولیه محصول است؟
پروتوتایپ معمولاً رفتار بخشهایی از محصول را شبیهسازی میکند و ممکن است هیچ اتصال واقعی به دادهها نداشته باشد. از آن برای بررسی مسیر و فهم کاربر استفاده کنید، نه تأیید امنیت یا عملکرد فنی.
آیا تحویل فایل فیگما برای تأیید پروژه کافی است؟
داشتن فایل فقط یکی از شرطهای تحویل است. باید معلوم باشد کدام نسخه تأیید شده، چه حالتهایی پوشش داده شدهاند و توسعهدهنده قواعد رفتار و تغییر چیدمان را از کجا میفهمد.
طراحی UI/UX چقدر زمان میبرد؟
بدون مشخص شدن مسیرها، نقشها و عمق آزمون نمیتوان زمان معناداری اعلام کرد. از تیم بخواهید برنامه را به خروجیهای مرحلهای و زمان لازم برای دریافت بازخورد شما متصل کند.
