مدیر واحد در جلسه بازنگری، ده نمودار میبیند اما نمیفهمد کدام یک به تصمیم امروز مربوط است. برای رسیدن به علت افت یک شاخص، سه فایل و دو گزارش جدا باز میکند. در پایان جلسه، کسی یادداشت میکند که «بررسی شود». این تجربه فقط تجربه بد یک صفحه نیست؛ کیفیت اجرای راهبرد را پایین میآورد، چون تحلیل از اقدام جدا میشود و زمان مدیران برای پیدا کردن مسیر میان دادهها صرف میشود.
تجربه کاربر در مدیریت راهبردی باید با کار واقعی مدیر شروع شود. مدیرعامل، مدیر واحد، صاحب ابتکار و کارشناس داده همه یک نما یا یک میزان جزئیات لازم ندارند. اما هر کدام باید بتوانند پاسخ پرسش خود را بدون گم شدن در منوها، تعریفهای مبهم و گزارشهای نامرتبط پیدا کنند. طراحی خوب، اطلاعات را پنهان نمیکند؛ ترتیب دیدن، دلیل بودن و راه اقدام را روشن میکند.
شریف استراتژی یک مشاوره مدیریت است، نه سازنده یک محصول تجربه کاربری. در کار مشاورهای، میتوان جریان تصمیم، نقشه استراتژی، نظام سنجش، ریتم جلسه و نمای مدیریتی را با مدیران روشن کرد. انتخاب، ساخت یا یکپارچهسازی ابزار دیجیتال خارج از این ادعاست مگر اینکه مستندات رسمی خلاف آن را نشان دهد.
کاربر را با نقش او بشناسید، نه با سن او یا مهارت دیجیتال فرضی
مدیر ارشد معمولاً به یک پاسخ فشرده نیاز دارد: کدام هدف از مسیر خارج شده، چه چیزی علت محتمل است و چه تصمیمی باید گرفته شود. صاحب ابتکار به وابستگی، ظرفیت و اقدام باز نیاز دارد. کارشناس داده باید فرمول، منبع، زمان برش و محدودیت شاخص را ببیند. وقتی همه این نیازها روی یک صفحه ریخته شوند، مدیر ارشد از جزئیات خسته میشود و کارشناس از نبود شفافیت شکایت میکند.
به جای ساختن پرسونای مبهم مانند «مدیر نسل جدید»، کارهای واقعی را فهرست کنید. آیا مدیر باید انحراف را تشخیص دهد؟ آیا باید علت را با مسئول واحد بررسی کند؟ آیا باید میان دو پروژه اولویت بدهد؟ آیا باید یک اقدام را تایید یا متوقف کند؟ هر کار، اطلاعات، زمان و سطح دسترسی متفاوت میخواهد. گفتن اینکه کاربر حرفهای است، جای دیدن کار او را نمیگیرد.
پژوهش کاربر در مرحله کشف پیشنهاد میکند پیش از طراحی، بفهمید کاربران چه کاری میخواهند انجام دهند، اکنون چگونه آن را انجام میدهند و کجا با مشکل روبهرو میشوند. این راهنما برای خدمات عمومی دیجیتال نوشته شده، اما در جلسه راهبردی نیز مفید است. قبل از تغییر گزارش، یک مدیر را در حال انجام تصمیم واقعی ببینید؛ نه اینکه فقط بپرسید چه نموداری میخواهد.
نمای اول باید پرسش را کوچک کند
نمای اولِ خوب، پاسخ همه چیز نیست. باید سه چیز را روشن کند: آیا وضعیت به توجه نیاز دارد، کدام هدف یا ابتکار درگیر است و چه سطحی از جزئیات برای تصمیم بعدی لازم است. اگر مدیر باید ده دقیقه صرف تشخیص مسئله کند، حتی دقیقترین نمودار هم در جلسه کاربرد محدودی دارد.
این به معنی استفاده اجباری از رنگ، کارت یا نمودار خاص نیست. یک جدول کوتاه با هدف، وضعیت، روند، علت ثبتشده، اقدام و موعد میتواند از داشبورد پرزرقوبرق مفیدتر باشد. اصل این است که هر المان پاسخ یک سؤال تصمیم باشد. نموداری که به هیچ تصمیم، توضیح علت یا اقدام بعدی وصل نیست، شاید برای ارائه زیبا باشد اما در چرخه اجرا نویز ایجاد میکند.
در طراحی داشبورد پایش استراتژی، هدف، سنجه، فاصله، علت انحراف، اقدام اصلاحی، مالک و موعد در یک جریان تصمیممحور کنار هم قرار میگیرند. این منطق به مدیر کمک میکند از جمله «عدد بد است» به سؤال «چه کسی تا چه زمانی چه گزینهای را بررسی میکند؟» برسد. این یک اصل مدیریتی است، نه مشخصات یک نرمافزار.
خستگی شاخصی معمولاً از تعداد زیاد عددها آغاز میشود، اما علت عمیقتر، نبود اولویت است. اگر ده سنجه همگی «حیاتی» اعلام شوند، هیچکدام در لحظه تصمیم حیاتی نیستند. برای هر جلسه، چند سنجه محدود انتخاب کنید و بقیه را به عنوان داده پشتیبان نگه دارید. این کار داده را حذف نمیکند؛ مسیر توجه را با تصمیم همراستا میکند.
جزئیات باید با حفظ زمینه باز شوند
مدیر پس از دیدن انحراف باید بتواند به جزئیات برود، اما نباید فراموش کند چرا وارد آن جزئیات شده است. اگر مدیر از نرخ تحویل به فهرست سفارشها میرود، صفحه بعد باید هدف، بازه زمانی و تعریف شاخص را نگه دارد. در غیر این صورت، افراد در میان جدولهای دقیق گم میشوند و هنگام بازگشت به جلسه، رشته تحلیل از دست رفته است.
لایه دوم میتواند علتهای ثبتشده، روند، مقایسه با هدف، تغییر منبع داده و وابستگیهای مرتبط را نشان دهد. لایه سوم باید به اقدام برسد: چه گزینهای روی میز است، چه کسی تصمیم میگیرد، چه اطلاعاتی کم است و موعد بازنگری چیست. این ترتیب از نمای کلان به علت و سپس اقدام، با افشای تدریجی اطلاعات سازگار است. هدف، پنهان کردن داده نیست؛ جلوگیری از تحمیل جزئیات نامربوط به کسی است که هنوز مسئله را تشخیص نداده.
ISO 9241-11 کاربرپذیری را در متن اثربخشی، کارایی و رضایت در یک زمینه استفاده تعریف میکند. برای گزارش راهبردی، زمینه استفاده همان تصمیم و زمان مدیر است. صفحهای که در آزمایش طراحی زیبا به نظر میرسد اما مدیر نمیتواند با آن اولویت پروژه را تشخیص دهد، در زمینه واقعی کاربرپذیر نیست.
در نقشه استراتژی و روابط علّی اهداف، فرضیههای رابطه میان هدفها برای گفتوگو و اتصال به سنجه و ابتکار دیده میشوند. این نقشه میتواند زمینه لایههای اطلاعات را نگه دارد: مدیر وقتی وارد جزئیات میشود، هنوز میداند کدام هدف بزرگتر و کدام فرض راهبردی پشت آن است.
زبان بصری باید معنا را ثابت نگه دارد
اگر رنگ قرمز گاهی معنی تاخیر، گاهی معنی بودجه و گاهی معنی کیفیت داده بدهد، مدیر باید پیش از تصمیم گرفتن زبان گزارش را ترجمه کند. همین مشکل در نمودارها، نام شاخصها و حالتهای وضعیت رخ میدهد. استانداردسازی بصری یعنی هر نشانه در زمینه خودش یک معنای مشخص داشته باشد، نه اینکه همه صفحهها شبیه هم باشند.
برای مثال، وضعیت یک شاخص میتواند از هدف عقب باشد، اما داده آن هنوز موقت باشد. این دو موضوع باید از هم جدا دیده شوند. اگر رنگ قرمز برای هر دو به کار رود، مدیر نمیداند باید اقدام اصلاحی را پیگیری کند یا ابتدا داده را معتبر سازد. یک یادداشت کوتاه درباره زمان داده، منبع و درجه اطمینان گاهی از افزودن نمودار دیگر ارزشمندتر است.
دسترسیپذیری نیز بخشی از وضوح است. صرف تکیه بر رنگ، متن ریز، آیکون بینام یا اصطلاح فنی، استفاده را برای بخشی از کاربران دشوار میکند. متن کوتاه، برچسب روشن و ترتیب قابل پیشبینی به مدیران کمک میکند حتی در جلسه پراسترس، معنی گزارش را حفظ کنند. طراحی برای وضوح، سادهسازی کودکانـه نیست؛ احترام به ظرفیت توجه افراد است.
اقدام باید آسانتر از راه فرار باشد
بسیاری از چرخههای پایش در لحظه تحلیل متوقف میشوند. مدیران علت را میبینند، درباره آن گفتوگو میکنند و سپس اقدام را در پیامرسان یا دفترچه جدا ثبت میکنند. در دوره بعد، گزارش هنوز انحراف را نشان میدهد اما معلوم نیست چه کاری قرار بود انجام شود. تجربه خوبِ اجرای راهبرد باید ثبت اقدام را بخشی طبیعی از دیدن انحراف کند.
برای هر اقدام، چهار فیلد کافی است: اقدام چیست، مالک کیست، تا چه زمانی باید بررسی یا انجام شود و کدام شواهد در بازنگری بعدی نتیجه آن را نشان میدهند. اگر ثبت اقدام به فرم بلند و چند تایید نیاز داشته باشد، افراد راه کوتاهتر بیرون از جریان را انتخاب میکنند. اگر بیش از حد ساده باشد، تعهد مبهم میماند. نقطه درست، ثبت حداقل اطلاعاتی است که جلسه بعد بتواند بر اساس آن تصمیم بگیرد.
استقرار و پایش اجرای استراتژی بر تفکیک مالک نتیجه، مالک اقدام و نقش دفتر استراتژی، همراه با جلسه بازنگری و خروجی قابل پیگیری تاکید دارد. تجربه تصمیم زمانی خوب است که این نقشها به زبان ساده در مسیر کار دیده شوند، نه اینکه فقط در آییننامه باقی بمانند.
با کاربر واقعی آزمون کنید، نه با نظر جلسه طراحی
مدیران و طراحان گزارش اغلب درباره سادگی صفحه توافق دارند، چون قبلاً در ساخت آن دخیل بودهاند. آزمون واقعی زمانی است که فردی با یک سناریوی معمول تلاش کند تصمیمی را انجام دهد: شاخص عقبمانده را پیدا کند، دلیل را ببیند، اقدام قبلی را بررسی کند یا داده موقت را تشخیص دهد. اگر فرد به کمک سازنده گزارش نیاز دارد، مسیر هنوز روشن نیست.
آزمون کاربرپذیری هدایتشده مشاهده کاربر در انجام یک کار مشخص و درخواست فکرکردن با صدای بلند را برای آشکار کردن مشکل زبان، چیدمان و مسیر توصیه میکند. در فضای راهبردی، لازم نیست آزمایشگاه بسازید. یک جلسه کوتاه با مدیر یا کارشناس واقعی، داده نمونه و یک کار معتبر میتواند نشان دهد کدام بخش گزارش او را معطل میکند.
پژوهش کاربر به نظرسنجی رضایت محدود نیست. ممکن است مدیر از صفحه خوشش بیاید اما نتواند با آن تصمیم بگیرد. ممکن است کارشناس بگوید فرم ساده است اما به دلیل ابهام تعریف، داده را بهروز نکند. مشاهده کار، زمان تکمیل و خطاهای مسیر شواهد بهتری از کاربرد گزارش میدهند. سپس باید یک تغییر کوچک اعمال شود و آزمون دوباره انجام گیرد.
سنجش کاربرپذیری نیز ترکیب سنجه عملکرد با مشاهده کاربر و تکرار دورهای آزمون را پیشنهاد میکند. برای گزارش راهبردی، میتوان زمان تشخیص انحراف، نرخ تکمیل اقدام، تعداد درخواستهای توضیح و نتایج آزمون سناریو را کنار هم دید. هیچ عددی به تنهایی تجربه مدیر را توضیح نمیدهد.
تغییر گزارش، تغییر رفتار است
اگر گزارش تازه اطلاعاتی را برجسته کند که سابقاً دیده نمیشد، نقشها و گفتوگوها نیز تغییر میکنند. مدیر واحد شاید احساس کند بیشتر قضاوت میشود، کارشناس داده شاید بار ثبت بیشتری ببیند و مدیر ارشد شاید با مسئلههایی مواجه شود که قبلاً پنهان بودند. اینها نقص تجربه کاربر نیستند؛ بخشی از تغییر رفتار سازمانیاند و باید در طراحی چرخه اجرا دیده شوند.
برای کاهش اصطکاک، از ابتدا توضیح دهید گزارش برای چه تصمیمی ساخته شده، کدام داده فقط برای یادگیری است و کدام داده در ارزیابی رسمی به کار میرود. بازخورد درباره صفحه را از ارزیابی فرد جدا نگه دارید. اگر کاربر تصور کند هر خطا در آزمون گزارش به حساب عملکرد او نوشته میشود، رفتار واقعی خود را نشان نمیدهد و پژوهش تجربه کاربر بیفایده میشود.
ISO 9241-210 طراحی انسانمحور را در سراسر چرخه عمر سیستمهای تعاملی قرار میدهد. برای گزارش و جلسه راهبردی، این یعنی بازخورد کاربر یک مرحله پایان کار نیست. هر بار که هدف، نقشها یا شرایط تصمیم تغییر میکنند، باید دید آیا اطلاعات و مسیر اقدام هنوز با کار واقعی هماهنگاند.
کیفیت فنی و کیفیت تصمیم را با هم بررسی کنید
کاربرپذیری فقط مسیر کلیک نیست. اگر گزارش در زمان جلسه باز نشود، منبع داده دیر برسد یا خروجی چاپی با آنچه مدیر روی صفحه میبیند فرق کند، تجربه تصمیم آسیب میبیند. تیم نباید سرعت فنی را به تنهایی شاخص موفقیت بداند، اما باید بداند کدام تاخیر یا خطا باعث میشود مدیر به فایل شخصی یا حدس خود برگردد. ثبت رخدادهای فنی در کنار بازخورد کاربر، تصویر کاملتری از تجربه کار میسازد.
تضمین کیفیت خدمت GOV UK پیشنهاد میکند کاربرپذیری در کنار امنیت، پایداری و عملکرد فنی آزموده شود. در چرخه راهبردی نیز این تفکیک مهم است: گزارش شاید در دسترس باشد اما برای کاربر قابل فهم نباشد، یا شاید طراحی خوب داشته باشد اما دادهاش بهموقع نرسد. کیفیت تصمیم وقتی بالا میرود که هر دو مسئله در یک برنامه بهبود دیده شوند.
یک روش ساده، ثبت رخدادهای جلسه است. چند دقیقه برای پیدا کردن گزارش صرف شد؟ آیا مدیر مفهوم شاخص را پرسید؟ آیا داده با گزارش دیگر تناقض داشت؟ آیا اقدام بدون مالک ماند؟ این رخدادها در ابتدا کیفیاند، اما پس از چند جلسه الگو میسازند. سپس تیم میتواند میان اصلاح تعریف، تغییر چیدمان، کوتاه کردن مسیر دسترسی یا بازطراحی ریتم داده انتخاب کند.
همچنین باید میان نمای مدیریتی و گزارش تحلیلی مرز بگذارید. نمای مدیریتی برای تشخیص مسئله و انتخاب اقدام است. گزارش تحلیلی برای بررسی فرض، جزئیات و شواهد. وقتی هر دو در یک صفحه جمع شوند، مدیر نگاه سریع را از دست میدهد و کارشناس امکان بررسی دقیق را. دو خروجی میتوانند از یک تعریف مشترک تغذیه شوند، اما لازم نیست تجربه یکسانی ایجاد کنند.
هر تغییر تجربه کاربر باید یک فرض قابل آزمون داشته باشد. مثلاً اگر علت انحراف کنار شاخص دیده شود، مدیر سریعتر تصمیم میگیرد. اگر این فرض تایید نشد، شاید علت ثبتشده بیکیفیت بوده، سطح جزئیات کافی نبوده یا اختیار تصمیم روشن نبوده است. تجربه کاربر با همین چرخه کوتاه از سلیقه صفحه به یادگیری درباره کار واقعی تبدیل میشود.
بهبود را با یک تصمیم پرتکرار آغاز کنید
برای آغاز، یک تصمیم پرتکرار انتخاب کنید؛ مثلا اولویتبندی ابتکارها، تشخیص انحراف فروش یا پیگیری اقدام اصلاحی. با سه مدیر یا کارشناس واقعی، مسیر فعلی آن تصمیم را مرور کنید. چه چیز را ابتدا میبینند، در کجا متوقف میشوند، چه توضیحی لازم دارند و در پایان چه چیزی باید ثبت شود؟ سپس نمای اول، لایه جزئیات و ثبت اقدام را فقط برای همان کار اصلاح کنید.
در دوره بعد، همان کار را بدون کمک سازنده گزارش دوباره آزمون کنید. اگر کاربر سریعتر به مسئله میرسد، علت را میفهمد و اقدام قابل پیگیری ثبت میکند، مسیر درستی دارید. اگر نه، نمودار بیشتر اضافه نکنید؛ تعریف، زبان، ترتیب اطلاعات یا اختیار تصمیم را اصلاح کنید. تجربه کاربر خوب در اجرای راهبرد زمانی دیده میشود که مدیر از دیدن یک عدد، به تصمیمی برسد که هفته بعد بتوان آن را پیگیری کرد.
اگر این مسیر برای یک تصمیم کار کند، آن را برای همه صفحهها کپی نکنید. کار بعدی را از تصمیمی انتخاب کنید که بیشترین زمان جلسه را میگیرد یا بیشترین اقدام بیپیگیری را تولید میکند. تجربه خوب از تکرار یک الگو به وجود نمیآید؛ از دیدن تفاوت کارها و اصلاح آرام هر کدام شکل میگیرد.
