🚀 AllWDbook — من الفكرة إلى الإطلاق
AllWDbook Build Journal
من فكرة بسيطة إلى منصة حقيقية: كيف بدأ بناء AllWDbook
نظرة عملية على المراحل الأولى لبناء AllWDbook، من تحديد المشكلة إلى تحويل الفكرة إلى منصة تعمل فعليًا على الويب.
عندما بدأت AllWDbook، لم تكن أمامي خريطة كاملة لمنصة كبيرة، ولم أبدأ بقائمة طويلة من المزايا التي يجب بناؤها. البداية كانت أبسط من ذلك بكثير: كانت هناك مجموعة من المشكلات التي أواجهها أثناء عملي في النشر الرقمي، وكنت أريد طريقة أكثر تنظيمًا للتعامل معها.
في البداية كان التفكير منصبًا على أداة أستخدمها بنفسي. لكن كلما بدأت بحل مشكلة، ظهرت العلاقة بينها وبين مشكلة أخرى: البحث عن فكرة يقود إلى النيتش، والنيتش يقود إلى الكلمات المفتاحية، ودراسة السوق تقود إلى المنافسين، ثم تأتي الحسابات والغلاف وتجهيز الكتاب.
بمرور الوقت أصبح واضحًا أن ما أبنيه لم يعد مجرد أداة صغيرة منفصلة. بدأ يتحول إلى نظام يجمع مراحل متعددة من رحلة الناشر في مكان واحد.
هذه المقالة ليست قصة عن بناء مشروع ضخم من اليوم الأول. إنها قصة عن الانتقال التدريجي من مشكلة شخصية واضحة إلى منصة حقيقية تعمل على الويب ويستطيع ناشرون آخرون استخدامها.
بدأت بالمشكلة، لا بشكل المنصة
من السهل عند التفكير في مشروع جديد أن نبدأ بالسؤال: كيف يجب أن يبدو الموقع؟ ما الصفحات التي يجب أن يحتويها؟ وما عدد الأدوات التي نحتاج إلى إضافتها؟ لكن هذا لم يكن السؤال الأول في AllWDbook.
السؤال الأول كان أبسط: ما أكثر الأشياء التي تجعل عملي كناشر أبطأ وأكثر تشتتًا؟ عندما بدأت أجيب عن هذا السؤال ظهرت أمامي مشكلات عملية واضحة، مثل البحث عن الكلمات المفتاحية والنيتشات، الانتقال إلى Micro Niche أكثر تحديدًا، دراسة السوق، متابعة المنافسين، حساب الأرباح وتجهيز أبعاد الغلاف.
هذا الفرق مهم. عندما يبدأ المشروع من قائمة مزايا، قد ينتهي بمجموعة أدوات لا تربط بينها فكرة واضحة. أما عندما يبدأ من مشكلة حقيقية، فإن كل ميزة يجب أن تبرر وجودها بأنها تقلل خطوة مزعجة أو تساعد المستخدم على اتخاذ قرار أفضل.
لهذا لم يكن الهدف في البداية أن أقول إن AllWDbook يجب أن تحتوي على أكبر عدد ممكن من الأدوات. الهدف كان أن تصبح المهام التي أكررها أثناء العمل أكثر سهولة وتنظيمًا.
أول نسخة مفيدة أهم من أول نسخة كاملة
في المشاريع الرقمية توجد دائمًا رغبة في الانتظار حتى تصبح الفكرة كاملة. لكن المنصة لا تصبح مفيدة لأنها تحتوي على كل شيء، بل لأنها تبدأ بحل مشكلة فعلية بصورة يمكن استخدامها.
لذلك كان التركيز على جعل الأدوات الأساسية تعمل أولًا. لم يكن الهدف بناء كل الاحتمالات الممكنة منذ البداية، بل التأكد من أن المستخدم يستطيع فتح المنصة، الوصول إلى أداة يحتاجها، إدخال ما لديه من معلومات والحصول على نتيجة تساعده في المرحلة التالية.
هذا الأسلوب غيّر طريقة بناء AllWDbook. بدل تطوير أجزاء كثيرة في الوقت نفسه، أصبح من الممكن إضافة كل أداة على أساس احتياج واضح، ثم تحسين طريقة استخدامها بعد أن تصبح جزءًا حقيقيًا من المنصة.
وجود نسخة تعمل فعليًا يغيّر أيضًا طريقة التفكير. المشكلات التي تبدو مهمة على الورق قد تصبح أقل أهمية عند الاستخدام، وفي المقابل قد تظهر تفاصيل صغيرة تؤثر كثيرًا في تجربة المستخدم.
من أدوات منفصلة إلى سير عمل واحد
مع إضافة الأدوات، ظهر تحدٍ جديد: مجرد جمع الأدوات في موقع واحد لا يكفي. إذا بقي المستخدم يشعر أنه ينتقل بين وظائف لا علاقة بينها، فإن المشكلة الأصلية لم تُحل بالكامل.
بدأت أنظر إلى AllWDbook على أنها رحلة. قد يبدأ الناشر بفكرة، ثم يبحث عن اتجاه أكثر تحديدًا، ثم يفحص كلمات مرتبطة بها، وبعد ذلك ينظر إلى السوق والمنافسة. لاحقًا يحتاج إلى حسابات مرتبطة بالطباعة والأرباح، ثم إلى تجهيز عناصر مثل الغلاف والوصف.
هذه المراحل ليست متطابقة لكل ناشر، لكنها مرتبطة ببعضها. لذلك أصبحت قيمة المنصة في قدرتها على جمع هذه المراحل داخل بيئة واحدة أكثر من مجرد عدد الأدوات الموجودة فيها.
وهنا بدأت AllWDbook تتحول فعليًا من أداة شخصية إلى منصة لها منطق واضح: أدوات للنشر الرقمي تعمل داخل تجربة واحدة.
التصميم أصبح جزءًا من المنتج
بعد أن بدأت الوظائف الأساسية تتشكل، لم يعد التصميم مجرد طبقة تجميلية. إذا كانت المنصة تحتوي على أدوات مفيدة لكن الوصول إليها متعب، فإن جزءًا كبيرًا من فائدتها يضيع.
لهذا أصبح الاهتمام بالواجهة مرتبطًا بالاستخدام الفعلي: كيف يصل المستخدم إلى الأدوات بسرعة؟ كيف تظهر المعلومات على شاشة الهاتف؟ كيف تكون الأزرار واضحة؟ وكيف نحافظ على هوية واحدة رغم اختلاف وظائف الأدوات؟
تم اعتماد طابع بصري داكن مع الأزرق البحري والبرتقالي، لكن الأهم من الألوان نفسها كان الحفاظ على الاتساق. المستخدم يجب أن يشعر أنه ما يزال داخل AllWDbook حتى عندما ينتقل من أداة بحث إلى حاسبة أرباح أو أداة غلاف.
الصورة المرفقة مع هذه المقالة تمثل المرحلة الحالية من هذا التطور: لم تعد الواجهة مجرد مكان لعرض أداة واحدة، بل أصبحت مدخلًا لمنظومة نشر رقمية متكاملة.
الهاتف لم يكن نسخة مصغرة من الحاسوب
أثناء تطوير المنصة أصبح واضحًا أن تجربة الهاتف لا يمكن أن تكون مجرد نسخة مضغوطة من تصميم سطح المكتب. كثير من المستخدمين يصلون إلى الأدوات من شاشة صغيرة، ولذلك يجب أن تكون الأولويات مختلفة.
العناصر الأساسية تحتاج إلى مساحة مناسبة للمس، والنصوص تحتاج إلى وضوح، والأدوات يجب أن تبقى قابلة للاستخدام دون أن يصبح المستخدم مضطرًا إلى التكبير أو التحرك أفقيًا.
لهذا أصبح التفكير Mobile-First جزءًا من عملية التطوير نفسها. قبل اعتبار أي واجهة جاهزة، يجب أن تعمل بصورة مريحة على الهاتف، لا أن تبدو جيدة فقط على شاشة كبيرة.
هذا القرار أثّر في الصفحة الرئيسية، القوائم، الأدوات، وحتى المدونة التي تقرأ منها هذه المقالة.
بناء تجربة عربية وإنجليزية
مع تحول AllWDbook إلى منصة يمكن أن يستخدمها جمهور أوسع، أصبحت اللغة جزءًا آخر من بنية المشروع. لم يكن المطلوب مجرد ترجمة بعض الأزرار، بل جعل التجربة تعمل بشكل طبيعي بالعربية والإنجليزية.
العربية تحتاج إلى اتجاه من اليمين إلى اليسار، بينما الإنجليزية تعمل من اليسار إلى اليمين. النصوص والعناوين والتنقل يجب أن تحافظ على وضوحها في الحالتين.
هذا المبدأ امتد لاحقًا إلى المدونة نفسها. بدل وضع المقال العربي والإنجليزي في رابط واحد يتغير محتواه حسب اللغة، أصبح لكل لغة مسارها المستقل، بحيث تكون بنية الموقع أوضح للمستخدم ومحركات البحث معًا.
كل قرار من هذا النوع يزيد العمل قليلًا في البداية، لكنه يجعل المنصة أكثر تنظيمًا عندما يبدأ المحتوى والوظائف في التوسع.
الانتقال من مشروع أبنيه إلى منصة حقيقية على الويب
هناك فرق كبير بين أن تعمل الأداة أثناء التطوير وبين أن تصبح خدمة يمكن فتحها من رابط عام واستخدامها يوميًا. هذه المرحلة أضافت طبقة جديدة من الأسئلة: كيف ننشر التحديثات؟ كيف نتأكد من أن النسخة الحية مستقرة؟ وكيف نستطيع تطوير المنصة دون كسر ما يعمل بالفعل؟
اعتماد GitHub لإدارة المشروع وVercel للنشر جعل التحديثات جزءًا من سير عمل واضح. كل تغيير يمكن تتبعه، والمنصة يمكن إعادة بنائها ونشرها بعد التحديث.
لكن الأهم أن هذا فرض انضباطًا في التطوير. عندما يكون هناك مستخدم يستطيع فتح الموقع الآن، لم يعد من المقبول التعامل مع كل تعديل كتجربة معزولة. يجب الحفاظ على الوظائف المستقرة أثناء إضافة الجديد.
في هذه النقطة بدأت AllWDbook بالنسبة لي تتجاوز مرحلة المشروع الشخصي. أصبحت منصة حقيقية لها نسخة إنتاجية، نطاق، مستخدمون، أدوات، محتوى وخطة تطوير مستمرة.
تقليل الاحتكاك أمام المستخدم
أحد الأسئلة المهمة أثناء بناء المنصة كان: كم خطوة نطلب من المستخدم قبل أن يصل إلى القيمة التي جاء من أجلها؟
من السهل إضافة التسجيل الإجباري وكلمات المرور في بداية كل تجربة، لكن ذلك قد يجعل المستخدم يواجه حاجزًا قبل أن يفهم أصلًا ما الذي تقدمه المنصة.
لذلك كان الاتجاه في AllWDbook هو السماح بالوصول إلى التجربة دون فرض حساب تقليدي منذ اللحظة الأولى، مع وجود نظام وصول مناسب للمزايا المدفوعة.
هذا مثال على أن بناء المنتج لا يتعلق فقط بإضافة الوظائف. أحيانًا يكون القرار الأفضل هو إزالة خطوة لا يحتاجها المستخدم.
المنصة الحقيقية لا تصل إلى نسخة نهائية
عندما بدأت AllWDbook، كان من الممكن أن أتخيل نقطة أقول عندها إن المشروع انتهى. لكن العمل على منصة حقيقية غيّر هذا التصور.
كل أداة يمكن تحسينها، وكل واجهة يمكن أن تصبح أوضح، وكل تجربة استخدام تكشف شيئًا جديدًا. كذلك يتغير المحتوى، وتتوسع المدونة، وتظهر احتياجات جديدة لم تكن موجودة في البداية.
لهذا أصبحت أتعامل مع AllWDbook كمنتج يتطور على مراحل. لا يعني ذلك إضافة ميزات بلا نهاية، بل الاستمرار في مراجعة ما إذا كانت المنصة تحل المشكلات التي بُنيت من أجلها بطريقة أفضل.
الانتقال من فكرة إلى منصة لم يحدث في لحظة واحدة. حدث من خلال سلسلة قرارات صغيرة: حل مشكلة حقيقية، بناء نسخة تعمل، اختبارها، تحسينها، ثم الانتقال إلى المشكلة التالية.
الدرس الأهم من الرحلة حتى الآن
أهم ما تعلمته من بناء AllWDbook هو أن المنتج الرقمي لا يحتاج في البداية إلى أن يكون كبيرًا، لكنه يحتاج إلى سبب واضح لوجوده.
الفكرة البسيطة يمكن أن تتحول إلى منصة حقيقية عندما تكون مرتبطة بمشكلة يعرفها صاحب المشروع جيدًا، وعندما يتم بناء الحل تدريجيًا بدل محاولة توقع كل شيء من البداية.
في حالة AllWDbook، لم تكن نقطة التحول هي إضافة أداة معينة. نقطة التحول كانت عندما أصبح واضحًا أن هذه الأدوات يمكن أن تعمل معًا داخل تجربة واحدة تخدم رحلة الناشر.
وهذا هو الفرق بين مجموعة وظائف وبين منتج: المنتج يربط الوظائف بهدف واضح ويجعل استخدامها جزءًا من تجربة متماسكة.