مجھے یقین ہے کہ آپ نے لکیروں کے بارے میں سنا ہے یا اس کے ساتھ کوئی ایپ استعمال کی ہے۔ لیکن کبھی سوچا ہے کہ لکیریں اتنی مقبول اور طاقتور کیوں ہیں؟ ٹھیک ہے، یہ واضح ہے کہ ایپس آپ کی زیادہ سے زیادہ توجہ چاہتی ہیں، لیکن اس کے علاوہ، کیا آپ جانتے ہیں کہ جب مقبول سیکھنے والی ایپ Duolingo نے iOS ویجٹس کو اسٹریکس ظاہر کرنے کے لیے متعارف کرایا، تو صارف کے عزم میں 60 فیصد اضافہ ہوا۔ ساٹھ فیصد رویے میں بڑے پیمانے پر تبدیلی ہے اور یہ ظاہر کرتا ہے کہ کس طرح "اسٹریک" پیٹرن کو مشغولیت اور ڈرائیو کے استعمال کو بڑھانے کے لیے استعمال کیا جا سکتا ہے۔ سب سے بنیادی طور پر، ایک سلسلہ مسلسل دنوں کی تعداد ہے جب صارف ایک مخصوص سرگرمی مکمل کرتا ہے۔ کچھ لوگ اسے ایک "گیمفائیڈ" عادت یا ایک میٹرک کے طور پر بھی بیان کرتے ہیں جو مستقل استعمال کی حوصلہ افزائی کے لیے ڈیزائن کیا گیا ہے۔ لیکن لکیریں ایک ایپ میں میٹرک یا ریکارڈ ہونے سے آگے بڑھ جاتی ہیں۔ یہ اس سے زیادہ نفسیاتی ہے. انسانی جبلتوں کو صحیح عوامل سے متاثر کرنا آسان ہے۔ ان تین عوامل کو دیکھیں: ترقی، فخر، اور گم ہونے کا خوف (عام طور پر FOMO کہا جاتا ہے)۔ ان سب میں کیا مشترک ہے؟ کوشش۔ آپ کسی چیز میں جتنی زیادہ محنت کرتے ہیں، اتنا ہی وہ آپ کی شناخت کو تشکیل دیتا ہے، اور اس طرح رویے کی نفسیات کی دنیا میں لکیریں عبور کرتی ہیں۔ اب، بڑی طاقت کے ساتھ بڑی ذمہ داری آتی ہے، اور اس کی وجہ سے، لکیروں کا ایک تاریک پہلو ہے۔ اس مضمون میں، ہم ایک مؤثر اسٹریک سسٹم بنانے کے پیچھے نفسیات، UX، اور ڈیزائن کے اصولوں میں جائیں گے۔ ہم دیکھیں گے کہ (1) ہمارے دماغ تقریباً فطری طور پر اسٹریک کی سرگرمی کا جواب کیوں دیتے ہیں، (2) اسٹریکس کو ایسے طریقوں سے کیسے ڈیزائن کیا جائے جس سے صارفین کی حقیقی مدد ہو، اور (3) اسٹریک پیٹرن بنانے میں شامل تکنیکی کام۔ اسٹریکس کے پیچھے نفسیات ایک موثر اسٹریک سسٹم کو ڈیزائن اور بنانے کے لیے، ہمیں یہ سمجھنے کی ضرورت ہے کہ یہ ہمارے دماغوں کے تاروں کے ساتھ کیسے مطابقت رکھتا ہے۔ جیسا کہ، کیا چیز اسے اس حد تک موثر بناتی ہے کہ ہم اپنی لکیروں کی حفاظت کے لیے اتنی شدید لگن محسوس کرتے ہیں؟ تین دلچسپ، اچھی طرح سے دستاویزی نفسیات کے اصول ہیں جو اس بات کی حمایت کرتے ہیں کہ اسٹریکس کو اتنا طاقتور اور لت کیا بناتا ہے۔ نقصان سے بچنا یہ شاید لکیروں کے پیچھے سب سے مضبوط قوت ہے۔ میں یہ اس لیے کہتا ہوں کہ اکثر اوقات، آپ زندگی میں تقریباً اس سے بچ نہیں سکتے۔ اس کے بارے میں اس طرح سوچیں: اگر کوئی دوست آپ کو $100 دیتا ہے، تو آپ خوش ہوں گے۔ لیکن اگر آپ اپنے بٹوے سے $100 کھو دیتے ہیں، تو اس سے کہیں زیادہ تکلیف ہوگی۔ ان حالات کا جذباتی وزن برابر نہیں ہے۔ نقصان اچھا محسوس کرنے سے کہیں زیادہ تکلیف دیتا ہے۔ آئیے اسے آگے لے جائیں اور کہتے ہیں کہ میں آپ کو 100 ڈالر دیتا ہوں اور آپ سے جوا کھیلنے کو کہتا ہوں۔ آپ کے مزید $100 جیتنے کا 50% امکان ہے اور اصل $100 سے محروم ہونے کا 50% امکان ہے۔ کیا آپ اسے لیں گے؟ میں نہیں کروں گا۔ زیادہ تر لوگ نہیں کریں گے۔ یہ نقصان سے بچنا ہے۔ اگر آپ اس کے بارے میں سوچیں تو یہ منطقی ہے، یہ قابل فہم ہے، یہ انسان ہے۔ نقصان سے بچنے کا تصور یہ ہے کہ ہم کسی چیز کو کھونے کا دکھ محسوس کرتے ہیں جتنا کہ مساوی قیمت کی چیز حاصل کرنے کی خوشی سے دوگنا زیادہ۔ نفسیاتی لحاظ سے، نقصان فائدہ سے زیادہ دیر تک رہتا ہے۔ آپ شاید دیکھیں گے کہ اس کا تعلق لکیروں سے کیسے ہے۔ ایک نمایاں لکیر بنانے کے لیے، اس کے لیے کوشش کی ضرورت ہوتی ہے۔ جیسے جیسے ایک سلسلہ بڑھتا ہے، اس کے پیچھے محرک ختم ہونے لگتا ہے۔ یا زیادہ درست طور پر، یہ ثانوی بننے لگتا ہے۔ یہاں ایک مثال ہے: کہتے ہیں کہ آپ کے دوست کی ایپل واچ پر اپنے "موو رِنگز" کو بند کرنے کا تین دن کا سلسلہ ہے۔ ان کے پاس اپنے مقصد کو حاصل کرنے اور مستقل مزاجی کی خواہش کے علاوہ کھونے کے لیے کچھ بھی نہیں ہے۔ ایک ہی وقت میں، آپ کا 219 دن کا شاندار سلسلہ جاری ہے۔ امکانات یہ ہیں کہ آپ اسے کھونے کے خوف سے پھنس گئے ہیں۔ آپ غالباً اس وقت کامیابی کے بارے میں نہیں سوچ رہے ہوں گے۔ یہ آپ کی سرمایہ کاری کی کوششوں کی حفاظت کے بارے میں زیادہ ہے، اور یہ نقصان سے بچنا ہے۔ Duolingo وضاحت کرتا ہے کہ کس طرح نقصان سے بچنا صارف کے سست ترین دنوں میں بھی طویل سلسلہ کو توڑنے میں ہچکچاہٹ کا باعث بنتا ہے۔ ایک طرح سے، ایک سلسلہ عادت میں بدل سکتا ہے جب نقصان سے بچنا شروع ہوجاتا ہے۔ فوگ طرز عمل کا ماڈل (B = MAP) اب جب کہ ہم لمبی لکیروں میں لگائی گئی کوششوں کو کھونے کے خوف کو سمجھتے ہیں، ایک اور سوال یہ ہے کہ: کیا چیز ہمیں دن بہ دن، اس سے پہلے کہ لکیر کے بڑے ہونے سے پہلے ہی کام کرنے پر مجبور کرتی ہے؟ فوگ طرز عمل کا ماڈل اسی کے بارے میں ہے۔ یہ نسبتاً آسان ہے۔ ایک رویہ (B) صرف اس وقت ہوتا ہے جب تین عوامل - حوصلہ افزائی (M)، قابلیت (A)، اور پرامپٹ (P) - ایک ہی لمحے میں سیدھ میں ہوں۔ اس طرح، مساوات B=MAP۔ اگر ان عوامل میں سے کوئی ایک بھی، اس وقت غائب ہے، تو یہ سلوک نہیں ہوگا۔ لہذا، ایک اسٹریک سسٹم کو موثر اور بار بار چلنے کے لیے، تینوں عوامل کا موجود ہونا ضروری ہے: حوصلہ افزائی یہ نازک ہے اور ایسی چیز نہیں جو مستقل طور پر موجود ہو۔ ایسے دن ہوتے ہیں جب آپ ہوتے ہیں۔ہسپانوی زبان سیکھنے کے لیے پمپ کیا گیا، اور ان دنوں آپ کو زبان سیکھنے کے لیے قوتِ ارادی کا ذرا سا بھی احساس نہیں ہوتا۔ عادت پیدا کرنے کی تحریک خود ہی ناقابل اعتبار ہے اور پہلے دن سے ہی ہاری ہوئی جنگ ہے۔ حوصلہ افزائی کی حدود کی تلافی کرنے کی صلاحیت، قابلیت اہم ہے۔ اس تناظر میں، قابلیت کا مطلب عمل میں آسانی ہے، یعنی کوشش اتنی آسان ہے کہ یہ کہنا غیر حقیقی ہے کہ یہ ممکن نہیں ہے۔ زیادہ تر ایپس اسے جان بوجھ کر استعمال کرتی ہیں۔ Apple Fitness کے لیے آپ کو اپنے اسٹینڈ گول کی طرف ٹک حاصل کرنے کے لیے ایک گھنٹے میں صرف ایک منٹ کھڑے ہونے کی ضرورت ہے۔ Duolingo کو صرف ایک مکمل سبق کی ضرورت ہے۔ ان کاموں کے لیے اتنی محنت کی ضرورت نہیں ہے۔ رکاوٹ اتنی کم ہے کہ آپ کے بدترین دنوں میں بھی آپ اسے کر سکتے ہیں۔ لیکن ایک جاری سلسلہ کی مشترکہ کوشش وہیں ہے جہاں اس سلسلے کو کھونے کا خیال آتا ہے۔ Promptیہ وہی ہے جو مساوات کو مکمل کرتا ہے۔ انسان فطری طور پر بھولنے والے ہوتے ہیں، اس لیے ہاں، قابلیت ہمیں وہاں 90 فیصد تک پہنچا سکتی ہے۔ لیکن ایک اشارہ ہمیں عمل کرنے کی یاد دلاتا ہے۔ اسٹریکس ڈیزائن کے لحاظ سے مستقل ہیں، لہذا صارفین کو عمل کرنے کے لیے مسلسل یاد دلانے کی ضرورت ہے۔ یہ دیکھنے کے لیے کہ ایک پرامپٹ کتنا طاقتور ہو سکتا ہے، Duolingo نے A/B ٹیسٹ کیا تاکہ یہ دیکھا جا سکے کہ آیا ایپ کے آئیکن پر تھوڑا سا سرخ بیج مسلسل استعمال میں اضافہ کرتا ہے۔ اس نے یومیہ متحرک صارفین میں 6 فیصد اضافہ کیا۔ صرف ایک سرخ بیج۔ ماڈل کی حدود یہ سب کچھ کہا جا رہا ہے، فوگ ماڈل کی ایک حد ہے جس کے تحت ناقدین اور جدید تحقیق نے دیکھا ہے کہ ایک ایسا ڈیزائن جو اشارے پر بہت زیادہ انحصار کرتا ہے، جیسے جارحانہ اطلاعات، ذہنی تھکاوٹ پیدا کرنے کا خطرہ ہے۔ مسلسل اطلاعات اور اوور ٹائم صارفین کو منتشر کرنے کا سبب بن سکتا ہے۔ تو، اس کے لئے دھیان سے. زیگرنک اثر آپ کیسا محسوس کرتے ہیں جب آپ کسی پروجیکٹ کا کام آدھا چھوڑ دیتے ہیں؟ یہ بہت سے لوگوں کو پریشان کرتا ہے کیونکہ نامکمل کام ہمارے مکمل ہونے والی چیزوں سے زیادہ ذہنی جگہ پر قبضہ کرتے ہیں۔ جب کچھ کیا جاتا ہے اور چلا جاتا ہے، تو ہم اسے بھول جاتے ہیں. جب کوئی چیز ادھوری چھوڑ دی جاتی ہے، تو یہ ہمارے ذہنوں پر بوجھ بن جاتی ہے۔ یہی وجہ ہے کہ ڈیجیٹل پروڈکٹس مصنوعی ترقی کے اشارے استعمال کرتے ہیں، جیسے Upwork کے پروفائل کی تکمیل بار، صارف کو یہ بتانے کے لیے کہ ان کا پروفائل صرف "60% مکمل" ہے۔ یہ صارف کو جو کچھ شروع کیا اسے ختم کرنے پر مجبور کرتا ہے۔
آئیے ایک اور مثال دیکھتے ہیں۔ ٹو ڈو لسٹ ایپ میں آپ کے پاس پانچ کام ہیں، اور دن کے اختتام پر، آپ ان میں سے صرف چار کو مکمل طور پر چیک کرتے ہیں۔ اس ایک نامکمل کام کی وجہ سے ہم میں سے بہت سے لوگ خود کو ادھورا محسوس کریں گے۔ وہیں، زیگرنک اثر ہے۔ زیگارنک اثر کا مظاہرہ ماہر نفسیات بلوما زیگارنک نے کیا، جس نے بیان کیا کہ ہم اپنی یادداشت میں نامکمل کاموں کو مکمل کیے گئے کاموں سے زیادہ دیر تک متحرک رکھنے کا رجحان رکھتے ہیں۔ UX ڈیزائن میں ایک اسٹریک پیٹرن قدرتی طور پر اس میں ٹیپ کرتا ہے۔ فرض کریں کہ آپ سیکھنے کے سلسلے کے 63 ویں دن پر ہیں۔ اس وقت، آپ نامکمل کاروبار کے جاری انداز میں ہیں۔ آپ کا دماغ شاذ و نادر ہی اس کے بارے میں بھول جائے گا کیونکہ یہ آپ کے دماغ کے پچھلے حصے میں بیٹھا ہے۔ اس وقت، آپ کا دماغ آپ کو اطلاعات بھیجنے والا بن جاتا ہے۔ جب آپ ان نفسیاتی قوتوں کو ایک ساتھ رکھتے ہیں، تو آپ صحیح معنوں میں سمجھنا شروع کر دیتے ہیں کہ اسٹریک صرف ایک باقاعدہ ایپ کی خصوصیت کیوں نہیں ہے۔ وہ انسانی رویے کو تبدیل کرنے کے قابل ہیں. لیکن لائن کے ساتھ کہیں — میں قطعی طور پر یہ نہیں کہہ سکتا کہ کب، جیسا کہ یہ ہر ایک کے لیے مختلف ہوتا ہے — چیزیں اس مقام پر پہنچ جاتی ہیں جہاں ایک سلسلہ "تفریح" سے کسی ایسی چیز میں بدل جاتا ہے جسے آپ محسوس کرتے ہیں کہ آپ کھونے کے متحمل نہیں ہو سکتے۔ آپ نہیں چاہتے کہ 58 دن کی محنت رائیگاں جائے، کیا آپ؟ یہی ایک اسٹریک سسٹم کو موثر بناتا ہے۔ اگر صحیح طریقے سے کیا جائے تو، لکیریں صارفین کو حیران کن عادات بنانے میں مدد کرتی ہیں جو ایک مقصد کو پورا کرتی ہیں۔ یہ روزانہ پڑھنا یا جم کو لگاتار مارنا ہو سکتا ہے۔ یہ بار بار کیے جانے والے اعمال (بعض اوقات چھوٹے) وقت کے ساتھ مل جاتے ہیں اور ہماری روزمرہ کی زندگی میں واضح ہو جاتے ہیں۔ لیکن ہر سکے کے دو رخ ہوتے ہیں۔ عادت اور مجبوری کے درمیان پتلی لکیر اگر آپ اس کی پیروی کر رہے ہیں تو، آپ پہلے ہی بتا سکتے ہیں کہ اسٹریک سسٹم کا ایک تاریک پہلو ہے۔ عادت کی تشکیل بار بار ہدف کے ساتھ مستقل مزاجی کے بارے میں ہے۔ تاہم، مجبوری ایک ایسے مقصد پر کام کرنے کی مستقل مزاجی ہے جس کی اب ضرورت نہیں ہے لیکن خوف یا دباؤ سے باہر رکھا جاتا ہے۔ یہ ایک استرا پتلی لکیر ہے۔ آپ بغیر سوچے سمجھے ہر صبح اپنے دانت صاف کرتے ہیں۔ یہ خودکار اور فطری ہے، اچھی سانس لینے کے واضح مقصد کے ساتھ۔ یہ ایک سلسلہ ہے جو ایک اچھی عادت بناتا ہے۔ ایک اخلاقی اسٹریک سسٹم صارفین کو سانس لینے کی جگہ دیتا ہے۔ اگر، کسی وجہ سے، آپ صبح برش نہیں کرتے ہیں، تو آپ دوپہر کو برش کر سکتے ہیں۔ ایک طویل کوشش کھونے کے خوف کے بغیر نامکمل کی اجازت ہے۔ مجبوری الٹا راستہ اختیار کرتی ہے، جہاں ایک سلسلہ آپ کو پریشان کر دیتا ہے، آپ کو مجرم محسوس ہوتا ہے یا یہاں تک کہ تھک جاتا ہے، اور کبھی کبھی ایسا محسوس ہوتا ہے کہ آپ نے اپنی تمام تر کوششوں کے باوجود کچھ حاصل نہیں کیا ہے۔کام آپ کام اس لیے نہیں کرتے کہ آپ کرنا چاہتے ہیں، بلکہ اس لیے کہ آپ لاشعوری طور پر اپنی ترقی کو صفر پر دوبارہ سیٹ ہوتے دیکھ کر خوفزدہ ہیں۔ کسی نے اسے بالکل ٹھیک بیان کیا، "میں نے محسوس کیا کہ میں دھوکہ دے رہا ہوں، لیکن صرف پرواہ نہیں کی۔ میں اپنی لکیر کے بغیر کچھ بھی نہیں ہوں"۔ یہ ظاہر کرتا ہے کہ ایک فرد پر انتہائی ہولڈ لکیریں ہوسکتی ہیں۔ اس حد تک کہ صارفین اپنی خود کی قدر کو اصل مقصد یا وجہ کے بجائے ایک صوابدیدی میٹرک سے جوڑنا شروع کر دیتے ہیں جس کی وجہ سے انہوں نے سلسلہ شروع کیا۔ یہ سلسلہ بن جاتا ہے کہ وہ کون ہیں، نہ کہ صرف وہ کیا کرتے ہیں۔ ایک اچھی طرح سے ڈیزائن کردہ اخلاقی اسٹریک سسٹم کو صارف کی حوصلہ افزائی کی طرح محسوس ہونا چاہئے، نہ کہ دباؤ یا ذمہ داری۔ اس کا تعلق داخلی اور خارجی محرک کے توازن سے ہے۔ خارجی محرک (بیرونی انعامات، سزا سے بچنا) صارفین کو شروع کر سکتا ہے، لیکن اندرونی ترغیب (کسی ذاتی مقصد کے لیے کام کرنا جیسے ہسپانوی سیکھنا کیونکہ آپ حقیقی طور پر کسی عزیز کے ساتھ بات چیت کرنا چاہتے ہیں) طویل مدتی مصروفیت کے لیے زیادہ مضبوط ہے۔ ایک اچھے نظام کو خارجی عناصر کے محتاط استعمال کے ساتھ اندرونی محرک کی طرف متوجہ ہونا چاہیے، یعنی صارفین کو یاد دلائیں کہ وہ کس حد تک پہنچ چکے ہیں، انہیں اس بات کی دھمکی نہ دیں کہ وہ کیا کھو سکتے ہیں۔ ایک بار پھر، یہ ایک ٹھیک لائن ہے. اسٹریک سسٹم کو ڈیزائن کرتے وقت ایک سادہ سا امتحان یہ ہے کہ درحقیقت کچھ وقت لگائیں اور یہ سوچیں کہ کیا آپ کی مصنوعات آپ کی مصنوعات کی تخلیق کردہ پریشانی کے حل کو بیچ کر پیسہ کماتی ہیں۔ اگر ہاں، تو اس بات کا زیادہ امکان ہے کہ آپ صارفین کا استحصال کر رہے ہیں۔ تو اگلا سوال بنتا ہے، اگر میں اسٹریک کو استعمال کرنے کا انتخاب کرتا ہوں، تو میں اسے اس طرح سے کیسے ڈیزائن کروں جو صارفین کو ان کے مقاصد کو حاصل کرنے میں حقیقی طور پر مدد کرتا ہو؟ گڈ اسٹریک سسٹم ڈیزائن کا UX مجھے یقین ہے کہ یہ وہ جگہ ہے جہاں زیادہ تر پروجیکٹس یا تو ایک موثر اسٹریک سسٹم کیل کرتے ہیں یا اسے مکمل طور پر گڑبڑ کرتے ہیں۔ آئیے ایک اچھے اسٹریک ڈیزائن کے کچھ UX اصولوں کو دیکھتے ہیں۔ اسے بے مقصد رکھیں یہ بات آپ نے پہلے بھی سنی ہو گی، شاید اٹامک ہیبیٹس جیسی کتابوں سے، لیکن یہ بات قابل ذکر ہے کہ عادات پیدا کرنے کا ایک آسان ترین طریقہ عمل کو چھوٹا اور آسان بنانا ہے۔ یہ قابلیت کے عنصر سے ملتا جلتا ہے جس پر ہم نے فوگ سلوک ماڈل سے تبادلہ خیال کیا ہے۔ کسی بھی اسٹریک ڈیزائن کا پہلا اصول یہ ہونا چاہئے کہ ترقی کو حاصل کرتے ہوئے مطلوبہ کارروائی کو انسانی طور پر ممکن حد تک چھوٹا بنانا چاہئے۔ اگر روزانہ کی کارروائی کو مکمل کرنے کے لیے قوت ارادی کی ضرورت ہوتی ہے، تو وہ عمل اسے پانچ دن سے زیادہ نہیں کر دے گا۔ کیوں؟ آپ کو لگاتار پانچ دن حوصلہ افزائی نہیں کی جا سکتی۔ مثال کے طور پر: اگر آپ ایک مراقبہ ایپ چلاتے ہیں، تو آپ کو صارفین کو 20 منٹ کے سیشن سے گزرنے کی ضرورت نہیں ہے تاکہ اس سلسلے کو برقرار رکھا جاسکے۔ اس کے بجائے، ایک منٹ، شاید تیس سیکنڈ جیسی چھوٹی چیز بھی آزمائیں۔ جیسا کہ کہاوت ہے، پانی کے چھوٹے قطرے طاقتور سمندر بناتے ہیں)۔ چھوٹی کوششیں وقت کے ساتھ ساتھ بڑی کامیابیوں میں ڈھل جاتی ہیں۔ یہ مقصد ہونا چاہئے: رگڑ کو دور کریں، خاص طور پر جب لمحہ مشکل ہو۔ جب صارفین دباؤ یا مغلوب ہوتے ہیں، تو انہیں بتائیں کہ محض چند سیکنڈ کے لیے بھی ظاہر ہونا، کوشش کے طور پر شمار ہوتا ہے۔ واضح بصری تاثرات فراہم کریں۔ انسان فطرتاً بصری ہیں۔ اکثر اوقات، ہمیں یقین کرنے کے لیے کچھ دیکھنے کی ضرورت ہوتی ہے۔ چیزوں کو بہتر طور پر سمجھنے اور چیزوں کو تناظر میں رکھنے کے لیے ان کا تصور کرنے کی ضرورت ہے۔ یہی وجہ ہے کہ اسٹریک پیٹرن کوشش کو دیکھنے کے لیے اکثر بصری عناصر، جیسے گراف، چیک مارکس، پروگریس رِنگز، اور گرڈز کا استعمال کرتے ہیں۔ GitHub کے تعاون کا گراف دیکھیں۔ یہ مستقل مزاجی کا ایک سادہ تصور ہے۔ پھر بھی ڈویلپر اسے آکسیجن کی طرح سانس لیتے ہیں۔
کلید یہ نہیں ہے کہ اسٹریک سسٹم کو تجریدی محسوس کیا جائے۔ یہ حقیقی اور کمائی محسوس کرنا چاہئے. مثال کے طور پر، Duolingo اور Apple کی فٹنس ایکٹیویٹی رِنگز ایک سٹریک کی تکمیل پر صاف اینیمیشن ڈیزائنز کا استعمال کرتے ہیں، اور GitHub وقت کے ساتھ ساتھ صارف کی مستقل مزاجی کا تاریخی ڈیٹا دکھاتا ہے۔
اچھی ٹائمنگ کا استعمال کریں۔ میں نے پہلے ذکر کیا تھا کہ انسان فطرتاً بھولے بھالے ہوتے ہیں، اور یہ اشارے آگے کی رفتار کو برقرار رکھنے میں مدد کر سکتے ہیں۔ اشارے کے بغیر، زیادہ تر نئے صارفین جاری رکھنا بھول جاتے ہیں۔ زندگی مصروف ہو سکتی ہے، حوصلہ غائب ہو جاتا ہے، اور چیزیں ہوتی ہیں۔ یہاں تک کہ طویل عرصے سے استعمال کرنے والے بھی اشارے سے فائدہ اٹھاتے ہیں، حالانکہ اکثر اوقات، وہ عادت کے اندر پہلے سے ہی بند ہوتے ہیں۔ بہر حال، سب سے زیادہ پرعزم شخص بھی غلطی سے ایک دن کھو سکتا ہے۔ آپ کے اسٹریک سسٹم کو یقینی طور پر یاد دہانیوں کی ضرورت ہے۔ سب سے زیادہ استعمال شدہ فوری یاد دہانیاں پش اطلاعات ہیں۔ پش اطلاعات کے ساتھ کام کرتے وقت وقت واقعی اہمیت رکھتا ہے۔ ایپ کی قسم بھی اہمیت رکھتی ہے۔ صبح 9 بجے ایک اطلاع بھیجنا کہ "آپ نے آج پریکٹس نہیں کی ہے" سیکھنے والی ایپ کے لیے بالکل عجیب ہے کیونکہ بہت سے لوگوں کے پاس سبق مکمل کرنے کے بارے میں سوچنے سے پہلے دن میں کچھ کرنا ہوتا ہے۔ اگر ہم فٹنس ایپ کے بارے میں بات کر رہے ہیں، اگرچہ، یہمعقول ہے اور ہو سکتا ہے کہ دن کے اوائل میں یاد دلانے کی توقع بھی ہو۔ پش اطلاعات ایپ کے زمرے کے لحاظ سے نمایاں طور پر مختلف ہوتی ہیں۔ فٹنس ایپس، مثال کے طور پر، صبح سویرے اطلاعات (7-8 AM) کے ساتھ زیادہ مصروفیت دیکھیں، جبکہ پیداواری ایپس دوپہر کے اوائل میں بہتر کارکردگی کا مظاہرہ کر سکتی ہیں۔ کلید یہ ہے کہ آپ کے صارفین کے طرز عمل کی بنیاد پر اپنی ایپ کے ٹائمنگ کو A/B پرکھنا ہے بجائے اس کے کہ یہ مان لیا جائے کہ چیزیں ایک ہی سائز کے مطابق ہیں۔ جو چیز مراقبہ ایپ کے لیے کام کرتی ہے ہو سکتا ہے کہ کوڈنگ ٹریکر کے لیے کام نہ کرے۔ دوسرے فوری طریقے ایپ کے آئیکن اور یہاں تک کہ ایپ ویجیٹس پر سرخ نقطے ہیں۔ مطالعہ مختلف ہوتے ہیں، لیکن اوسطاً فرد دن میں 50-150 بار (PDF) کے درمیان اپنا آلہ کھولتا ہے۔ اگر کوئی صارف کسی ایپ یا ویجیٹ پر سرخ نقطے کو دیکھتا ہے جو ہر بار اپنے فون کو غیر مقفل کرنے پر موجودہ سلسلہ کی نشاندہی کرتا ہے، تو اس سے عزم میں اضافہ ہوتا ہے۔ بس اسے زیادہ نہ کرو؛ پرامپٹ کو ایک یاد دہانی کے طور پر کام کرنا چاہئے، نہ کہ ناگ۔ سنگ میل کا جشن منائیں۔ ایک اسٹریک سسٹم کو جذبات کو دوبارہ زندہ کرنے کے لیے سنگ میلوں کو منانے کی کوشش کرنی چاہیے، خاص طور پر صارفین کے لیے جو اسٹریک کی گہرائی میں ہے۔ جب کوئی صارف دن 7، دن 30، دن 50، دن 100، دن 365 کو مارتا ہے، تو آپ کو اس میں سے ایک بڑا سودا کرنا چاہئے۔ کامیابیوں کو تسلیم کریں — خاص طور پر طویل مدتی صارفین کے لیے۔
جیسا کہ ہم نے پہلے دیکھا تھا، Duolingo نے اس کا پتہ لگایا اور ایک اینیمیٹڈ گرافک کو نافذ کیا جو سنگ میل کو کنفیٹی کے ساتھ مناتا ہے۔ کچھ پلیٹ فارمز کافی بونس انعامات بھی دیتے ہیں جو صارفین کی کوششوں کی توثیق کرتے ہیں۔ اور یہ ایپس کے لیے فائدہ مند ہو سکتا ہے، جیسے کہ صارفین سوشل میڈیا پر اپنے سنگ میل کو عوامی طور پر شیئر کرتے ہیں۔ ایک اور فائدہ وہ توقع ہے جو سنگ میل تک پہنچنے سے پہلے آتی ہے۔ یہ صرف سلسلہ کو لامتناہی طور پر زندہ رکھنا نہیں ہے۔ صارفین کو انتظار کرنے کے لئے کچھ ہے. فضل میکانزم کا استعمال کریں زندگی غیر متوقع ہے۔ لوگ مشغول ہوجاتے ہیں۔ کسی بھی اچھے اسٹریک سسٹم کو نامکمل ہونے کی توقع کرنی چاہئے۔ اسٹریک سسٹم کے لیے سب سے بڑے نفسیاتی خطرات میں سے ایک صرف ایک یاد شدہ دن کے بعد صفر پر ہارڈ ری سیٹ کرنا ہے۔ ایک "اخلاقی" اسٹریک سسٹم کو صارف کو کچھ سستی فراہم کرنی چاہئے۔ فرض کریں کہ آپ کے پاس شطرنج سیکھنے کا 90 دن کا سلسلہ ہے۔ آپ تین اچھے مہینوں سے مستقل مزاج ہیں، اور ایک دن، آپ کا فون سفر کے دوران مر جاتا ہے، اور اسی طرح، 90 0 ہو جاتا ہے - ہر چیز، وہ تمام کوششیں، مٹ جاتی ہیں، اور ترقی ختم ہو جاتی ہے۔ صارف مکمل طور پر تباہ ہو سکتا ہے۔ اسے شروع سے دوبارہ تعمیر کرنے کا خیال اتنا مایوس کن ہے کہ کوشش اس کے قابل نہیں ہے۔ بدترین طور پر، ایک صارف ناکامی کی طرح محسوس کرنے کے بعد ایپ کو ترک کر سکتا ہے۔ اپنے اسٹریک سسٹم میں "فضل" میکانزم شامل کرنے پر غور کریں:
Streak Freeze صارفین کو بغیر کسی جرمانے کے جان بوجھ کر ایک دن گنوانے کی اجازت دیں۔ اضافی وقت دوبارہ ترتیب دینے سے پہلے معمول کی آخری تاریخ سے چند گھنٹے (2–3) گزرنے دیں۔ Decay Modelsایک ہارڈ ری سیٹ کے بجائے، سٹریک تھوڑی مقدار سے کم ہو جاتی ہے، مثلاً، سٹریک فی یاد شدہ دن سے 10 دن کاٹے جاتے ہیں۔
ایک حوصلہ افزا لہجہ استعمال کریں۔ آئیے صارفین کو دکھائے جانے والے دو پیغامات کا موازنہ کریں جب ایک سلسلہ ٹوٹ جاتا ہے:
"آپ نے اپنا 42 دن کا سلسلہ کھو دیا۔ دوبارہ شروع کریں۔" "آپ مسلسل 42 دن تک آئے۔ یہ ناقابل یقین پیشرفت ہے! اسے ایک بار پھر آزمانا چاہتے ہیں؟"
دونوں ایک ہی معلومات پہنچاتے ہیں، لیکن جذباتی اثر مختلف ہوتا ہے۔ پہلا پیغام غالباً صارف کو مایوسی کا احساس دلائے گا اور اسے چھوڑنے کا سبب بنے گا۔ دوسرا پیغام اس بات کا جشن مناتا ہے جو پہلے ہی حاصل کیا جا چکا ہے اور آہستہ سے صارف کو دوبارہ کوشش کرنے کی ترغیب دیتا ہے۔ اسٹریک سسٹمز ڈیزائن چیلنجز اس سے پہلے کہ ہم اسٹریک سسٹم بنانے کی تکنیکی تفصیلات میں جائیں، آپ کو ان چیلنجوں سے آگاہ ہونا چاہیے جن کا آپ کو سامنا ہو سکتا ہے۔ چیزیں پیچیدہ ہو سکتی ہیں، جیسا کہ آپ توقع کر سکتے ہیں۔ ٹائم زونز کو ہینڈل کرنا اس کی ایک وجہ ہے کہ وقت اور تاریخ کو ہینڈل کرنا ان سب سے مشکل تصورات میں سے ہے جن سے ڈویلپر ڈیل کرتے ہیں۔ یہاں فارمیٹنگ، انٹرنیشنلائزیشن، اور بہت کچھ غور کرنے کے لیے ہے۔ میں آپ سے یہ پوچھتا ہوں: ایک دن کیا شمار ہوتا ہے؟ ہم جانتے ہیں کہ دنیا مختلف ٹائم زونز پر چلتی ہے، اور گویا یہ کافی نہیں ہے، کچھ علاقوں میں ڈے لائٹ سیونگ ٹائم (DST) ہوتا ہے جو سال میں دو بار ہوتا ہے۔ آپ ان ایج کیسز کو کہاں سے سنبھالنا شروع کرتے ہیں؟ کل کے "آغاز" کے طور پر کیا شمار ہوتا ہے؟ کچھ ڈویلپرز UTC کی طرح ایک مرکزی ٹائم زون کا استعمال کرکے اس سے بچنے کی کوشش کرتے ہیں۔ کچھ صارفین کے لیے، اس سے صحیح نتائج برآمد ہوں گے، لیکن کچھ کے لیے، یہ ایک گھنٹہ، دو گھنٹے، یا اس سے زیادہ بند ہو سکتا ہے۔ یہ عدم مطابقت صارف کے تجربے کو برباد کر دیتی ہے۔ صارفین اس بات کی کم پرواہ کرتے ہیں کہ آپ پردے کے پیچھے وقت کو کیسے ہینڈل کرتے ہیں۔ وہ صرف یہ توقع کرتے ہیں کہ اگر وہ رات 11:40 پر ایک اسٹریک ایکشن کرتے ہیں، تو اسے ان کے سیاق و سباق میں، عین وقت پر رجسٹر ہونا چاہیے۔ آپ کو صارف کے مقامی ٹائم زون کی بنیاد پر "ایک دن" کی وضاحت کرنی چاہیے، سرور کے وقت کی نہیں۔ یقینا، آپ آسانی سے لے سکتے ہیںآدھی رات UTC پر تمام صارفین کے لیے عالمی سطح پر روٹ اور ری سیٹ سٹریکس، لیکن آپ بہت زیادہ ناانصافی پیدا کر رہے ہیں۔ کیلیفورنیا میں رہنے والے کسی کے پاس لندن میں رہنے والے کے مقابلے میں اپنا کام مکمل کرنے کے لیے ہمیشہ آٹھ اضافی گھنٹے ہوتے ہیں۔ یہ ایک غیر منصفانہ ڈیزائن کی خامی ہے جو بعض صارفین کو ان کے مقام کی وجہ سے سزا دیتی ہے۔ اور کیا ہوگا اگر وہ شخص لندن میں صرف دورہ کر رہا ہو، کوئی کام مکمل کرے، پھر کسی اور ٹائم زون میں واپس آجائے؟ ان سب کا ایک مؤثر حل یہ ہے کہ صارفین کو آن بورڈنگ کے دوران اپنا ٹائم زون واضح طور پر سیٹ کرنے کے لیے کہا جائے (ترجیحی طور پر پہلی تصدیق کے بعد)۔ ایک باریک نوٹ شامل کرنا اچھا خیال ہے کہ ٹائم زون کی معلومات فراہم کرنے کا استعمال صرف ایپ کے لیے پیش رفت کو درست طریقے سے ٹریک کرنے کے لیے کیا جاتا ہے، بجائے اس کے کہ ذاتی طور پر قابل شناخت ڈیٹا کے طور پر استعمال کیا جائے۔ اور اسے تبدیل کرنے والی ترتیب بنانا ایک اور اچھا خیال ہے۔ میرا مشورہ ہے کہ کوئی بھی ایپ میں ٹائم زون منطق کو براہ راست ہینڈل کرنے سے گریز کرے۔ آزمائشی اور درست تاریخ کی لائبریریاں استعمال کریں، جیسے Moment.js یا pytz (Python) وغیرہ۔ اس جیسی پیچیدہ چیز کے لیے پہیے کو دوبارہ ایجاد کرنے کی ضرورت نہیں ہے۔ مسڈ ڈیز اینڈ ایج کیسز ایک اور چیلنج جس کے بارے میں آپ کو فکر کرنی چاہئے وہ ہے بے قابو ایج کیسز جیسے کہ صارفین زیادہ سونا، سرور ڈاؤن ٹائم، وقفہ، نیٹ ورک کی ناکامی وغیرہ۔ فضل میکانزم کا خیال استعمال کرنا، جیسا کہ ہم نے پہلے بات کی ہے، مدد کر سکتا ہے۔ دو گھنٹے کی گریس ونڈو صارف اور ڈویلپر دونوں کی مدد کر سکتی ہے، اس لحاظ سے کہ صارفین کو زندگی کے بے قابو حالات کے لیے سخت سزا نہیں دی جاتی۔ ڈویلپرز کے لیے، گریس ونڈوز ان بے قابو لمحات میں مددگار ثابت ہوتی ہیں جب سرور آدھی رات کو بند ہو جاتا ہے۔ سب سے بڑھ کر، کلائنٹ پر کبھی بھروسہ نہ کریں۔ ہمیشہ سرور سائیڈ پر توثیق کریں۔ سرور کو سچائی کا واحد ذریعہ ہونا چاہئے۔ دھوکہ دہی کی روک تھام ایک بار پھر، میں اس پر کافی زور نہیں دے سکتا: سرور کی طرف سے ہر چیز کی توثیق کرنا یقینی بنائیں۔ صارف انسان ہیں، اور اگر موقع ملے تو انسان دھوکہ دے سکتے ہیں۔ یہ ناگزیر ہے۔ آپ کوشش کر سکتے ہیں:
UTC ٹائم اسٹیمپ کے ساتھ تمام اعمال کو ذخیرہ کرنا۔ کلائنٹ اپنا مقامی وقت بھیج سکتا ہے، لیکن سرور اسے فوری طور پر UTC میں تبدیل کر سکتا ہے اور سرور کے وقت کے خلاف توثیق کر سکتا ہے۔ اس طرح، اگر کلائنٹ کا ٹائم اسٹیمپ مشکوک طور پر دور ہے، تو سسٹم اسے غلطی کے طور پر مسترد کر سکتا ہے، اور UI اس کے مطابق جواب دے سکتا ہے۔ ایونٹ پر مبنی ٹریکنگ کا استعمال کرنا۔ دوسرے لفظوں میں، میٹا ڈیٹا کے ساتھ ہر ایکشن کا ریکارڈ محفوظ کریں بشمول صارف کی ID، کی گئی کارروائی کی قسم، اور ٹائم اسٹیمپ اور ٹائم زون۔ اس سے توثیق میں مدد ملتی ہے۔
ایک اسٹریک سسٹم انجن بنانا یہ کوڈ ٹیوٹوریل نہیں ہے، لہذا میں آپ پر کوڈ کا ایک گروپ پھینکنے سے گریز کروں گا۔ میں اس کو عملی طور پر برقرار رکھوں گا اور بیان کروں گا کہ فن تعمیر، بہاؤ، اور قابل اعتمادی تک چیزیں عام طور پر اسٹریک سسٹم انجن کو کیسے چلاتی ہیں۔ بنیادی فن تعمیر جیسا کہ میں نے کئی بار کہا ہے، سرور کو اسٹریک ڈیٹا کے لیے سچائی کا واحد ذریعہ بنائیں۔ سرور پر فن تعمیر کچھ اس طرح جا سکتا ہے:
ہر صارف کے ڈیٹا کو ڈیٹا بیس میں محفوظ کریں۔ موجودہ اسٹریک اسٹور (ڈیفالٹ بطور 0) کو ایک عدد کے طور پر اسٹور کریں۔ ٹائم زون کی ترجیح کو اسٹور کریں، یعنی IANA ٹائم زون سٹرنگ (یا تو مقامی ٹائم اسٹیمپ سے یا واضح طور پر صارف سے اپنا ٹائم زون منتخب کرنے کے لیے کہہ کر)۔ مثال کے طور پر، "America/New_York"۔ اس بات کا تعین کرنے کے لیے تمام منطق کو ہینڈل کریں کہ آیا سلسلہ جاری رہتا ہے یا ٹوٹ جاتا ہے، ٹائم زون کی جانچ کے ساتھ جو صارف کے مقامی ٹائم زون سے متعلق ہے۔
دریں اثنا، کلائنٹ کی طرف:
عام طور پر سرور سے حاصل کی جانے والی موجودہ اسٹریک کو دکھائیں۔ میٹا ڈیٹا کی شکل میں کی گئی کارروائی کو سرور کو بھیجیں تاکہ یہ تصدیق ہوسکے کہ آیا صارف نے حقیقت میں کوالیفائنگ اسٹریک ایکشن مکمل کیا ہے۔ سرور کے جوابات کی بنیاد پر بصری تاثرات فراہم کریں۔
لہذا، مختصر میں، دماغ سرور پر ہے، اور کلائنٹ ڈسپلے کے مقاصد اور واقعات کو جمع کرنے کے لئے ہے. یہ آپ کو بہت ساری ناکامیوں اور ایج کیسز کو بچاتا ہے، نیز اپ ڈیٹس اور اصلاحات کو آسان بناتا ہے۔ منطقی بہاؤ آئیے اس واک تھرو کی تقلید کرتے ہیں کہ جب صارف کوئی کارروائی مکمل کرتا ہے تو ایک کم سے کم موثر اسٹریک سسٹم انجن کیسے چلے گا:
صارف کوالیفائنگ اسٹریک ایکشن مکمل کرتا ہے۔ کلائنٹ میٹا ڈیٹا کے بطور سرور کو ایک واقعہ بھیجتا ہے۔ یہ "ٹائم اسٹیمپ Z پر صارف X مکمل ایکشن Y" ہو سکتا ہے۔ سرور اس واقعہ کو وصول کرتا ہے اور بنیادی توثیق کرتا ہے۔ کیا یہ حقیقی صارف ہے؟ کیا وہ مستند ہیں؟ کیا عمل درست ہے؟ کیا ٹائم زون مطابقت رکھتا ہے؟ اگر یہ گزر جاتا ہے تو، سرور ڈیٹا بیس سے صارف کا اسٹریک ڈیٹا بازیافت کرتا ہے۔ پھر، موصول ہونے والے ایکشن ٹائم اسٹیمپ کو صارف کے مقامی ٹائم زون میں تبدیل کریں۔ سرور کو صارف کے مقامی ٹائم زون میں کیلنڈر کی تاریخوں (ٹائم اسٹیمپ نہیں) کا موازنہ کرنے دیں: اگر یہ ایک ہی دن ہے، تو عمل بے کار ہے اور اس میں کوئی تبدیلی نہیں ہے۔لکیر اگر یہ اگلے دن ہے، تو سلسلہ بڑھتا ہے اور 1 تک بڑھتا ہے۔ اگر ایک دن سے زیادہ کا وقفہ ہو تو سلسلہ ٹوٹ جاتا ہے۔ تاہم، یہ وہ جگہ ہے جہاں آپ فضل میکینکس کا اطلاق کر سکتے ہیں۔ اگر فضل کا طریقہ کار چھوٹ گیا ہے، تو پھر اسٹریک کو 1 پر سیٹ کریں۔
اگر آپ سنگ میل کی کامیابیوں کے لیے تاریخی ڈیٹا کو محفوظ کرنے کا انتخاب کرتے ہیں، تو "سب سے طویل سلسلہ" یا "کل فعال دن" جیسے متغیرات کو اپ ڈیٹ کریں۔ سرور پھر ڈیٹا بیس کو اپ ڈیٹ کرتا ہے اور کلائنٹ کو جواب دیتا ہے۔ کچھ اس طرح:
{ "موجودہ_اسٹریک": 48، "لمبی_لڑائی": 50، "کل_فعال_دن": 120، "streak_extended": سچ، }
مزید اقدام کے طور پر، سرور کو یا تو دوبارہ کوشش کرنی چاہیے یا رد کرنا چاہیے اور عمل کے دوران کچھ ناکام ہونے پر کلائنٹ کو مطلع کرنا چاہیے۔ لچک کے لئے عمارت جیسا کہ پہلے ذکر کیا گیا ہے، صارفین کی خرابیوں یا سرور کے ڈاؤن ٹائم کی وجہ سے اسٹریک کھونا خوفناک UX ہے، اور صارفین اس کے زوال کی توقع نہیں کرتے ہیں۔ اس طرح، آپ کے اسٹریک سسٹم میں ان منظرناموں کے لیے حفاظتی اقدامات ہونے چاہئیں۔ اگر سرور دیکھ بھال کے لیے بند ہے (یا جو بھی وجہ ہے)، اسے ٹھیک کرنے کے لیے اضافی گھنٹوں کی ایک عارضی ونڈو کی اجازت دینے پر غور کریں تاکہ کارروائیاں تاخیر سے جمع کروائی جا سکیں اور پھر بھی گنتی کی جا سکے۔ آپ صارفین کو مطلع کرنے کا انتخاب بھی کر سکتے ہیں، خاص طور پر اگر صورت حال جاری سلسلہ کو متاثر کرنے کے قابل ہو۔ نوٹ: ایک ایڈمن بیک ڈور قائم کریں جہاں ڈیٹا کو دستی طور پر بحال کیا جا سکے۔ کیڑے ناگزیر ہیں، اور کچھ صارفین آپ کی ایپ کو کال کریں گے یا اس کی حمایت کرنے کے لیے پہنچیں گے کہ ان کا سلسلہ اس وجہ سے ٹوٹ گیا کہ وہ کنٹرول نہیں کر سکتے تھے۔ آپ کو دستی طور پر سٹریکس کو بحال کرنے کے قابل ہونا چاہئے اگر، تحقیقات کے بعد، صارف صحیح ہے. نتیجہ ایک چیز واضح ہے: اسٹریکس واقعی طاقتور ہیں کیونکہ انسانی نفسیات بنیادی سطح پر کیسے کام کرتی ہے۔ وہاں کا بہترین اسٹریک سسٹم وہ ہے جس کے بارے میں صارف شعوری طور پر نہیں سوچتے ہیں۔ یہ فوری نتائج یا نظر آنے والی پیش رفت کا معمول بن گیا ہے، جیسے دانت صاف کرنا، جو ایک باقاعدہ عادت بن جاتی ہے۔ اور میں صرف یہ کہنے والا ہوں: تمام مصنوعات کو اسٹریک سسٹم کی ضرورت نہیں ہے۔ کیا آپ کو مستقل مزاجی کو صرف اس لیے مجبور کرنا چاہیے کہ آپ روزانہ فعال صارفین چاہتے ہیں؟ اس کا جواب بہت اچھا ہو سکتا ہے "نہیں"۔
