دقیقه
27 مهر 1405طرح سایت یا اپلیکیشن را تأیید کرده‌اید و قرار است فایل‌ها به تیم توسعه برسند. چند تصویر از صفحات و یک لینک پروتوتایپ دریافت می‌کنید، اما برنامه‌نویس هنوز نمی‌داند فرم در حالت خطا چه رفتاری دارد، نسخه نهایی کدام است و فایل آیکون‌ها از کجا باید برداشته شود. ظاهر طرح آماده به نظر می‌رسد، ولی تحویل هنوز برای اجرای دقیق کافی نیست.
خروجی طراحی UI/UX باید هم تصمیم‌های طراحی را منتقل کند و هم امکان استفاده از آن‌ها را برای کارفرما و تیم توسعه فراهم کند. این خروجی فقط عکس صفحات نیست؛ بسته به محدوده پروژه، فایل قابل ویرایش، طرح نسخه‌های توافق‌شده، حالت‌های مهم، پروتوتایپ و توضیحات لازم برای پیاده‌سازی را هم در بر می‌گیرد.
در این راهنما بررسی می‌کنیم هنگام تحویل طراحی رابط و تجربه کاربری چه چیزهایی را کنترل کنید و جلسه تحویل چگونه از یک نمایش ظاهری به بررسی قابل پیگیری تبدیل شود. همه پروژه‌ها به تعداد یکسان سند یا جزئیات نیاز ندارند؛ معیار اصلی این است که خروجی‌های توافق‌شده روشن، قابل دسترس و برای ادامه کار قابل استفاده باشند.
تحویل طراحی UI/UX چه تفاوتی با ارائه طرح دارد؟
در ارائه، طراح منطق و ظاهر راه‌حل را توضیح می‌دهد و بازخورد می‌گیرد. در تحویل، باید مرجع مورد تأیید و اطلاعات لازم برای ادامه کار مشخص باشند. ممکن است یک جلسه هر دو هدف را داشته باشد، اما تأیید ظاهر چند صفحه لزوماً به معنی کامل‌بودن بسته تحویل نیست.
عکس، پروتوتایپ و فایل طراحی نقش یکسانی ندارند
تصویر ثابت برای مرور ظاهر مفید است، اما معمولاً اجزای قابل ویرایش و رفتارها را منتقل نمی‌کند. پروتوتایپ، نمونه تعاملی مسیرهای طراحی‌شده است و می‌تواند ارتباط صفحات و بعضی حالت‌ها را نمایش دهد. فایل طراحی، ساختار و اجزایی را در اختیار تیم قرار می‌دهد که برای بررسی یا ادامه طراحی به آن‌ها نیاز دارد. نوع دسترسی به هرکدام باید مطابق توافق روشن باشد.
این خروجی‌ها جای سامانه عملیاتی را نمی‌گیرند. کارکردن لینک‌ها در فیگما به معنی وجود ثبت سفارش واقعی، ذخیره داده یا اتصال پرداخت نیست. اگر قرارداد شامل طراحی و توسعه است، پایان هر مرحله و معیار تحویل آن را جدا مشخص کنید تا تأیید پروتوتایپ با تأیید نرم‌افزار اجراشده اشتباه نشود.
محدوده تحویل باید پیش از پایان پروژه معلوم باشد
فهرست خروجی‌ها را هنگام پیشنهاد و قرارداد بنویسید، نه فقط در جلسه تسویه. نوع صفحات، نسخه‌های موبایل و دسکتاپ، سطح تعامل، اجزای مشترک و همراهی با تیم توسعه باید در محدوده دیده شوند. اگر پژوهش کاربر یا آزمون مشخصی سفارش داده نشده، نباید گزارش انجام آن را جزو خروجی قطعی فرض کرد.
در مقابل، عبارت‌هایی مانند «طراحی کامل» هم نباید جای فهرست قابل بررسی را بگیرند. برای هر خروجی بپرسید چه چیزی دریافت می‌شود و با چه سناریویی می‌توان کامل‌بودنش را سنجید. این شفافیت به مقایسه پیشنهادها و برآورد هزینه نیز کمک می‌کند.
برای بررسی عوامل قیمت، مقاله هزینه طراحی UI/UX چگونه محاسبه می‌شود؟ را بخوانید.
بسته تحویل باید چه تصویری از محصول به ما بدهد؟
کارفرما باید بتواند خروجی را به هدف محصول وصل کند و تیم توسعه باید بفهمد چه تجربه‌ای را می‌سازد. این دو نیاز با فهرستی از نام صفحات به‌تنهایی پوشش داده نمی‌شوند. ارتباط میان نقش‌ها، مسیرها، صفحات و حالت‌های ضروری باید در فایل یا مستند همراه آن قابل فهم باشد.
جمع‌بندی تصمیم‌ها و مسیرهای اصلی کاربر
اگر مرحله شناخت در قرارداد بوده، جمع‌بندی آن باید روشن کند چه نیازهایی مبنای طراحی قرار گرفته‌اند و چه محدودیت‌هایی پذیرفته شده‌اند. لازم نیست همه یادداشت‌های خام در فایل نهایی نمایش داده شوند؛ مهم این است که فرض‌ها و تصمیم‌های مؤثر بر طرح از هم تفکیک شوند و تیم بتواند دلیل انتخاب‌های اصلی را دنبال کند.
مسیرهای کاربر نیز باید از نقطه شروع تا نتیجه مشخص باشند. مثلاً در سامانه نوبت‌دهی، انتخاب خدمت، انتخاب زمان و تأیید درخواست باید در ارتباط با هم دیده شوند. این ارتباط می‌تواند در پروتوتایپ یا نقشه مسیر مستند شود؛ لزوماً برای هر پروژه به چند سند جداگانه نیاز نیست.
صفحات و نسخه‌های توافق‌شده
فهرستی از نوع صفحات و وضعیت تحویلشان بخواهید. صفحه خدمت، آرشیو، جزئیات محصول یا پنل کاربری ممکن است هرکدام الگوی متفاوتی داشته باشند. صفحه تکرارشونده با محتوای متفاوت را از ساختار مستقل جدا کنید تا معلوم باشد چه چیزی واقعاً طراحی شده است.
نسخه‌های لازم نیز باید مشخص باشند. داشتن طراحی دسکتاپ، رفتار منو، جدول یا فرم را در موبایل تعیین نمی‌کند. در عین حال، طراحی دو اندازه ثابت هم به‌تنهایی همه عرض‌های میان آن‌ها را توضیح نمی‌دهد. درباره قواعد تغییر چیدمان، جابه‌جایی اجزا و محدودیت اندازه‌ها توضیح کافی لازم است؛ سطح این توضیح با پیچیدگی پروژه تنظیم می‌شود.
حالت‌های مهم و محتوای واقع‌بینانه
برای مسیرهای اصلی، حالت خالی، بارگذاری، خطا، موفقیت و محدودیت دسترسی را بررسی کنید. اگر کاربر هنوز سفارشی ندارد چه می‌بیند؟ اگر ارسال فرم شکست خورد، چگونه دوباره تلاش می‌کند؟ پاسخ این پرسش‌ها بخشی از طراحی تجربه است و نباید در زمان توسعه صرفاً از روی حدس ساخته شود.
محتوای نزدیک به واقعیت هم اهمیت دارد. نام محصول طولانی، توضیح چندخطی یا تصویر نامتناسب می‌تواند ضعف چیدمان را آشکار کند. لازم نیست همه داده‌های نهایی از ابتدا آماده باشند، اما فرض‌های استفاده‌شده باید معلوم باشند و محدودیت‌های مهم محتوا در تحویل توضیح داده شوند.
چه فایل‌ها و اجزایی برای ادامه طراحی و توسعه لازم‌اند؟
خروجی زمانی قابل استفاده است که دریافت‌کننده بتواند آن را باز کند، بخش نهایی را پیدا کند و اطلاعات مورد نیازش را بردارد. یک لینک بدون دسترسی مناسب یا فایلی پر از نسخه‌های نامشخص، تحویل مؤثری ایجاد نمی‌کند. ابزار مهم است، اما نظم، مستندات و توافق دسترسی نیز به همان اندازه اهمیت دارند.
فایل قابل ویرایش و مرجع نهایی مشخص
فایل منبع باید مطابق قرارداد در دسترس باشد و بخش تأییدشده از اتودها و کارهای در حال تغییر تفکیک شود. نام‌گذاری واضح صفحات و بخش‌ها کمک می‌کند توسعه‌دهنده به نسخه اشتباه رجوع نکند. تاریخ یا شناسه نسخه مرجع را در صورت‌جلسه ثبت کنید تا تغییرهای بعدی قابل پیگیری باشند.
سطح دسترسی کارفرما و تیم توسعه را با نیاز واقعی بسنجید. ممکن است برای بررسی، دسترسی مشاهده کافی باشد، اما برای ادامه طراحی یا انتقال پروژه به فایل قابل ویرایش یا امکان تهیه نسخه مستقل نیاز داشته باشید. مالکیت فضای کاری، اجازه استفاده و مسیر تحویل نسخه پشتیبان را از داشتن صرف یک لینک نتیجه نگیرید.
اجزای مشترک و قواعد ظاهر
رنگ‌ها، تایپوگرافی، فاصله‌ها و اجزایی مانند دکمه، ورودی و کارت باید به شکلی منسجم تعریف شده باشند. حالت غیرفعال یا خطای یک ورودی نیز جزو همین قواعد است. اگر یک جزء در چند صفحه تکرار می‌شود، مشخص باشد کدام مرجع و چه حالت‌هایی مبنای اجرا هستند.
این نیاز الزاماً به معنی سفارش دیزاین سیستم گسترده نیست. یک محصول کوچک ممکن است با مجموعه اجزا و قواعد پایه ادامه یابد؛ محصول چندبخشی به مستندات بیشتری نیاز دارد. دامنه مورد توافق را کنترل کنید و از تحویل تعداد زیادی جزء بدون توضیح کاربرد، کامل‌بودن سیستم را نتیجه نگیرید.
دارایی‌های بصری، فونت‌ها و مجوزها
تصویرها و آیکون‌های مورد نیاز باید قابل شناسایی و با قالب مناسب برای اجرا قابل دریافت باشند. همچنین معلوم شود کدام فایل نهایی است و کدام صرفاً جای‌نگهدار زمان طراحی بوده است. اگر تهیه تصویر یا آیکون نهایی جزو قرارداد نیست، این کمبود باید پیش از شروع توسعه روشن شود.
درباره فونت و دارایی‌های دارای مجوز، منبع و شرایط استفاده را ثبت کنید. وجود فایل در طرح لزوماً اجازه استفاده در سایت یا اپلیکیشن را منتقل نمی‌کند. مشخص کنید تهیه مجوز با چه کسی است و آیا تیم بعدی برای ادامه کار به حساب یا اشتراک دیگری نیاز خواهد داشت.
پروتوتایپ و توضیحات تعامل را چگونه بررسی کنیم؟
یک نمونه تعاملی خوب به کارفرما و تیم کمک می‌کند مسیرهای توافق‌شده را بفهمند، اما قرار نیست تمام رفتار سامانه واقعی را شبیه‌سازی کند. فهرست سناریوهای قابل بررسی و محدودیت‌های نمونه را همراه آن بخواهید تا سکوت طرح درباره یک رفتار با تصمیم قطعی اشتباه نشود.
یک سناریوی کامل را از ابتدا تا پایان اجرا کنید
برای مثال، مسیر ارسال درخواست مشاوره را از صفحه خدمت شروع کنید، به فرم برسید، یک ورودی نامعتبر را بررسی کنید و پیام نتیجه را ببینید. اگر بعضی مرحله‌ها در نمونه تعاملی اجرا نمی‌شوند، توضیح یا طرح حالت آن‌ها را پیدا کنید. هدف روشن‌شدن رفتار است، نه اینکه هر کلیک تزئینی الزاماً شبیه‌سازی شده باشد.
در مسیرهای چندنقشی، نقش دریافت‌کننده درخواست را هم فراموش نکنید. کاربر نهایی چه پیامی می‌بیند و مدیر از کجا نتیجه را بررسی می‌کند؟ اگر این بخش در محدوده طراحی است، باید ارتباطش با مسیر اصلی معلوم باشد؛ اگر خارج از محدوده است، همین موضوع ثبت شود.
رفتارهایی که در تصویر ثابت دیده نمی‌شوند
بازشدن منو، بسته‌شدن پنجره، ترتیب حرکت با صفحه‌کلید، وضعیت فوکوس و نمایش پیام خطا را فقط از ظاهر نمی‌توان استنباط کرد. رفتارهای مهم را با توضیح کوتاه یا نمونه مناسب منتقل کنید. برای حرکت‌ها نیز هدف و حدود آن‌ها روشن باشد تا توسعه به افزودن انیمیشن سلیقه‌ای وابسته نشود.
توضیحات باید متناسب با نیاز باشند. برای یک دکمه استاندارد می‌توان به قاعده مشترک رجوع کرد؛ برای فرایند ویژه، توضیح مستقل لازم است. همچنین با تیم توسعه درباره محدودیت‌های واقعی مرورگر، دستگاه و زیرساخت گفت‌وگو کنید تا تصمیم اجرایی از تغییر بی‌خبر طرح جدا بماند.
جلسه تحویل چه بررسی‌هایی لازم دارد؟
جلسه تحویل بهتر است به چند آزمون روشن ختم شود. فایل را با حساب دریافت‌کننده باز کنید، مرجع نهایی را پیدا کنید و چند سناریوی اصلی را مرور کنید. نتیجه بررسی باید شامل موارد پذیرفته‌شده، ابهام‌ها و کارهای باقی‌مانده باشد؛ صرف گفتن «طرح مورد تأیید است» جزئیات تحویل را ثبت نمی‌کند.
| محور بررسی | آزمون عملی | خروجی جلسه |
|---|---|---|
| دسترسی و نسخه | دریافت‌کننده فایل را باز و نسخه نهایی را پیدا کند | مرجع و سطح دسترسی ثبت شود |
| صفحات و دستگاه‌ها | فهرست محدوده با طرح موبایل و دسکتاپ تطبیق داده شود | موارد تحویلی و باقی‌مانده مشخص شوند |
| تعامل و حالت‌ها | چند مسیر اصلی و حالت خطا مرور شوند | ابهام‌های رفتاری ثبت شوند |
| اجزا و دارایی‌ها | یک جزء و فایل تصویری لازم بررسی شود | منبع، قالب دریافت و مجوز روشن شود |
| ادامه همکاری | روش ثبت سؤال و تغییر پس از تحویل بررسی شود | مسئول و حدود پاسخ‌گویی مشخص شوند |
ابهام طراحی را از درخواست توسعه تازه جدا کنید
اگر رفتار توافق‌شده در طرح روشن نیست، ابتدا همان ابهام را با طراح حل کنید. اضافه‌کردن یک نقش یا فرایند تازه موضوع متفاوتی است و می‌تواند نیازمند برآورد جدید باشد. ثبت این تفاوت کمک می‌کند رفع نقص تحویل با توسعه محدوده مخلوط نشود.
از تیم توسعه هم بخواهید سؤال‌ها را تجمیعی و با اشاره به صفحه یا جزء مشخص مطرح کند. بازخوردی مانند «این بخش قابل اجرا نیست» بدون توضیح محدودیت، تصمیم بعدی را روشن نمی‌کند. بهتر است محدودیت، گزینه پیشنهادی و اثر تغییر بر تجربه در یک گفت‌وگوی مشخص بررسی شوند.
پس از تحویل، مسئولیت طراح تا کجا ادامه دارد؟
تحویل فایل می‌تواند پایان یک مرحله باشد، اما همراهی با توسعه و بازبینی اجرا باید جداگانه تعریف شوند. مدت و دامنه پاسخ‌گویی، تعداد یا حدود بازبینی و نحوه تأیید تغییرهای بعدی را روشن کنید. هیچ‌کدام را از عنوان «طراحی کامل» یا «پشتیبانی» به‌تنهایی برداشت نکنید.
تأیید طراحی و تأیید اجرای نهایی دو مرحله‌اند
ممکن است فایل طراحی درست تحویل شده باشد، ولی نسخه اجراشده در فاصله‌ها، فونت یا رفتار فرم تفاوت داشته باشد. این موضوع به بازبینی پیاده‌سازی مربوط می‌شود و باید مسئول و روش رسیدگی آن معلوم باشد. از طرف دیگر، اگر در زمان توسعه نیاز تازه‌ای مطرح شود، مرجع طرح باید پس از توافق به‌روزرسانی شود تا چند نسخه متناقض باقی نماند.
هدف از مستندات، ساخت محصول نزدیک به تصمیم تأییدشده و کاهش حدس در اجراست. فایل طراحی به‌تنهایی کیفیت نرم‌افزار نهایی را تضمین نمی‌کند؛ هماهنگی طراح، توسعه‌دهنده و کارفرما و آزمون مسیرها نیز لازم است.
در آژانس خلاقیت امین، مسیر طراحی با مصاحبه و شناخت نیازها و رقبا شروع می‌شود و پس از جمع‌بندی، وایرفریم تعاملی با جزئیات بالا برای ارائه آماده می‌شود. با اصلاح و تأیید این مرحله، رابط نهایی موبایل و دسکتاپ با رعایت هویت بصری و اجزای مشترک طراحی می‌شود و سپس به پیاده‌سازی می‌رود. برای تعیین محدوده خروجی‌های پروژه خود، صفحه خدمات طراحی رابط و تجربه کاربری آژانس خلاقیت امین را ببینید.
تحویل قابل استفاده یعنی دریافت‌کننده بداند کدام نسخه مرجع است، چه چیزی طراحی شده و برای ادامه کار به چه اطلاعاتی دسترسی دارد. اگر این سه مورد روشن نیست، پیش از شروع توسعه آن‌ها را مشخص و ثبت کنید.