داشبورد مدیریتی را از سؤال روزانه کاربر طراحی کنید. مدیر پشتیبانی ممکن است بخواهد درخواست‌های معطل را پیدا کند و سرپرست فروش بخواهد سفارش‌های نیازمند پیگیری را ببیند. قرار دادن چند نمودار و عدد در صفحه، این دو نیاز را خودکار پاسخ نمی‌دهد. پیش از انتخاب رنگ و کارت، مشخص کنید کاربر پس از دیدن هر بخش چه تصمیمی می‌گیرد و برای اجرای آن تصمیم به کجا می‌رود.
در یک نمونه فرضی برای مدیریت سفارش، کار اصلی می‌تواند یافتن سفارش‌هایی باشد که پرداخت شده‌اند اما ارسال نشده‌اند. این نمونه، داده یا نتیجه یک مشتری واقعی نیست. آن را برای توضیح رابطه شاخص، فیلتر و جدول استفاده می‌کنیم. صفحه مناسب این کار، زمان آخرین به‌روزرسانی و وضعیت ارسال را نشان می‌دهد و اجازه می‌دهد کاربر از خلاصه به سفارش‌های مربوط برسد.
نقش و اختیار کاربر را قبل از صفحه روشن کنید
فهرست نقش‌ها را به اسم شغل محدود نکنید. ببینید هر نقش چه اطلاعاتی لازم دارد و چه عملی انجام می‌دهد. مشاهده یک سفارش، اصلاح نشانی و لغو پرداخت اختیارهای متفاوتی‌اند. طراحی باید این تفاوت را در محل عمل توضیح دهد؛ مخفی کردن یک دکمه در رابط، جای کنترل دسترسی سمت سرور را نمی‌گیرد. کاربر هم باید بفهمد چرا عملی برای او در دسترس نیست.
برای نقش کم‌اختیار، نمایش اطلاعات غیرضروری ممکن است صفحه را شلوغ و داده حساس را آشکار کند. از تیم محصول بپرسید هر ستون برای چه تصمیمی لازم است. اگر شماره کامل تماس فقط هنگام پیگیری لازم می‌شود، نمایش دائمی آن در همه فهرست‌ها نیاز به توجیه دارد. این تصمیم بخشی از طراحی تجربه و قرارداد داده است و باید با نیاز عملیاتی هماهنگ شود.
مصاحبه را با درخواست توضیح یک کار واقعی پیش ببرید: آخرین سفارش مشکل‌دار را چگونه پیدا کردید، چه اطلاعاتی کم داشتید و بعد چه کاری انجام دادید؟ پاسخ درباره مسیر عمل از درخواست کلی «یک داشبورد زیبا» مفیدتر است. اگر کاربر در عمل از فایل بیرونی استفاده می‌کند، دلیل آن را بررسی کنید؛ شاید فیلتر لازم یا تعریف قابل اعتماد شاخص در محصول وجود ندارد.
هر KPI باید تعریف و مسیر پیگیری داشته باشد
«فروش امروز» بدون تعریف می‌تواند مبلغ ثبت سفارش، پرداخت موفق یا مبلغ پس از مرجوعی باشد. کنار شاخص، دوره زمانی و واحد را مشخص کنید و توضیح تعریف را در محل قابل دسترس بگذارید. اگر شاخص با داده دیگری مقایسه می‌شود، دوره‌ها باید قابل مقایسه باشند. ساعت میانی روز را با یک روز کامل مقایسه نکنید و تغییر ظاهری را به رشد کسب‌وکار نسبت ندهید.
برای عدد خلاصه، مسیر رسیدن به اقلام سازنده آن فراهم کنید. کلیک روی «سفارش‌های منتظر ارسال» باید فهرستی با همان تعریف و فیلتر باز کند. اگر تعداد کارت و جدول متفاوت است، تفاوت منبع، تأخیر یا محدوده را توضیح دهید. کاربری که نتواند عدد را پیگیری کند، برای تصمیم مهم مجبور است از جای دیگری تأیید بگیرد.
عدد صفر با نبود داده یکسان نیست. صفر یعنی داده معتبر نشان می‌دهد موردی وجود ندارد؛ نبود داده ممکن است از شکست دریافت، دسترسی محدود یا دوره نامعتبر ناشی شود. نمایش صفر در خطای شبکه معنای نادرستی می‌سازد. برای هر شاخص، قرارداد حالت loading، unavailable و مقدار معتبر را تعریف کنید. همین قرارداد باید در export و گزارش‌های دیگر هم رعایت شود.
چیدمان را با جریان کار بسنجید
قرار دادن اطلاعات مهم در بالا و چپ، قانون عمومی برای تمام داشبوردها نیست. جهت نوشتار، عرض صفحه و هدف کار تعیین‌کننده‌اند. در رابط فارسی، ترتیب خواندن و محل آغاز گروه‌ها با رابط LTR متفاوت است. به جای تحمیل یک الگوی ثابت، مسیر نگاه و حرکت کاربر را با محتوا و کار مشخص بررسی کنید. اطلاعات فوری باید زود پیدا شود، ولی همه اطلاعات فوری هم‌ارزش نیستند.
گروه‌بندی بر اساس تصمیم معمولاً از گروه‌بندی صرف بر اساس نوع نمودار واضح‌تر است. سفارش‌های نیازمند اقدام را با علت و عمل مرتبط کنار هم بگذارید. گزارش روند را در بخشی جدا قرار دهید تا بررسی روزانه با تحلیل دوره‌ای مخلوط نشود. اگر یک صفحه باید هر دو کار را انجام دهد، عنوان بخش و ناوبری داخلی باید تفاوت را نشان دهد.
فضای خالی برای جدا کردن گروه‌ها مفید است، اما کارت‌های بزرگ کم‌محتوا ممکن است جدول کاری را بیش از حد پایین ببرند. میزان تراکم را با طول داده واقعی تنظیم کنید. عنوان چندکلمه‌ای، رقم بزرگ و نام طولانی مشتری را در طراحی بیاورید. نمونه‌ای که فقط متن کوتاه و اعداد مرتب دارد، مشکلات صفحه واقعی را پنهان می‌کند.
جدول را برای خواندن و اقدام طراحی کنید
برای داده‌هایی که باید سطر به سطر مقایسه شوند، جدول اغلب از مجموعه کارت‌ها مناسب‌تر است. ستون اصلی باید هویت رکورد را روشن کند و وضعیت‌ها نام قابل فهم داشته باشند. واحد مبلغ در عنوان یا سلول مشخص باشد. تاریخ هم با تقویم و منطقه زمانی مورد انتظار کاربر نمایش داده شود؛ عددی که در export معنای دیگری پیدا کند اعتماد به گزارش را کم می‌کند.
راهنمای Table در WAI-ARIA APG استفاده از HTML table بومی را، وقتی مناسب است، توصیه می‌کند و آن را از grid تعاملی تفکیک می‌کند. وجود دکمه داخل یک سلول، به تنهایی دلیل تبدیل کل جدول به grid نیست. Grid قرارداد Keyboard پیچیده‌تری دارد و انتخاب آن باید برای رفتار واقعاً لازم باشد، نه فقط ظاهر شبیه صفحه‌گسترده.
عنوان ستون، caption و رابطه header با سلول‌ها را در پیاده‌سازی حفظ کنید. برای مرتب‌سازی، نام دکمه و جهت فعلی روشن باشد. اگر فقط یک آیکون کوچک تغییر کند، کاربر Screen Reader ممکن است از ترتیب جدید خبر نداشته باشد. تغییر ترتیب باید با وضعیت برنامه‌ای مناسب مانند aria-sort همراه شود و Focus بی‌دلیل از کنترل کاربر نپرد.
فیلترها باید قابل توضیح و قابل بازگشت باشند
فیلتر فعال را کنار نتایج قابل مشاهده نگه دارید. کاربر باید بفهمد فهرست به چه دلیل محدود شده و چگونه محدودیت را پاک کند. عبارت «همه» هم باید محدوده مشخص داشته باشد: همه سفارش‌های قابل دسترسی، همه دوره یا همه وضعیت‌ها؟ اگر فیلتر پیش‌فرض دارید، آن را پنهان نکنید؛ ممکن است کاربر با فرض دیدن کل داده تصمیم بگیرد.
برای جست‌وجو، نوع تطابق را روشن کنید. جست‌وجوی کد سفارش با جست‌وجوی نام مشتری رفتار متفاوتی دارد. ورودی رقم فارسی و لاتین را مطابق قرارداد محصول مدیریت کنید و تبدیل را برای شناسه‌های حساس خودسرانه تعمیم ندهید. اگر نتیجه پیدا نشد، متن باید به اصلاح جست‌وجو کمک کند؛ پیام «چیزی وجود ندارد» ممکن است نبود رکورد در کل سامانه را القا کند.
ثبت فیلتر در URL، وقتی داده حساس را آشکار نمی‌کند، بازگشت و اشتراک مسیر را آسان‌تر می‌کند. وضعیت pagination و sort نیز باید با همین قرارداد هماهنگ باشد. پس از بازگشت از جزئیات سفارش، کاربر نباید مجبور شود تمام فیلترها را دوباره بسازد. برای مقادیر محرمانه، روش مناسب دیگری انتخاب کنید و آن‌ها را صرفاً برای راحتی در URL عمومی ننویسید.
عملیات گروهی را با محدوده روشن ارائه کنید
انتخاب همه رکوردهای صفحه با انتخاب همه نتیجه‌های فیلتر فرق دارد. تعداد و محدوده انتخاب را قبل از عملیات گروهی نشان دهید. اگر کاربر صفحه را عوض می‌کند، رفتار حفظ انتخاب باید مشخص باشد. تغییر فیلتر هم ممکن است رکوردهای انتخاب‌شده را از دید خارج کند؛ حفظ بی‌توضیح آن‌ها خطر اجرای عمل روی موارد فراموش‌شده را ایجاد می‌کند.
برای عملی مانند لغو سفارش، پیام تأیید باید خود عمل و اقلام مربوط را نام ببرد. دکمه «بله» در چند پنجره متفاوت اطلاعات کافی ندارد. اگر بازگردانی ممکن است، مسیر آن را توضیح دهید. اگر عملیات بخشی موفق و بخشی ناموفق شد، نتیجه را تفکیک کنید؛ اعلام موفقیت کلی باعث می‌شود کاربر موارد باقی‌مانده را پیگیری نکند.
به‌روزرسانی نتایج پس از عملیات باید با داده معتبر هماهنگ باشد. برای عملیات طولانی، وضعیت پیشرفت و امکان ادامه کار را تعریف کنید. معیار Status Messages توضیح می‌دهد چگونه پیام‌های وضعیت بدون انتقال Focus برای فناوری کمکی قابل تشخیص شوند. هر تغییر کوچک را با alert فوری اعلام نکنید؛ اعلان‌های زیاد می‌توانند کار را مختل کنند.
عرض کوچک را بر اساس کار مهم طراحی کنید
روی موبایل، مخفی کردن تصادفی ستون‌ها ممکن است اطلاعات لازم برای تصمیم را حذف کند. ابتدا کار اصلی در عرض کوچک را مشخص کنید. شاید مشاهده وضعیت و پیگیری یک سفارش لازم باشد، اما تحلیل چند نمودار هم‌زمان اولویت نداشته باشد. سطر خلاصه می‌تواند اطلاعات ضروری را نگه دارد و جزئیات را با مسیر واضح باز کند؛ کاربر نباید معنی ستون حذف‌شده را حدس بزند.
برای جدول نیازمند مقایسه افقی، scroll محدود داخل ناحیه جدول می‌تواند مناسب باشد. کنترل‌ها و عنوان صفحه نباید همراه آن از دید خارج شوند. وجود این ناحیه را قابل تشخیص کنید و امکان استفاده با Keyboard را در طراحی در نظر بگیرید. تبدیل همه سطرها به کارت همیشه پاسخ بهتری نیست؛ مقایسه مقدارهای چند رکورد ممکن است دشوارتر شود.
برای layout componentها، مقاله Container Queries کمک می‌کند اندازه محل قرارگیری را در نظر بگیرید. در داشبورد، Sidebar باز یا بسته می‌تواند فضای بخش اصلی را تغییر دهد، حتی اگر viewport ثابت باشد. واکنش component به فضای خودش باید همراه محدودیت طول متن و ترتیب محتوای مهم طراحی شود.
با سناریوی تصمیم، کیفیت را ارزیابی کنید
در جلسه بررسی، از کاربر بخواهید یک سفارش معطل را پیدا کند، علت را بخواند و اقدام مناسب را انتخاب کند. محل سردرگمی را ثبت کنید، نه فقط نظر او درباره زیبایی صفحه. زمان انجام کار، خطا و نیاز به کمک، داده‌های قابل بررسی‌اند؛ بدون اندازه‌گیری، ادعای چند برابر شدن بهره‌وری نسازید. تغییر کوچک در نام وضعیت گاهی مسئله‌ای را حل می‌کند که نمودار تازه حل نمی‌کند.
برای تحویل، تعریف شاخص‌ها، حالت‌های داده و رفتار فیلتر را کنار طراحی ثبت کنید. مقاله UX Writing برای متن عمل و پیام خطا ادامه مرتبط است. داشبورد زمانی قابل نگهداری می‌شود که طراح و توسعه‌دهنده درباره معنای داده و نتیجه عمل توافق داشته باشند؛ این توافق باید در نسخه بعدی محصول هم قابل پیگیری بماند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!