پنجره‌های شکسته را شوق تماشا نیست!

تئوری پنجره‌های شکسته و کاربرد آن در توسعه محصول

اصطلاح «پنجره‌های شکسته» نخستین بار در نوشتة جیمز ویلسون و جورج کلینک در سال ۱۹۸۲ و در نشریة آتلانتیک پدیدار شد. آن‌ها که در زمینه مدیریت شهری و جرم‌شناسی تخصص داشتند، در مقاله‌شان با ذکر مثال‌هایی ساده تأثیر «نابسامانی‌های به‌ظاهر کوچک» در ایجاد «جو ناامنی و وقوع جرم‌های بزرگ» در شهرها را بررسی کردند.

تئوری پنجره شکسته ساده است: ساختمانی را در نظر بگیرید که چند تا از پنجره‌های آن شکسته است (نابسامانی کوچک). اگر این پنجره‌ها تعمیر نشوند، احتمالاً رهگذران فکر می‌کنند که آن خانه ساکنی ندارد. بنابراین احتمالاً آشغال‌های خود را کنار این ساختمان می‌گذارند. روی درودیوارش فحش می‌نویسند و درنهایت احتمالاً افراد خراب‌کار، در هنگام مشاهده این ساختمان (در مقایسه با یک ساختمان سالم) تمایل بیشتری به تخریب سایر پنجره‌ها خواهند داشت. حتی ممکن است وارد آن ساختمان شوند و اگر کسی ساکن آنجا نباشد، آنجا را اِشغال کنند (جو ناامنی و جرم بزرگ).

ویلسون و کلینک در پایان مقاله بلندشان و در بخش نتیجه‌گیری پیشنهاد دادند که پلیس و مردم نباید صرفاً‌ به‌دنبال جرم‌ها ‌و آسیب‌های فردی باشند که شاکی مشخصی دارد؛ بلکه همه باید بکوشیم جامعه‌ای را حفظ و نگهداری کنیم که پنجره‌های شکسته (از هر جنس و نوع، مثلاً زباله‌ریختن در پیاده‌رو، مترو و...) نداشته باشد.

تئوری پنجره‌های شکسته در توسعه محصول

از تئوری پنجره‌های شکسته می‌توان ایده‌های خوبی در توسعه محصول و بهبود تجربه کاربر گرفت. دیدن پنجره‌ای شکسته در محصول این پیام را به کاربر می‌دهد که در این محصول اوضاع بسامان نیست و نظمی وجود ندارد. حالا اگر وجود پنجره‌های شکسته ادامه پیدا کند و کسی رسیدگی نکند و پنجره‌ها همچنان شکسته بمانند،‌ کاربران به‌تدریج محصول را ترک می‌کنند؛ محصولی که برای صاحبش اهمیت ندارد، چرا باید برای کاربرش اهمیت داشته باشد؟!

برای پرهیز از دام پنجره‌‌های شکسته در محصول چه باید کرد؟

یک. پنجره‌های محصول خود را بشناسید.

ابتدا باید پنجره‌های محصول خود را بشناسید. اما پنجره محصول چیست؟ دو موضوع را می‌توان به‌عنوان پنجره‌های محصول در نظر گرفت:

۱. رابط کاربری بدو ورود: پنجره محصول یعنی پیشانی محصول. رهگذران در اولین نگاه به ساختمان، نما و در و پنجره آن را می‌بینند و با همان نگاه‌های اولیه متوجه می‌شوند که آیا با ساختمان «درست‌ودرمانی» طرف هستند یا با ساختمانی که به حال خود رها شده است؟ در هنگام مواجهه کاربر با محصول هم دقیقاً با چنین شرایطی مواجهیم. کاربران در سی ثانیه اول تصمیم می‌گیرند که آیا در اپلیکیشن خواهند ماند یا خیر؟ دقیقاً به‌دلیل همین «تأثیر اولیه» است که شرکت‌های بزرگ وقت خیلی زیادی از تیم توسعة محصولشان را برای تأثیر اولیة کاربر (First Impression) صرف می‌کنند. مثلاً اسکات بلسکی مدیر ارشد محصول ادوبی پیشنهاد می‌کند که سی درصد از کل انرژی تیم باید به «تأثیر اولیه» اختصاص پیدا کند. (منبع)

اگر اپلیکیشن شما «تأثیر اولیه» خوبی نداشته باشد، یعنی شما پنجره شکسته‌ی بزرگی را در بهترین جای ساختمان قرار داده‌اید. پنجره‌ای که نگاه هر رهگذری ـ حتی اگر نخواهد ـ به آن خواهد افتاد و تأثیر بد آن نگاه را همیشه با خود خواهد داشت؛ تأثیری که در بیشتر مواقع باعث می‌شود کاربر حتی پایش را داخل ساختمان (محصول) شما نگذارد!

۲. کارکردهای اصلی و پرکاربرد محصول: کارکردهایی هستند که از محصول شما انتظار می‌رود باید بی‌عیب‌ونقص کار کنند. از دید هر رهگذر، صاحب‌خانه‌ای که شیشه‌ی شکسته‌ی پنجره‌ی خانه‌اش را تعمیر نمی‌کند و راه را برای ناامنی باز می‌گذارد،‌ حتماً سایر المان‌های خانه‌اش نیز همین‌قدر بی‌سامان است. صاحب اپلیکیشنی هم که کارکرد اصلی‌اش درست کار نمی‌کند، یعنی کل محصولش از پای‌بست ویران است.

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

«ایجاد کانال و گروه»، «ارسال پیام» و «ارسال و دریافت سریع فایل» را می‌توان به‌عنوان پنجره‌های دیگر محصول در «بله» در نظر گرفت.

دو. به‌جای ایجاد در و پنجره جدید، فکری به حال پنجره‌های شکسته کنید!

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

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

خودتان ساختمانی را که ده پنجره دارد و سه تا از آن‌ها شکسته و داغان است، ترجیح می‌دهید یا ساختمانی که کلاً سه پنجره امروزی و شیک و کارا دارد؟!

ج. تمیز کد بزنید!

قسمت آخر مستقیماً به تجربة کاربر مربوط نمی‌شود؛ ولی با واسطه به آن می‌رسد. برنامه‌نویسان باید درست و تمیز کد بزنند. کتاب مرجع Clean code را باید خواند و به آن عمل کرد. حالا این چه ربطی به پنجره‌های شکسته دارد؟

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

نتیجه‌گیری

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