لعنت به کاربر، مرا باد بزنید.

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

در پای حرف‌های مربوط به «شهر هوشمند» بشینید. حرف‌های مدیران دولتی را در مورد انتظارشان از سامانه‌های مختلف بشنوید: «بتوانیم نظارت کنیم که چه کسی چقدر سوخت مصرف کرده، چقدر پروتئن مصرف کرده، چقدر مسافت پیموده، و ...» و در ادامه، رو به پیمانکار، می‌پرسند: «به نظر شما ایده‌ی ما خوب است؟»
پاسخ بسیار ساده است: «ایده‌ی شما خوب است اما دیدگاه شما صرفا بالا-به-پایین است، باید ارزشی را برای آدم‌هایی که قرار است از این سیستم استفاده کنند خلق کنید».
اما اگر این جواب را بلند بلند بگویید، در ذهن آن‌ها این پرسش به درستی شکل می‌گیرد که «باید؟ کی گفته باید؟ بایدی وجود ندارد!»

حتما به دفاتر پیش‌خوان و شعب شرکت‌ها و دستگاه‌های مختلف مراجعه کردید. این‌ها قرار بود همین خلا را پوشش بدهند که زمانی به «طرح تکریم ارباب رجوع» مشهور شد. اما می‌بینید که یکهو وسط روز کاری، سیستم برای بکاپ گرفتن قطع می‌شود و شمای کاربر سامانه بلاتکلیف توی صف طولانی ماندید با آدم‌هایی که خودشان را با زونکنی از فرم‌ها و فیش‌ها و رسید‌ها باد می‌زنند و در مورد قیمت نفت برنت یا کیفیت فلان پلاس توربو اظهار نظر می‌کنند. بدیهی است که در اینجا دیدگاه غالب که قالب کارها را شکل داده است، همان سوال همیشگی «چگونه سر خودمان را خلوت کنیم» از سوی مدیران است و لزوما «چگونه کاربری را بهینه کنیم» نیست.

نمی‌گویم «آسیب است» و نمی‌خواهم آسیب شناسی کنم. فقط صحبتم این است که اگر کسی به مخاطب و مصرف‌کننده وابسته است، مثل یک فروشگاه مواد غذایی، این راهش نیست و دیدگاهش باید تغییر کند. اگر هم وابسته نیست که اصلا صحبتی نداریم. وابستگی یعنی اگر کاربر نباشد، سیستم بی‌معنی خواهد بود. وابستگی یعنی کاربر تامین کننده‌ی بخشی از موارد ضروری برای نیاز‌های شماست. یعنی که سرویس بهتر دادن به کاربر، باعث رشد و بقای شماست. و البته وابستگی در رقابت معنی پیدا می‌کند. کسی که بی‌رقیب است، کاربرش به معنی دقیق کلمه بی‌چاره است چون در عمل هیچ الزامی برای حمایت از کاربر وجود ندارد و در نتیجه تجربه‌ی کاربر بی‌معنی است.

به عنوان طراح محصول چه کنیم؟

داستان ساده است. ما طراح محصول هستیم و کارِ ما، پیدا کردن نقطه‌ی تعادل است. تعادل بین پیچیدگی و رضایت، رضایت و عملکرد، رضایت مدیر و رضایت کاربر، پول ورودی و هزینه‌های محصول، محدودیت‌های زمانِ حال و نیازهای آینده، انتظار از محصول و نهایی، و ... .

درست است که ما پولمان را از صاحب پروژه می‌گیریم اما باید مشاوری امین برای او باشیم و چشم‌هایش را به تاثیر خلق محصول در وضعیت سایر ذی‌نفعان باز کنیم. فرض کنید آپارتمانی را برای صاحب سرمایه‌ای می‌سازید. او تمایل دارد که کمترین پول را خرج کند. در نتیجه شما به او پیشنهاد می‌دهید که حمام و توالت را از پروژه حذف کنید. او که با شاخص «کاهش هزینه» پیشنهاد شما را می‌سنجد، مشعوف از راه‌کاری که به او نشان داده‌اید با پیش‌نهاد شما موافقت می‌کند. اما اتفاقی که در نهایت می‌افتد این است که هیچ کدام از واحد‌ها فروش نمی‌روند و شما او را به خاک سیاه می‌نشانید.

به عنوان صاحب پروژه چه کنیم؟

باید‌ها و نباید‌ها را مشخص کنید

فهرستی از باید‌ها و نباید‌ها را تهیه کنید که در آن به صورت واضح و بدون هیچ تبصره و انعطافی، خطوط قرمزی را به اندازه‌ی نصف برگه‌ی آ چهار داشته باشید که سه چهارتا قانون بیشتر جا نشود؛ مثل:

• نباید کاربر بیشتر از یک‌بار در سیستم من احراز هویت شود؛ در نتیجه نباید آدم‌هایی را ببینیم که کپی مدارک شناساییشان را در دست دارند و یا منتظر ارسال شناسه‌ی تایید به تلفن همراهشان هستند.
• نباید هیچ روندی با بیش از ۵ مرحله داشته باشیم؛ در نتیجه باید در سطوح دسترسی کارگزاران و کارمندها تغییراتی ارائه کنیم.
• هر کارمند باید روزانه n مراجعه کننده داشته باشد؛ در نتیجه شاهد صف‌ها نخواهیم بود و کارمندان فرسوده نخواهند شد و کارهای انجام نشده را باید یا با روندهای مکانیزه سامان بدهیم یا افزایش تعداد نیرو‌ها.
• باید گزارش مربوط به هر بخش به صورت زنده و بلادرنگ در اختیار مدیران مرتبه‌ی بالاتر قرار بگیرد و آن مدیران دسترسی کافی برای پیگیری امور داشته باشند؛ در نتیجه ساختار سازمانی به سمت کم‌عمق (flat) شدن پیش می‌رود.

این کار پیشتر در کشور استونی انجام شده بود. خانم Anna Piperal که کارشناس دولت الکترونیک است، در یکی از سخنرانی‌های TED خود در این رابطه صحبت کرده بود. ایشان می‌گوید: «توافق روی تعدادی اصول مشترک، مهم، بازطراحی قوانین و رویه‌ها، رهایی از شر جمع‌آوری اطلاعات غیرضروری و تکرار وظایف، و باز و شفاف شدن انجام دادیم». و آن اصول اساسی که عینا نقل قول می‌کنم عبارت بودند از:

• اول، تضمین امنیت و حریم خصوصی داده‌ها و اطلاعات از طریق یک هویت دیجیتالی قوی که توسط دولت تنظیم شده است و با همه چیز در استونی و اروپا سازگار است؛ وقتی سیستم بتواند به درستی و ایمنی تشخیص دهد که چه کسی از آن استفاده می‌کند، پس از ورود به سیستم، امکان دسترسی به اطلاعات شخصی شهروندان و کلیه خدمات عمومی را از طریق یک ابزار فراهم می‌کند، و با امضای دیجیتالی مجوز هر کاری را دارید.
• اصل دوم و یکی از تحول‌بخش‌ترین اصول، «فقط یکبار» نامیده می‌شود. به این معناست که دولت نمی‌تواند بیش از یکبار، درخواست اطلاعات یکسانی را نماید، و نه می‌تواند آن‌را در بیش از یکجا جمع‌آوری کند. برای مثال، اگر قبلا گواهی تولد یا ازدواج خود را به ثبت احوال ارائه کرده‌اید، این تنها جایی است که این اطلاعات نگهداری می‌شوند. و هیچ نهاد دیگری هرگز درخواستی برای آن نخواهد کرد. «فقط یکبار» یک قانون بسیار قدرتمند است، که کل ساختار جمع‌آوری داده در یک کشور را تعریف می‌کند، چه اطلاعاتی جمع‌آوری می‌شود و چه کسی مسئول حفظ آن است، تا اطمینان حاصل شود که از تمرکز داده‌ها، و تکرار داده‌ها جلوگیری می‌کنیم، و تضمین کنیم که اطلاعات واقعا به روز است.

انتظارات خود را در قالب سناریو مطرح کنید

حال زمان آن رسیده که هرچقدر بیشتر که می‌توانید به بازخوردهای مراجعه کنید، با کاربران مصاحبه کنید، پای حرف مدیران بنشینید و انواع سناریوها را استخراج کنید. انواع سناریوهایی که ممکن از اتفاق بیافتد. سناریوهایی که انتظار دارید پس از توسعه‌ی نسخه‌ی فعلی سیستم بتوانید پشتیبانی کنید را هم بنویسید. طرح پیشنهادی را با تک تک سناریوها تطبیق دهید و شبیه‌سازی کنید.

برای مثال:

• کاربری پس از گم کردن کارت ملی خود برای ثبت نام به یکی از شعب مراجعه می‌کند. با توجه به محدودیت ۵ مرحله در روند، چگونه می‌توانیم او را احراز هویت کنیم؟
• کاربر به صورت خود سرانه پول را به حساب دیگری از شرکت کارت به کارت کرده است، با توجه به اینکه تا کنون ۴ مرحله از فرایند خرید طی شده و نمی‌توانیم بیشتر او را معطل کنیم، چطور می‌توانیم پرداخت او را تایید کنیم، بی آن که محاسبات واحد حساب‌داری دچار اشکال شود؟
• کاربر پس از تماس با مرکز پاسخگویی تلفنی به اشتباه داخلی واحد دیگری را شماره‌گیری کرده است، با توجه به این که ۱ مرحله از روند را طی کرده چه کسی باید او را به واحد مربوطه ارجاع دهد (هماهنگی با اپراتور توسط کارمند انجام شود یا کاربر)؟

شما را به بازگشت به مکتبی تشویق می‌کنم که اگر بخواهیم اسمی برایش انتخاب کنیم احتمالا «رویکرد عمل‌گرای کاربر‌محور» باشد. با این حساب، کاربر نباید درگیر خود محصول باشد، بلکه باید درگیر نتیجه‌ی کاری باشد که می‌خواهد با آن محصول انجام دهد. در نتیجه محصول خوب محصولی خواهد بود که حضورش احساس نشود اما تاثیراتش مشهود باشد. پس با این رویکرد:

• مهم نیست که تاکسی چه رنگی است، مهم این است او را بشناسم و مرا به مقصد برساند
• عینک خوب عینکی است که دید من را بهتر کند و حضورش را حس نکنم.
• سایت فروشگاهی خوب سایتی است که اطلاعات محصول، اطمینان از خرید، دسترس‌پذیری، و مقدار و قیمت به صرفه را برای من ضمانت کند و لازم نباشد که بدانم شماره‌ی مرکز پشتیبانی‌اش چند است.
• نرم‌افزار خوب نرم‌افزاری است که هنگام استفاده از آن، احساس کنم کارم دارد راه می‌افتد، نه اینکه احساس کنم که دارم با یک نرم‌افزار کار می‌کنم.
• ما به رستوران نمی‌رویم که به رستوران رفته باشیم. به رستوران می‌رویم که غذایی خوب در محیطی آرامش‌بخش میل کنیم.
• شما مرورگر وب را باز نمی‌کنید که با مرورگر کار کنید، بلکه مرورگر را باز می‌کنید که به سایت دلخواهتان بروید.