همینطور که بیشتر مردم ممکنه فکر کنند، این نوشته درباره ی طراحی بسترمحور، با یک پست «کدام رابط کاربری بهتر است» در لینکدین بود که فکر نوشتنش به سرم افتاد.
مطمئنم میدونید درباره ی چی حرف میزنم. یه قالب استاندارد که از دو رابط کاربری، یک گزینه ی رای دادن برای هرکدوم و همراه با سوالی تشکیل شده که بینندگان پست رو اینطوری مخاطب قرار میده: "کدام رابط کاربری بهتر است؟"
این، تمام محتوای پست های این مدلیه. همین و بس. هیچ توضیحات و اطلاعاتی درباره ی پس زمینه، وجود نداره. هیچ چیز. فقط به عکسها نگاه کن و رای بده.
جدای از اعداد و ارقام و حجم تعاملی که کسب میکنند، به شخصه خیلی مطمئن نیستم این نوع پست ها قرار است دقیقاً چه دستاوردی را کسب کنند؛ اما اخیراً با کامنت ها و پست هایی روبرو شده ام که مشکل این مدل نظر سنجی ها را توضیح میدهند.
طراحی بسترمحور چیه؟
چند روز پیش با یه پست در Reddit مواجه شدم. طراحی پرسیده بود:
"اگر من 80 ستون در یک جدول داشته باشم، به نظرتون اسکرول افقی تنها راه برای طراحی تجربه ی کاربری جدول منه؟"
بیشترین واکنش هایی که دیدیم از این دست بود: واکنش هایی سریع و فکر نشده که "اووووه! 80 تا ستون! چه خبره؟ خیلی زیاده."
اما بعضی وقتها، این دقیقاً کاریه که باید انجام بدی. بعضی وقتها، این دقیقاً چیزیه که مردم(به عنوان کاربران نهایی اون جدول) میخوان. اسکرول افقی در جدولی عریض و طویل!
این یعنی طراحی بسترمحور.
طرحی که به وجود اومده تا نیاز های کاربرِ هدفش رو پاسخ بده، صرف نظر از اینکه ممکنه چقدر در بحث زیبایی شناختی، شاهکار به نظر نیاد. به عنوان طراح، درک و سنجش اینکه کاربرهای ما به چی احتیاج دارن بر عهده ی ماست؛ همینطور به وجود آوردن راه حل هایی که هم مفید هستن و هم دلپسند: اما اول مفید، بعد دلپسند.
یک طرح که برای یک کاربر محشره، ممکنه برای یک کاربرِ دیگه به کلی غیرقابل استفاده باشه.
برای بیشتر طراحان، طراحی بسترمحور به طور طبیعی سر و کله اش پیدا میشه. بالاخره ما طوری آموزش دیدیم که تجربه ای به وجود بیاریم تا نیازهای کاربرمون رو پاسخگو باشه.
اما دو تا نکته پایین آوردم که بهتره محور هر فرایند طراحی ای باشه:
1-فهم ضروریات
بله! همینقدر ساده. تمام چیزی که لازمه انجام بدیم اینه که موقع خلق راه حل، نیازهای کاربران و ذینفعان رو جمع کنیم و اون هارو نقطه ی کانونی راه حلمون قرار بدیم. مشخص کردن چهارچوب و بستر، در ابتدایی ترین مراحل فرایند طراحی، به راه حل هامون یه تم و ته مایه ای میبخشه و این در طول سفر ترسیم میشه.
2- تست ایده ها با کاربران
تست کاربر اونقدر ها هم چیز ناشناخته ای نیست. در حالیکه تست کردن یک راه حل با جامعه ی هدف قبل از لانچ کردن اون، به نظر استاندارد میاد، خیلی وقتها این مرحله حذف میشه. در حالیکه در ابتدای فرایند طراحی در حال جمع کردن نیازهای ضروری هستید، امتحان کردن ایده های مختلف با حتی یک راه حل نهایی ضرری نداره و به احتمال زیاد میتونه در انتها موجب موفقیتتون بشه. این مسئله باعث میشه نقش "بستر" دوباره تکرار بشه و بهمون کمک میکنه قبل از لانچ کردن، درباره ی راه حلمون اعتماد به نفس کافی رو داشته باشیم.
نقد کردن یه تمرین مشترکه. طراحان فیدبک های مختلف رو درباره ی طرحاشون جمع میکنند چون اینکه نگاه تازه ای دیزاینشون رو تماشا کنه بهشتون افق های جدیدی رو نشون میده.
زمینه سازی برای مخاطبان قبل از اینکه نقد شروع بشه، مهمترین چیزه. بدون اینکه هیچ اطلاعاتی بدی از اینکه چرا یک طرح اینطوری که هست و به این شکل ویژه ای که هست طراحی شده و چه هدفی پشتش بوده، مخاطبین قادر نخواهند بود که نقد مرتبط و سازنده ای ارائه بدند.
برای دریافت نشانه ها یا ایده هایی که ممکنه در موفقیت یک محصول مفیدِ فایده باشند، مهمه که کسانی که در حال نقدش هستند اطلاعات مرتبطی رو درباره ی تفاوت های ظریف و نادیدنی محصول در دست داشته باشند.
بنابراین، دفعه ی بعدی قبل از اینکه طرحی رو فوراً نقد کنید، بهتره سعی کنید اطلاعات بیشتری درباره ی زمینه ی محصول به دست بیارید و لطفاً از اینکاراتون که میگید "این UI یا اون" توی پست هاتون دست بکشید.
ممنونم که مطالعه کردید!
لینک مقاله:
