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