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