Wireframe باید یک تصمیم باز را روشن کند
در صفحهٔ فهرست درخواست‌ها، کاربر باید وضعیت یک مورد را پیدا کند و بداند برای اصلاح اطلاعات از کجا شروع کند. اگر هنوز نمی‌دانیم فیلتر، عنوان و اقدام اصلی کجا باشند، Wireframe می‌تواند رابطهٔ آن‌ها را بدون صرف وقت روی ظاهر نهایی نشان دهد. این ابزار نمایش ساختار و رفتار محدود است. ساختن چند کادر خاکستری به تنهایی مسئله را حل نمی‌کند؛ باید معلوم باشد چه تصمیمی قرار است با آن بررسی شود. اگر پرسش روشن نیست، کم‌جزئیات بودن فایل فقط ابهام را ساده‌تر نمایش می‌دهد.
Wireframe همیشه نخستین قدم همهٔ پروژه‌ها نیست. گاهی پژوهش، خواندن محتوای موجود یا بررسی محدودیت سیستم مقدم است. همچنین استفاده از آن تضمین حذف خطاهای بعدی نیست. این راهنما یک تمرین فرضی را توضیح می‌دهد و فایل طراحی، تصویر یا تست کاربر واقعی نمی‌سازد. تعریف و نقش این ابزار در معرفی Wireframe در Balsamiq توضیح داده شده است. انتخاب سطح جزئیات باید با پرسش و مخاطب بازبینی هماهنگ باشد.
ساختار را از محتوا جدا فرض نکنید
یک عنوان واقعی طول دارد و یک وضعیت واقعی ممکن است توضیح لازم داشته باشد. اگر تمام محتوا را با خط‌های کوتاه فرضی نمایش دهیم، مسئلهٔ خواندن و ترتیب اطلاعات پنهان می‌شود. پیش از رسم، فهرست محتوای لازم را بنویسید: نام درخواست، تاریخ، وضعیت، جزئیات و اقدام مرتبط. سپس اولویت را با نیاز کاربر مشخص کنید. نام داخلی یک field همیشه برچسب مناسب برای صفحه نیست. Wireframe باید اطلاعات لازم برای تصمیم را قابل دیدن کند، نه فقط محل کلی متن را.
برای نمونهٔ این مقاله، سه وضعیت فرضی داریم: در حال بررسی، نیازمند اصلاح و تکمیل‌شده. هر کدام اقدام یکسان ندارند. مورد نیازمند اصلاح باید مسیر روشن به جزئیات مسئله بدهد؛ مورد تکمیل‌شده شاید فقط نمایش نتیجه بخواهد. قرار دادن دکمهٔ عمومی ادامه در همهٔ ردیف‌ها، همین تفاوت را پنهان می‌کند. دادهٔ فرضی باید به اندازه‌ای واقعی باشد که طول عنوان و تفاوت حالت‌ها دیده شود، ولی نباید به عنوان دادهٔ مشتری معرفی شود.
دامنهٔ تمرین را محدود بنویسید
تمرین ما فقط پیدا کردن درخواست و ورود به جزئیات آن است. ثبت درخواست تازه، پرداخت و مدیریت کاربران خارج از دامنه‌اند. این محدودیت را بالای فایل بنویسید. سپس یک جملهٔ task بسازید: کاربر می‌خواهد موردی را که نیاز به اصلاح دارد پیدا کند و بداند چه چیزی باید تغییر کند. همین جمله کمک می‌کند جای فیلتر، وضعیت و لینک جزئیات را انتخاب کنیم. اگر در بازبینی درخواست ویژگی تازه‌ای مطرح شد، آن را جدا ثبت کنید تا هدف تمرین بی‌صدا عوض نشود.
سه نمای محدود کافی است: فهرست معمولی، نتیجهٔ خالی پس از فیلتر و جزئیات مورد نیازمند اصلاح. تعداد نماها دستور عمومی نیست؛ این‌ها نیاز همین task را پوشش می‌دهند. در نمای جزئیات، پیام مسئله و راه بازگشت به فهرست دیده می‌شود. در حالت خالی، گزینهٔ پاک کردن فیلتر لازم است. این تمرین به backend وصل نیست و رفتار همهٔ وضعیت‌های واقعی را اثبات نمی‌کند. یادداشت محدوده جلوی برداشت اشتباه از کامل بودن نمونه را می‌گیرد.
از گروه‌بندی اطلاعات شروع کنید
در فهرست، عنوان صفحه و توضیح کوتاه، گروه کنترل فیلتر و خود نتایج را جدا مشخص کنید. فاصلهٔ گروه‌ها باید ارتباط را نشان دهد. لازم نیست برای هر field کادر مستقل بگذارید؛ شاید بعضی اطلاعات باید در یک ردیف یا کارت کنار هم دیده شوند. تصمیم table یا card را به میزان داده و نیاز مقایسه وصل کنید. اگر کاربر باید وضعیت چند مورد را سریع مقایسه کند، حذف ستون‌های مرتبط برای ظاهر خلوت ممکن است کار را سخت‌تر کند.
در اندازهٔ کوچک، همان اطلاعات شاید نیاز به چیدمان دیگری داشته باشند. نسخهٔ narrow را فقط با کوچک کردن تصویر نسخهٔ عریض نسازید. تعیین کنید کدام اطلاعات همیشه دیده می‌شوند و کدام در جزئیات قرار می‌گیرند. این تصمیم ساختاری با اندازهٔ فونت فرق دارد. مقالهٔ اصول UX رابطهٔ نیاز و اطلاعات را توضیح می‌دهد. Wireframe باید بتواند دلیل حذف یا جابه‌جایی را بیان کند، نه اینکه فقط به محدودیت جا اشاره کند.
کنترل باید عمل قابل فهم داشته باشد
برای فیلتر، نام گزینه‌ها و وضعیت انتخاب‌شده را نشان دهید. برای لینک جزئیات، مقصد را با متن واضح بیان کنید. اگر دکمه عمل غیرقابل برگشت انجام می‌دهد، باید در ساختار بازبینی دیده شود؛ پنهان کردن آن تا مرحلهٔ Visual Design تصمیم مهم را عقب می‌اندازد. همچنین مشخص کنید control در حالت loading چه رفتاری دارد. یک placeholder مربع بدون برچسب، دربارهٔ معنی عمل اطلاعات کافی نمی‌دهد و مخاطب را مجبور می‌کند از توضیح شفاهی طراح کمک بگیرد.
در تمرین فرضی، عمل اصلی ردیف نیازمند اصلاح، «دیدن موارد اصلاح» است. این متن شاید بعداً با زبان محصول بازنویسی شود، ولی اکنون مقصد را واضح می‌کند. پس از ورود به جزئیات، پیام باید بگوید کدام اطلاعات ناقص‌اند و مسیر تغییر چیست. وضعیت بارگذاری برای ثبت رفتار انتظار مناسب است. Stateهای خطا و خالی باید در ساختار حضور داشته باشند، چون کاربر فقط مسیر موفق را تجربه نمی‌کند.
جزئیات بصری را به اندازهٔ لازم نگه دارید
رنگ محدود می‌تواند برای جدا کردن یادداشت از محتوای صفحه مفید باشد. بنابراین Wireframe الزاماً بدون هیچ رنگ یا style نیست. مسئله این است که جزئیات، توجه را از تصمیم باز منحرف نکنند. اگر بازبینی دربارهٔ محل فیلتر است، سایه و gradient نهایی شاید فقط گفتگو را به سلیقه بکشاند. اگر کنتراست یا hierarchy پرسش اصلی است، مقداری جزئیات بصری لازم می‌شود. Fidelity باید به شاهد مورد نیاز وابسته باشد، نه یک رتبه‌بندی ثابت میان ابزارها.
کاغذ، Balsamiq و Figma گزینه‌های مختلف‌اند و سریع‌ترین ابزار برای همهٔ تیم‌ها یکی نیست. آشنایی، نیاز به تعامل و روش بازبینی اثر دارند. در Figma می‌توان رابطهٔ فاصله و اندازه را با Auto Layout ثبت کرد؛ راهنمای رسمی Auto Layout رفتار آن را توضیح می‌دهد. این قابلیت اجرای responsive در مرورگر را تأیید نمی‌کند و باید به قرارداد کد ترجمه شود.
Annotation رفتار پنهان را روشن می‌کند
اگر فیلتر بعد از انتخاب فوراً اعمال می‌شود، کنار آن بنویسید. اگر نیاز به دکمهٔ اعمال دارد، خود دکمه باید در نما دیده شود. اگر داده از server می‌آید، loading و خطا را توضیح دهید. Annotation کوتاه باید شرط و نتیجه را بگوید، نه تکرار ظاهر را. مثلاً «پس از پاک کردن فیلتر، تمام درخواست‌های مجاز دوباره نمایش داده می‌شوند» قرارداد روشن‌تری از «این بخش فیلتر است» دارد. اطلاعات باز و قطعی را هم جدا علامت بزنید.
در handoff، مشخص کنید کدام ترتیب برای keyboard و خواندن صفحه مهم است. تغییر بصری ترتیب boxها به تنهایی ترتیب DOM را تعیین نمی‌کند. آیکون بدون متن هم نیاز به نام مناسب دارد. مقالهٔ طراحی آیکون این مرز را توضیح می‌دهد و دسترس‌پذیری به ساختار کنترل‌ها می‌پردازد. Wireframe فرصت خوبی است که این تصمیم‌ها پیش از تبدیل به جزئیات ثابت مطرح شوند.
بازبینی باید task را دنبال کند
از مخاطب بازبینی بخواهید مورد نیازمند اصلاح را پیدا کند و توضیح دهد بعد از انتخاب چه انتظاری دارد. راه درست را با اشاره به دکمه لو ندهید. در بازبینی تیمی، فرض‌های فنی و محتوایی هم باید بررسی شوند. در تست کاربردپذیری، روش مناسب و مشارکت‌کنندهٔ مرتبط لازم است؛ راهنمای رسمی تست moderated این قرارداد را بیان می‌کند. این مقاله چنین جلسه‌ای اجرا نکرده و نتیجهٔ کاربر گزارش نمی‌کند.
یادداشت کنید فرد کدام اطلاعات را دید، کجا مکث کرد و کدام واژه را اشتباه فهمید. «صفحه خوب بود» به اندازهٔ رفتار مشخص برای اصلاح مفید نیست. اگر کاربر مسیر خالی را نمی‌فهمد، فقط افزودن رنگ تازه شاید پاسخ نباشد. اصلاح را به مسئله وصل کنید و دامنهٔ تغییر را حفظ کنید. ممکن است معلوم شود فرض اولیه دربارهٔ نیاز درست نبوده؛ آن را در brief اصلاح کنید، نه اینکه فقط چند box را جابه‌جا کنید.
نسخهٔ بعد باید دلیل تغییر داشته باشد
پس از بازبینی، نام نسخه و تغییر اصلی را کوتاه ثبت کنید. اگر ترتیب اطلاعات عوض شد، علت را همراه تصمیم بنویسید. این یادداشت به عضو جدید تیم کمک می‌کند گزینهٔ کنارگذاشته‌شده را دوباره بدون زمینه پیشنهاد نکند. نسخه‌ها نباید به آرشیو نامنظم از frameهای مشابه تبدیل شوند. برای مسیر نمونه‌سازی، نوشتهٔ کارگاه Figma مراحل را ادامه می‌دهد. آنچه باید حفظ شود، قرارداد و دلیل ساختار است.
Wireframe را تأیید کامل محصول ندانید
یک ساختار قابل فهم هنوز ممکن است در اجرای واقعی با دادهٔ بلند، تأخیر یا محدودیت سیستم مشکل داشته باشد. Visual Design، Prototype و کد هر کدام شاهد متفاوت می‌دهند. اگر یک مسئله در Wireframe حل شده، نتیجه را با همان محدوده گزارش کنید. این ابزار می‌تواند برخی تصمیم‌ها را زودتر قابل گفتگو کند و هزینهٔ بعضی اصلاح‌ها را کم کند، اما حذف همهٔ خطاها را تضمین نمی‌کند. خروجی مفید، ساختاری است که نیاز، رفتار و تصمیم‌های باز آن برای تیم قابل پیدا کردن باشند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!