داشبوردی که تصمیم میسازه، نه فقط عدد نشون میده
خلاصهٔ کاملتر
تو خیلی از استندآپهای هفتگی یه اتفاق تکراری میافته: یکی عددها رو نشون میده، جمع سر تکون میدن، و جلسه بدون تصمیم تموم میشه. مریم بنحبیلس تو اسمشینگ مگزین میگه معمولاً داده رو مقصر میکنیم، ولی مشکل تقریباً هیچوقت خود داده نیست: نمودار از روی چیزی ساخته شده که دم دست بوده، نه از روی سؤالی که باید جواب میگرفت.
نویسنده با انسکومب شروع میکنه: سال ۱۹۷۳ چهار مجموعه داده ساخت با میانگین، واریانس، همبستگی و خط رگرسیون یکسان، که رسمشون هیچ شباهتی به هم نداره. تافتی هم نسبت data-ink رو گذاشت، یعنی هر علامت روی نمودار باید به داده خدمت کنه نه به تزئین. ولی به گفته نویسنده اون قاعده فقط برای نمودارِ تنهاست، و لختکردن بیش از حد ممکنه همون لایهای رو برداره که تصمیمگیرنده لازم داشت.
سؤال اول Context ـه: با این داده میخوایم چی نشون بدیم؟ «بگو محصول چطور کار میکنه» هدف نیست، ولی «کدوم قابلیتها روی موندگاری کاربرهای ثبتنامی Q1 اثر میذارن» هست، چون هم متریک داره، هم جامعه مشخص، هم یه کنش ضمنی. مثال مقاله یه چکاوت نشتیه: رویکرد دادهمحور کلیک و عمق اسکرول و نوع دستگاه رو میریزه رو صفحه؛ رویکرد سؤالمحور یه قیف ساده میسازه و گلوگاه صفحه پرداخت رو نشون میده.
سؤال دوم Audience ـه و به دو چیز برمیگرده: آشنایی با داده، و پاسخگو بودن. یه داشبورد چگال رو دادن دست مدیر فروش و دست تحلیلگر ارشد مثل اینه که یه نقشه رو بدی به کسی که با نشونه راه میره و کسی که مختصات میخونه؛ داده درسته ولی فقط برای یکیشون کار میکنه. افت ۱۲ درصدی هم برای مدیری که جوابگوی اون عدده وزن دیگهای داره تا تحلیلگری که فقط گزارشش میکنه.
سؤال سوم Insight ـه: بعد از دیدن این داده چی باید عوض بشه؟ داشبورد اطلاعاتی فقط زنگ خطر میزنه، مثلاً افت ۱۵ درصدی نرخ رزرو رو نشون میده و مدیریت فوری تیم UX رو صدا میزنه چون فکر میکنه اپ خرابه. داشبورد بینشی همون افت رو کنار منابع ترافیک و زمان کمپینها میذاره و معلوم میشه اپ سالمه و نرخ کل با هجوم ترافیک کمکیفیت یه کمپین تازه رقیق شده. یعنی بهجای ریدیزاین بیمورد، کمپین رو نگه میدارن.
نکات کلیدی:
- به گفته مقاله حدود ۸۰ درصد چیزی که موفقیت داشبورد رو تعیین میکنه قبل از کشیدن اولین نمودار اتفاق میافته
- یه هدف واقعی سه جزء داره: متریک، جامعه مشخص، و کنشی که ازش درمیاد
- نسبت data-ink تافتی برای نمودار تنها درسته؛ تو بستر واقعی، سادهسازی بیش از حد میتونه لایه لازم برای تصمیم رو حذف کنه
- تحلیلگر به محیط پرچگالی برای کشف نیاز داره، مدیر به ترجمه فشردهای که فوری بگه چی رشد رو جلو میبره
- تو پروژه پلتفرم B2B، نویسنده بهجای «زمان صرفشده» سراغ نمره شایستگی، نرخ تکمیل گواهی و روند تاریخی رفت و برای هشت حوزه شایستگی نمودار رادار رو انتخاب کرد
- رنگ هر محصول از مرحله برندینگ داخل مدل داده نشست، پس کاربر از اولین بازدید زبان داشبورد رو بلد بود
