چگونه وایرفریم سایت بسازیم؟ آموزش گام‌به‌گام برای مبتدیان

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

چرا یک مستطیل ساده کافی نیست؟

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

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

یک نمونه annotation برای صفحه درخواست خدمت

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

جریان را قبل از صفحه رسم کنید

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

برای مبتدیان، کاغذ یا ابزار ساده‌ای مانند Figma کافی است. کیفیت ابزار بر کیفیت سوال‌ها غلبه ندارد. استفاده از componentهای آماده وقتی مفید است که مسیر و محتوا روشن شده باشند؛ در غیر این صورت، component فقط ابهام را زیباتر نمایش می‌دهد.

متن واقعی را زود وارد کنید

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

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

تست پنج‌دقیقه‌ای

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

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

چه چیزی را به UI منتقل کنیم؟

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

منابع

1. W3C — Designing for Web Accessibility
2. MDN — HTML: A good basis for accessibility

حالت خالی را در همان طرح اولیه ببینید

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

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

بین بلوک‌ها اولویت بسازید

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

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

handoff به توسعه‌دهنده چگونه انجام می‌شود؟

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

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

یک روش بازبینی پیش از UI

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

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

نتیجه کاربردی برای مبتدیان

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

محدودیت این روش را بشناسید

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

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