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