جب میں نے اپنی پہلی ویب سائٹ بنانے کے لیے بیٹھنے کا فیصلہ کیا، تو جو جوش و خروش تھا وہ حقیقی تھا۔ میرا خیال تھا کہ مشکل کام کوڈنگ سیکھنا ہوگا—ٹیگز کو یاد کرنا، فنکشنز کو سمجھنا، اور سنتیکس (syntax) کو درست کرنا۔ میں غلط تھا۔ کوڈ لکھنا تو آسان نکلا۔ اصل چیلنج ان لائنوں کو کسی ایسی چیز میں بدلنا تھا جسے لوگ بغیر کسی الجھن یا مایوسی کے استعمال کر سکیں۔ اس پہلے پروجیکٹ نے مجھے سکھایا کہ ڈویلپمنٹ کا مقصد تنہائی میں ٹائپنگ کرنا نہیں ہے، بلکہ ان انسانوں کے مسائل حل کرنا ہے جنہیں آپ کے 'اسٹیک' (stack) سے کوئی سروکار نہیں ہوتا۔ میں نے ایسی غلطیاں کیں جن کی وجہ سے میرا وقت، نیند اور ابتدائی صارفین، سب کا نقصان ہوا۔ ان میں سے پانچ غلطیاں سب سے نمایاں تھیں۔
لانچ کرنے سے پہلے کمال (Perfection) کے پیچھے بھاگنا
میں اس 'پرفیکشن ٹریپ' کا شکار ہو گیا تھا، جبکہ میں نے ابھی تک کسی چیز کو مکمل طور پر پرفیکٹ کہنے کا حق بھی حاصل نہیں کیا تھا۔ میں نے پوری دوپہریں صرف ہیکس کوڈز (hex codes) کے رنگوں کو معمولی سا بدلنے، بارڈر ریڈیس (border-radius) کی ویلیوز کو آٹھ پکسل سے دس پکسل کرنے اور پھر واپس آٹھ پر لانے میں، اور ایک بھی وزیٹر کے آنے سے پہلے ہی ہیڈ لائن کو پانچ بار دوبارہ لکھنے میں گزار دیں۔ میں خود کو یہ کہہ کر تسلی دیتا رہا کہ میں کام کو نکھار رہا ہوں، لیکن حقیقت میں میں معیار کے بہانے کام کو ٹال رہا تھا۔ نتیجہ؟ میں تین ہفتے کی تاخیر سے لانچ کر سکا۔ جب سائٹ آخر کار لائیو ہوئی، تو کسی بھی صارف نے اس بٹن کے کرو (curve) پر کوئی تبصرہ نہیں کیا جس کے لیے میں نے اتنی تگ و دو کی تھی۔ انہیں صرف اس بات سے مطلب تھا کہ فارم بغیر کسی خرابی (crash) کے سبمٹ ہو رہا ہے یا نہیں۔
سبق یاد رہ گیا: پہلے اپنا کام لانچ کریں۔ آپ اس فیڈ بیک پر کام نہیں کر سکتے جو آپ کو ملا ہی نہ ہو۔ ڈھانچہ مضبوط بنائیں، اس بات کو یقینی بنائیں کہ بنیادی راستہ (core path) کام کر رہا ہے، اور اسے لائیو کر دیں۔ بہتری (refinement) ورژن دو کا کام ہے، ورژن زیرو کا نہیں۔ آپ کے صارفین آپ کو بتائیں گے کہ اصل میں کیا خراب ہے اور کیا صرف آپ کے خیال میں نامکمل ہے۔
بہت جلد بہت زیادہ بنا لینا
میرا پروجیکٹ کتابوں کی سفارشات شیئر کرنے کے ایک سادہ سے ٹول کے طور پر شروع ہوا تھا۔ بس یہی اس کا مقصد تھا۔ دوسرے ہفتے تک، میں نے یوزر لاگ ان سسٹم، ایک ڈائنامک ریٹنگ گراف، کمنٹس کا ایک پیچیدہ سیکشن، ڈارک موڈ ٹوگل، اور ای میل ڈائجسٹ کا خاکہ بھی تیار کر لیا تھا۔ ان میں سے کوئی بھی چیز ٹھیک سے کام نہیں کر رہی تھی۔ لاگ ان کا عمل آدھی بار ٹوٹ جاتا تھا۔ گراف کے پاس دکھانے کے لیے کوئی حقیقی ڈیٹا نہیں تھا۔ کمنٹ سیکشن میں ایک ہی بات بار بار لکھی جا سکتی تھی۔ اس دوران، کتابوں کی فہرست دکھانے والا بنیادی فیچر—جس کے لیے یہ سائٹ بنائی گئی تھی—ان تمام ٹوٹے پھوٹے اور ادھورے اضافی فیچرز کے ڈھیر تلے دب گیا تھا، جس نے ہوم پیج پر آنے والے ہر شخص کو الجھن میں ڈال دیا۔
ایک سادہ سی سائٹ جو ایک مسئلے کو صفائی سے حل کرتی ہے، وہ ہمیشہ ایک ایسی پیچیدہ سائٹ سے بہتر ہوگی جو دس کام بری طرح کرتی ہے۔ کوڈ کی ایک اور لائن لکھنے سے پہلے، یہ طے کریں کہ آپ کی پروڈکٹ صارف کے لیے کون سا ایک کام کرتی ہے۔ وہی بنائیں۔ اسے ٹیسٹ کریں۔ اسے تب تک نکھاریں جب تک کہ وہ قابل بھروسہ نہ ہو جائے۔ اگر صارفین واقعی ڈیش بورڈ یا سوشل فیڈ کا مطالبہ کریں، تو آپ اسے بعد میں شامل کر سکتے ہیں۔ تب تک، سوئس آرمی نائف (Swiss Army knife) بنانے کی خواہش سے بچیں جب کہ لوگوں کو صرف ایک تیز کچن نائف کی ضرورت ہو۔
ظاہری شکل و صورت کے پیچھے کے تجربے کو نظر انداز کرنا
میں نے خوبصورت فونٹس اور اسٹائلش کلر پیلیٹ (color palette) منتخب کرنے میں گھنٹوں صرف دیے۔ میں ہیرو سیکشن کے بیک گراؤنڈ گریڈینٹ (background gradient) کے بارے میں ضرورت سے زیادہ سوچتا رہا۔ پھر میں نے اس بات کو نظر انداز کر دیا کہ سائٹ کو استعمال کرنے کا اصل تجربہ کیسا تھا۔ صفحات بہت آہستہ لوڈ ہو رہے تھے کیونکہ میں نے بغیر کمپریشن کے فل ریزولوشن والی PNG فائلیں استعمال کی تھیں۔ نیویگیشن لیبلز میں ایسی چالاک الفاظ کا استعمال کیا گیا تھا جو دیکھنے میں تو اچھے لگتے تھے لیکن لوگوں کو اندازہ لگانے پر مجبور کر دیتے تھے کہ لنک انہیں کہاں لے جائے گا۔ بٹن پتلے اور اسٹائلش تھے لیکن فون کی اسکرین پر دبانے کے لیے بہت چھوٹے تھے۔
میں نے کٹھن تجربے سے سیکھا کہ ویژول ڈیزائن (visual design) اور یوزر ایکسپیریئنس (user experience) ایک دوسرے کے متبادل نہیں ہیں۔ ایک خوبصورت انٹرفیس بھی ناکام ہو جاتا ہے اگر وزیٹرز کو بینر امیج کے لیے کئی سیکنڈ انتظار کرنا پڑے، یا اگر وہ دو کلکس کے اندر آپ تک پہنچنے کا طریقہ نہ سمجھ سکیں۔ ہر عمل (interaction) کو سادہ بنائیں۔ نیویگیشن کے لیے سادہ زبان استعمال کریں۔ اپنی فائلز (assets) کو کمپریس کریں۔ چیک کریں کہ بٹن دبانے کے لیے کافی بڑے ہوں۔ رفتار اور وضاحت کوئی اضافی چیزیں نہیں ہیں جو آپ آخر میں شامل کرتے ہیں؛ بلکہ یہ وہ بنیاد ہیں جس پر باقی سب کچھ کھڑا ہوتا ہے۔
صرف اپنی مشین پر ٹیسٹنگ کرنا
میں نے پوری سائٹ ایک ہی لیپ ٹاپ، ایک ہی براؤزر اور ایک ہی اسکرین ریزولوشن پر بنائی۔ میری مشین پر سب کچھ بے عیب نظر آ رہا تھا۔ پھر ایک دوست نے اسے اپنے آئی فون (iPhone) پر کھولا۔ بٹن ایک دوسرے کے اوپر آ گئے۔ ٹیکسٹ اپنے کنٹینر سے باہر نکل گیا۔ ایک اور دوست نے میک (Mac) پر سفاری (Safari) استعمال کیا، اور پورا CSS گرڈ لے آؤٹ بکھر کر ایک ناقابلِ فہم ڈھیر بن گیا۔ میں نے خاموشی سے یہ فرض کر لیا تھا کہ اگر یہ میرے لیے کام کر رہا ہے، تو یہ سب کے لیے کام کرے گا۔ اس مفروضے کی وجہ سے مجھے ایک پورا ویک اینڈ ہنگامی طور پر غلطیاں ٹھیک کرنے (hotfixes) اور شرمندگی بھرے معذرت ناموں میں گزارنا پڑا۔
میری غلطی نہ دہرائیں۔ پبلش کرنے سے پہلے، اپنی سائٹ کو کروم (Chrome)، فائر فاکس (Firefox)، سفاری (Safari) اور ایج (Edge) پر چلا کر دیکھیں۔ مختلف چوڑائی والے فونز، ٹیبلٹس اور لیپ ٹاپس کو آزمانے کے لیے اپنے براؤزر کے ڈویلپر ٹولز (developer tools) کا استعمال کریں۔ ہر لنک پر کلک کریں۔ ہر فارم سبمٹ کریں۔ ونڈو کا سائز بار بار بدل کر دیکھیں۔ ٹیسٹنگ کے دوران پکڑے گئے بگ (bugs) پروڈکشن میں صارفین کے ذریعے پائے جانے والے بگ سے کہیں زیادہ سستے پڑتے ہیں۔
فیڈ بیک کو ذاتی حملے کے طور پر لینا
پروجیکٹ شیئر کرنے سے میں گھبراہٹ محسوس کر رہا تھا۔ کیا ہوگا اگر لوگوں نے اسے ناپسند کیا؟ جب ایک ساتھی نے اس فیچر کو چھوڑنے کا مشورہ دیا جس پر میں نے گزارا تھا