یک فروشگاه آنلاین در مشهد طرحِ تازه‌اش را مستقیم از فیگما به برنامه‌نویس میدهد. سه هفته بعد معلوم میشود صفحه‌ی پرداخت چهار حالتِ خطا دارد که هیچ‌کس طراحی‌شان نکرده و دکمه‌ها در دو صفحه دو رنگِ متفاوتِ «آبی» دارند. فرایند طراحی UI/UX برای جلوگیری از همین اتفاق‌هاست: هفت قدمِ پشت‌سرهم، از تحقیق روی کاربر تا تحویل به توسعه، که هر قدم خروجیِ مشخصی دارد و ورودیِ قدمِ بعدی میشود. اگر یکی را جا بیندازید، هزینه‌اش را بعداً در کد می‌دهید.
اگر فرقِ خودِ UI و UX را هنوز برایتان روشن نیست، اول تفاوت UI و UX را بخوانید و برگردید. این مقاله فرض میکند آن مرز را می‌دانید و درباره‌ی ترتیبِ کار حرف می‌زند.
فرایند طراحی UI/UX از کجا شروع میشود؟
از چیزی که هنوز طراحی نیست: از آدم‌ها. قدمِ اول مصاحبه و مشاهده است، نه رنگ‌بندی. هدف این است که بفهمید کاربر واقعی برای رسیدن به کارش چه میکند، کجا گیر میکند و امروز چطور دورش می‌زند.
مصاحبه‌ی خوب سؤالِ «این صفحه را دوست دارید؟» نمی‌پرسد. می‌پرسد «آخرین باری که می‌خواستید از یک کلینیک وقت بگیرید، چه کردید؟». جواب‌ها داستان‌اند و داستان‌ها الگو دارند. با چند مصاحبه با آدم‌های واقعی از مخاطبِ همان کسب‌وکار، معمولاً دو سه مشکلِ تکراری بیرون میآید که هیچ جلسه‌ی داخلیِ شرکت آن‌ها را کشف نمی‌کرد.
پرسونا و سفر کاربر چه کمکی به طراحی می‌کنند؟
پرسونا خلاصه‌ی یک گروهِ واقعی از کاربران است، نه یک شخصیتِ خیالیِ خوش‌ظاهر با عکسِ استوک. کافی است هدف، موقعیتِ استفاده (موبایل در صف یا لپ‌تاپ در دفتر) و بزرگ‌ترین دغدغه‌اش را بنویسید. سفر کاربر همین آدم را روی یک خط می‌گذارد: از اولین آشنایی با کسب‌وکار تا انجام کار، و در هر نقطه می‌پرسد چه فکر میکند و چه چیزی آزارش میدهد.
ارزشِ این دو در تصمیم‌گیری است. وقتی بحثِ «این دکمه بالا باشد یا پایین؟» پیش میآید، جواب را پرسونا میدهد، نه سلیقه‌ی بلندترین صدای جلسه.
معماری اطلاعات و وایرفریم چرا پیش از طراحی بصری می‌آیند؟
معماری اطلاعات یعنی تصمیم بگیرید چه صفحه‌هایی لازم است، منو چطور دسته‌بندی شود و هر محتوا کجا بنشیند. وایرفریم همان ساختار را به‌صورتِ طرحِ خاکستریِ بدون رنگ و عکس روی صفحه می‌آورد. خاکستری بودنش عمدی است: وقتی رنگ نیست، بحث سرِ جای عناصر و ترتیبِ اطلاعات می‌ماند.
تغییرِ یک بلوک در وایرفریم چند دقیقه کار دارد. همان تغییر بعد از کدنویسی ممکن است چند فایل را درگیر کند. به همین دلیل در مراحل طراحی سایت هم ساختار را پیش از ظاهر تأیید می‌کنیم.
طراحی UI و دیزاین سیستم دقیقاً چه چیزی تحویل میدهد؟
حالا نوبتِ ظاهر است. طراحی UI رنگ، تایپوگرافی، فاصله‌ها و حالتِ اجزا را روی ساختارِ تأییدشده سوار میکند. برای سایت فارسی چند چیز را باید از همین‌جا لحاظ کرد: چیدمانِ راست‌به‌چپ، وزن‌های فونتِ فارسی که در اندازهی کوچک خوانا بمانند و ارقامی که با متن هماهنگ باشند.
دیزاین سیستم جایی است که طرح از «چند صفحه‌ی قشنگ» به «زبانِ قابل‌تکرار» تبدیل میشود. Nielsen Norman Group آن را مجموعه‌ای کامل از استانداردها برای مدیریتِ طراحی در مقیاس با اجزا و الگوهای قابل‌استفاده‌ی مجدد تعریف میکند و می‌گوید از یک مخزن (راهنمای سبک، کتابخانه‌ی اجزا، کتابخانه‌ی الگوها) و آدم‌هایی که آن را نگه می‌دارند ساخته میشود. همان آدم‌ها را فراموش نکنید؛ دیزاین سیستمِ بی‌صاحب بعد از چند ماه از کد جدا میشود.
هر قدم از فرایند چه خروجی‌ای دارد؟
این چک‌لیست را موقع تحویلِ هر مرحله به کار ببرید. اگر خروجیِ یک ردیف را نمی‌توانید نشان بدهید، آن قدم هنوز تمام نشده است.
| قدم | سؤالی که جواب میدهد | خروجیِ قابل‌تحویل |
|---|---|---|
| تحقیق و مصاحبه | کاربر واقعی چه میکند و کجا گیر میکند؟ | یادداشت‌های مصاحبه و فهرست مشکلات |
| پرسونا و سفر کاربر | برای چه کسی و در چه موقعیتی طراحی می‌کنیم؟ | پرسونا و نقشه‌ی سفر |
| معماری اطلاعات | چه صفحه‌هایی لازم است و چطور به هم وصل‌اند؟ | نقشه‌ی سایت و ساختار منو |
| وایرفریم | هر صفحه چه بخش‌هایی دارد و به چه ترتیب؟ | طرح خاکستری صفحه‌های اصلی |
| UI و دیزاین سیستم | ظاهر و رفتار هر جزء چیست؟ | طرح نهایی، رنگ، تایپوگرافی، کتابخانه‌ی اجزا |
| پروتوتایپ و تست | آدم واقعی با این طرح کارش را انجام میدهد؟ | پروتوتایپ تعاملی و گزارش تست |
| تحویل به توسعه | برنامه‌نویس همه‌ی حالت‌ها را می‌داند؟ | مشخصات اجزا، حالت‌ها و توکن‌های طراحی |
پروتوتایپ را با چند نفر تست کنیم؟
پروتوتایپ طرحِ کلیکشدنی است که هنوز کد ندارد. تستش ساده است: یک کار مشخص به کاربر بدهید («یک نوبت برای هفته‌ی آینده بگیر»)، ساکت بنشینید و ببینید کجا مکث میکند. توضیح ندهید. هر توضیحی که می‌دهید یعنی صفحه خودش جواب نداده.
تعدادِ لازم کمتر از چیزی است که فکر می‌کنید. به گفته‌ی Jakob Nielsen در مقاله‌ی «چرا فقط به ۵ کاربر نیاز دارید»، بیشترِ مشکلاتِ قابل‌کشف را همان نفراتِ اول نشان می‌دهند و از حدود نفر پنجم تکرارِ یافته‌های قبلی شروع میشود. او به‌جای یک تستِ بزرگ، چند دورِ کوچک پیشنهاد میکند: تست، اصلاح، تستِ دوباره. اگر سایت چند گروهِ کاملاً متفاوت از کاربر دارد، برای هر گروه باید جدا آدم بیاورید.
در همین مرحله به قابلیتِ دسترسی هم نگاه کنید. مثلاً W3C در معیار ۲.۵.۸ از WCAG 2.2 می‌گوید هدف‌های لمسی دست‌کم ۲۴ در ۲۴ پیکسل CSS باشند، مگر استثناهایی مثل فاصله‌ی کافی از هدف‌های کناری. دکمه‌ی ریزِ منوی موبایل معمولاً همین‌جا گیر میکند.
تحویل به توسعه‌دهنده چه چیزهایی میخواهد؟
تحویل فقط فایل فرستادن نیست. برنامه‌نویس باید همه‌ی حالتِ هر جزء را بداند: حالت عادی، هاور، فوکوس، غیرفعال، خطا، خالی بودن و در حال بارگذاری. صفحه‌ی پرداختِ ابتدای مقاله دقیقاً سرِ همین حالت‌ها خراب شد.
توکن‌های طراحی (نامِ رنگ‌ها، اندازهی فاصله‌ها، وزن فونت‌ها) کمک می‌کنند طرح و کد از یک واژگان حرف بزنند. وقتی طراح می‌گوید «رنگِ اصلی» و در کد هم همین اسم هست، تغییرِ برند یک جا انجام میشود، نه در صدها فایل.
برای این کارها از چه ابزارهایی استفاده کنیم؟
ابزار مهم است ولی از فرایند مهم‌تر نیست. فیگما برای وایرفریم، طرح نهایی، کتابخانه‌ی اجزا و پروتوتایپ کافی است و تقریباً استانداردِ تیم‌هاست. برای مصاحبه یک دفترچه و یک تماسِ ویدیویی کافی است. برای نقشه‌ی سایت حتی یک تخته‌ی سفید. اگر تیمتان کوچک است، با کمترین ابزار شروع کنید و فقط آنچه واقعاً استفاده میشود نگه دارید.
فرایند UI/UX برای سایت کوچک هم لازم است؟
نسخه‌ی سبکش بله. سایتی با چند صفحه به مصاحبه‌های طولانی و دیزاین سیستمِ بزرگ نیاز ندارد، ولی تحقیقِ کوتاه، وایرفریمِ صفحه‌های اصلی و یک تست با چند نفر را نباید حذف کرد. مثلاً یک صفحه‌ی فرود که قرار است تبلیغ بگیرد، بدون این سه کار معمولاً با حدس طراحی میشود.
تجربه‌ی خودم در این باره تلخ‌تر از چیزی است که دوست دارم اعتراف کنم. موقع ساختنِ onwebs.ir با Next.js یک بخش را چند بار فقط بصری صیقل دادم و بعد دیدم کاربرِ موبایل در آن صفحه راهش را پیدا نمیکند. طرح از نظر UI ایرادی نداشت؛ ساختارش غلط بود. اولش حدس زده بودم مشکل از فاصله‌ها و اندازهی فونت است، و اشتباه می‌کردم. از آن به بعد قاعده‌ام این است: وایرفریمِ خاکستری، بعد تأییدِ مسیر، بعد رنگ. اسم رنگ‌ها و فاصله‌ها را هم از همان اول در طرح و کد یکی نگه می‌دارم تا برنامه‌نویس و طراح دو زبان نداشته باشند. کندتر شروع میشود، ولی بازطراحیِ وسط راه را حذف میکند.
اگر پروژه‌ای دارید که می‌خواهید طراحی‌اش از تحقیق شروع شود، آنوبز در مشهد این مسیر را بخشی از طراحی UX و طراحی UI انجام میدهد. می‌توانید نمونه‌کارها را در بخش نمونه‌کار ببینید و برای مشاوره و برآورد رایگان از صفحه‌ی تماس پیام بدهید.
منابع
- Design Systems 101 — Nielsen Norman Group
- Why You Only Need to Test with 5 Users — Nielsen Norman Group
- Understanding Success Criterion 2.5.8: Target Size (Minimum) — W3C Web Accessibility Initiative
