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