اذهب إلى المحتوى

البحث في الموقع

المحتوى عن 'نموذج أولي'.

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المحتوى


التصنيفات

  • الإدارة والقيادة
  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • السلوك التنظيمي في المؤسسات
  • عالم الأعمال
  • التجارة والتجارة الإلكترونية
  • نصائح وإرشادات
  • مقالات ريادة أعمال عامة

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • PHP
    • Laravel
    • ووردبريس
  • جافاسكربت
    • لغة TypeScript
    • Node.js
    • React
    • Vue.js
    • Angular
    • jQuery
    • Cordova
  • HTML
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • لغة C#‎
    • ‎.NET
    • منصة Xamarin
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • لغة Rust
  • برمجة أندرويد
  • لغة R
  • الذكاء الاصطناعي
  • صناعة الألعاب
  • سير العمل
    • Git
  • الأنظمة والأنظمة المدمجة

التصنيفات

  • تصميم تجربة المستخدم UX
  • تصميم واجهة المستخدم UI
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب GIMP
    • كريتا Krita
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • مقالات DevOps عامة
  • خوادم
    • الويب HTTP
    • البريد الإلكتروني
    • قواعد البيانات
    • DNS
    • Samba
  • الحوسبة السحابية
    • Docker
  • إدارة الإعدادات والنشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
    • ريدهات (Red Hat)
  • خواديم ويندوز
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • شبكات
    • سيسكو (Cisco)

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • مقالات عمل حر عامة
  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • العمل الحر المهني
    • العمل بالترجمة
    • العمل كمساعد افتراضي
    • العمل بكتابة المحتوى

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
    • بريستاشوب
    • أوبن كارت
    • دروبال
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
    • Trados
    • Memsource
  • برامج تخطيط موارد المؤسسات ERP
    • تطبيقات أودو odoo
  • أنظمة تشغيل الحواسيب والهواتف
    • ويندوز
    • لينكس
  • مقالات عامة

التصنيفات

  • آخر التحديثات

أسئلة وأجوبة

  • الأقسام
    • أسئلة البرمجة
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات

التصنيفات

  • كتب ريادة الأعمال
  • كتب العمل الحر
  • كتب تسويق ومبيعات
  • كتب برمجة
  • كتب تصميم
  • كتب DevOps

ابحث في

ابحث عن


تاريخ الإنشاء

  • بداية

    نهاية


آخر تحديث

  • بداية

    نهاية


رشح النتائج حسب

تاريخ الانضمام

  • بداية

    نهاية


المجموعة


النبذة الشخصية

تم العثور على 2 نتائج

  1. يستخدم مصممو تجربة المستخدم النماذج الأوَّليَّة طوال الوقت. إلا أن إقناع العملاء والإدارة بأنها تستحق الوقت والمال قد يكون مُحبِطًا. توضّح هذه المقالة الفوائد التجارية من النماذج الأوَّليَّة. النماذج الأوَّليَّة هي واحدة من أجدى الأدوات الموجودة تحت تصرفنا، ولكن الكثيرين يرون أنها أداة تصميم فاخرة ليس لها داعٍ. عندما تكون المواعيد النهائية ملحّة، والميزانيات محدودة، فغالبًا ما تكون النماذج الأوَّليَّة هي أول ما يُستغنى عنه، حيث تتجه المنظمات إلى الإنتاج أو تعتمد على وثائق المواصفات الطويلة على أمل اختصار العملية. لكنّ ما يحدُث في النهاية هو العكس تمامًا. ستُدرك بنهاية هذه المقالة لمَ النموذج الأوَّليّ أداة لا غنى عنها لمعالجة عدد كبير من مشاكل العمل، وخاصة عندما يتعلق الأمر بتحسين تجربة العملاء. تخلق النماذج الأوَّليَّة رؤية مقنعة تفشل العديد من الأفكار، ليس لأنها سيئة، بل لأن الناس لم “يفهموها”. يكون صعبًا في العادة تخيل منتجات أو خدمات أو ميزات جديدة، ولذلك تفشل وثائق المواصفات التقليدية وخطط الأعمال؛ لأنها لا تثير الناس بإمكانياتها؛ ولأنها لا تُري الناس ما يمكن فعله. عندما أراد موظفو ديزني إقناع السلطة التنفيذية باستثمار مليار دولار في تجديد حدائقهم لدعم تجربة أفضل للمستخدم، صنعوا نماذج أوَّليَّة. فبدلًا من كتابة وثيقة تجذب فقط السلطة التنفيذية على مستوى عقلاني، بنوا نموذجًا أوَّليًا حتى تتمكن الإدارة من الشعور بمدى روعة التجربة. يكتسب الإحساس بالمنتج أهميّة قصوى في ظلّ تنوّع الخدمات التي تقدّمها المنظّمات وتفاوت جودتها. حيث يتيح لك النموذج الأوَّليّ تجربة المنتج، ويحفّز أصحاب العمل للاطلاع على ما يمكن فعله. النماذج الأوَّليَّة وسيلة رائعة لتوحيد الناس حول رؤية مشتركة، وهذا له فائدة أخرى متعلقة. تقلل النماذج الأوَّليَّة سوء الفهم تتميّز النماذج الأوَّليَّة عن الوثائق الأخرى مثل خطط الأعمال والمواصفات بأنها تقلل من فرصة سوء الفهم. تتطلّب هذه الوثائق من الناس أن يتصوروا الحل النهائيّ، وهذا بالتالي يحتاج إلى درجة من التخيّل من جانب القارئ. ومن ناحية أخرى، يُظهِر النموذج الأوَّليّ لأصحاب العمل ما ستصنع. وهذا يعني أنه سيصبح لكل شخص نفس الصورة عن الهدف النهائي وهو ما يقلل كثيرًا من حاجة الناس إلى “ملء الثغرات” بخيالهم. يكافح العديد من أصحاب العمل لتصور المنتج أو الخدمة النهائية. ولا يؤدي هذا إلى سوء الفهم فحسب، ولكنه يؤدي أيضًا إلى الكثير من التغييرات بعد بدء العمل. تحد النماذج من كثرة التغيير سيقلل وضوح النموذج الأوَّليّ من التغييرات التي ستحدث في المشروع، لأن الكثير منها يولَد من سوء التخيُّل. علاوة على ذلك، تقلل النماذج التغيرات بطريقة أخرى أيضًا. لفهم لماذا يقلل النموذج من كثرة التغييرات يجب أن نعرف أولًا لماذا تحدث. أحد الأسباب الرئيسية هي أن أصحاب العمل يكافحون لتصور تفاصيل الخدمة حتى يروها أمامهم فيدركوا المفقود أو ما ينبغي أن يكون مختلفًا. يمكن أن يكون النموذج الأوَّليّ بمثابة مواصفات حية توفر هدفًا مشتركًا يمكن للجميع العمل على تحقيقه؛ فإنتاج تمثيل مرئي للمنتج في الأيام الأولى يساعد أصحاب العمل على رؤية ما هو مفقود أو خطأ في وقت مبكر، حين يمكن تعديل الأمور بسهولة. النماذج الأوَّليَّة مثالية للاختبار أحد الأسباب الرئيسية لإنشاء نموذج أوَّليّ هو أن يكون لديك شيء يمكنك اختباره، منتج ملموس يمكن وضعه أمام المستخدمين ويمكنهم تجربته، وبذلك تستطيع تحديد المشاكل في وقت مبكر، وبالتالي يصبح إصلاحها غير مكلف. بالإضافة إلى ذلك، يقدم اختبار النموذج الأوَّليّ ما هو أكثر من مجرد تحديد المشاكل. في الأيام الأولى من المشروع نقدم الكثير من الافتراضات حول ما يريده المستخدمون. بعض الشركات تدرس الأسواق، ولكن تمامًا مثل أصحاب العمل، فالمستخدمون غالبًا يكافحون لرسم صورة عما تقترح بناءه. وبإنشاء نموذج أوَّليّ، يمكن للمستخدمين تجربة الخدمة التي تفكر في بناءها. ويمكنهم توفير ردود فعل قيمة من شأنها أن توفر لك الكثير من المال. على سبيل المثال، قد تفكر في إضافة خواص، ثم يتضح أن المستخدمين لا يحتاجون إليها، وربما يفوتك شيء يعتبره المستخدمون ضروريًا، وستكون إضافته لاحقًا مكلفة. يتيح لك اختبار نموذج أوَّليّ التحقق من صحة الافتراضات، والثقة من أنك تقدم الخدمة الصحيحة. تشجع النماذج الأوَّليَّة التجريب والتكرار المشاريع الرقمية مختلفة جدًا عن غيرها. في المشاريع التقليدية، التخطيط المسبق أمر بالغ الأهمية، لأن تكلفة التغييرات بمجرد وضع المشروع قيد التنفيذ باهظة. ولكن عندما يتعلق الأمر بالمشاريع الرقمية، فمن السهل اختبار وتجربة نُهُج مختلفة حتى تجد الوسيلة المثالية. وحتى التكلفة تصبح معقولة عند عمل نموذج أوَّليّ. يمكنك بسرعة بناء الأفكار واختبارها، قبل تحسينها عن طريق التكرار. وبذلك، بجانب مستوى البيانات غير المسبوق التي يمكنك جمعها من النموذج الأوَّليّ، تستطيع التكرار بسرعة تجاه الحد الأدنى من منتج فعّال قاعدي Minimum viable product وحتى أكثر من ذلك. تحافظ النماذج الأوَّليَّة على انخفاض التكاليف جميع المزايا التي أوجزناها حتى الآن تتجلى في حجة واحدة مقنعة؛ النماذج توفر المال. لذلك من غير المعقول أن تكون التكلفة أكثر الأعذار لعدم صنع النموذج الأوّلي. بل الحقيقة هي أنه لا يمكنك تحمل تكاليف عدم صنع نموذج أوَّليّ. فقط ألقِ نظرة على جميع طرق توفير المال التي تقدمها النماذج: تقلل من الوقت الذي تقضيه في الاجتماعات محاولًا الاتفاق على اتجاه. تجنبك التغييرات التي تحدث بسبب سوء الفهم مع أصحاب العمل. تحد من التغييرات والتكاليف المرتبطة بتحديث الخصائص الجديدة. تجنبك إضافة خصائص غير مطلوبة. لكن تكلفة عدم صنع النماذج تتعدى المال؛ أنت تتكلف الوقت أيضًا. تتعطل المشاريع، وتفوتك المواعيد النهائية، وتضيع الفرص. الشركة تُضيِع الوقت بسبب عدم وضوح ما تصنع. سيكلّف هذا الوقت المنظمة في نهاية المطاف المال وحصتها في السوق. مرة أخرى، من غير المعقول أن يكون عدم وجود الوقت حجة أخرى ضد النماذج الأوَّليَّة. مرة أخرى، أجادل بأنك ليس لديك الوقت الكافي لعدم صنع النموذج. قاوم رغبة التسرع في المشاريع أو اللجوء إلى مراحل المواصفات الطويلة. وابدأ بنموذج أوَّليّ، وبذلك ستوفر المال والوقت على المدى الطويل. ترجمة - بتصرّف - للمقال What are the business benefits of building prototypes? لصاحبه Paul Boag. حقوق الصورة البارزة محفوظة لـ Freepik
  2. عندما أطلقنا تطبيق المحادثة الجديد في السنة الماضية، أضفنا للعملاء إمكانية إنشاء ملفات تعريف شخصية غنية بحيث يتأكد المستخدمون أن هناك دائما شخصا حقيقيًّا في الجهة المقابلة. والمشكلة؟ لا أحد يستخدم الميزة. بعد أن أطلقناه بوقت قصير, أكمل 13-15% من العملاء فقط ملفات التعريف الخاصة بهم. ملئت أغلب الملفات جزئيا بينما تُركت العديد منها غير ممسوسة. بعد التحدث مع الزملاء في فرق البحث والتحليل لدينا، اكتشفنا سببيْن رئيسيْن لهذا الاستعمال المنخفض: الوضوح: فقد كانت القدرة على إنشاء ملفك الشخصي محشورة في أماكن تصعب رؤيتها ضمن التطبيق. التثقيف: فقد كان الناس غير مقتنعين بأهمية الملفات الشخصية في تأسيس علاقات شخصية مع عملائهم. جزء واحد من حل أشمل وُجِدَت الملفات التعريفية في أجزاء عدة من المنتج، ممّا يعني أننا اضطررنا إلى إشراك فرق عمل مختلفة لزيادة تبني الميزة. دمَج فريق التطوير إنشاء ملفات التعريف في عمليّة التسجيل، بينما أعطى المنتج وضوحا أكبر لإمكانية تحرير ملف التعريف ضمن التطبيق نفسه. بجميع الأحوال، كانت هناك فرصة كبيرة لزيادة الفعالية وذلك بالاستفادة من ميزات تطبيقات هواتفنا المحمولة. فقد قام حوالي 45% من أعضاء فريقنا ممن تحدثوا مع عملائهم باستخدام تطبيقاتنا على أندرويد أو iOS. البدء ينشئ المصممون في Intercom، بالنسبة لكل مشروع جديد، قائمة بسيطة بالأمور الأساسية المسببة للمشكلة التي يحاولون حلها. الأمر الذي يساعد بالتفكير في حلول عامّة. وحلولنا كانت كما يلي: زيادة توعيّة المستخدمين الذين لم يكملوا ملفاتهم التعريفية أو أكملوها جزئيا. تثقيف المستخدمين بأهمية ملفات التعريف العامة. تسهيل عملية تعديل ملفات التعريف للمستخدمين في الوقت الذي يريدونه. التفكير في الأنظمة أخذنا في البداية ملفات التعريف لنساعد الفريق في فهم النظام وتحديد المكونات الخاصة التي تحتاج الأولوية. مما يعني إعداد جرد بالأجزاء والحالات والقواعد وغيرها. إليك مثالا عن منشور كان معلقا على حائط مساحة العمل الخاصة بنا. الأفكار تأتي من كل مكان ساعد توثيق النظام الفريق في مناقشة العقبات التقنية في وقت مبكر، وحتى في هذه المرحلة المبكرة قدم فريق الهندسة اقتراحات لم يكن فريق التصميم قد فكر بها. على سبيل المثال، ذكر أحدهم أن باستطاعتنا استخلاص بيانات من المصادر الموجودة لملْء مكونات محددة ضمن ملف التعريف. بما أن اسم الشخص موجود لدينا عندما يسجّل دخوله عبر تطبيق الجوّال، فلم لا ننسخ هذ الاسم إلى ملف التعريف ونوفر عليه زمن إدخال تلك البيانات يدويا؟ بعد رسم بعض الاتجاهات، التقينا بEmmet مدير تصميم المنتجات لدينا، للحصول على ردود الفعل واتخاذ قرار بشأن الخطوات التالية. وفيما يلي الخيارات الأربعة التي قدّمناها. الخيار الأول الخيار الثاني الخياران الثالث والرابع إن المكونات الأساسية هنا هي المقاطعة (الإزعاج) والتثقيف . لا نريد أن يكون التثقيف قابلا للتجاوز بسهولة، كما نريد مساحة لنتمكن من تثقيف المستخدمين بأهمية ملف التعريف ومكوناته. إلا أننا نعرف أيضًا أن المزيد من المقاطعة يعني مزيدا من النفور (أي أن المستخدمين يريدون التجاوز)، لذا نريد الإبقاء على عدد الخطوات في الإرشادات التفصيلية منخفضا قدر الإمكان. قررنا في النهاية أن نستخدم خيار الإرشاد البسيط. وفيما يلي القرارات الناتجة عن الاجتماع. يا له من تقدم! تصميم الحل حتى هذه النقطة، اتخذنا قرارا بأمرين. سنضيف إرشادًا بسيطًا لتطبيقنا في البداية نسأل فيه عن أي مكونات مفقودة في ملف التعريف بغية ملئها (المقاطعة والتثقيف). كان هدفنا الثالث إضافة القدرة على “تعديل ملف التعريف من أي مكان”. قررنا العمل ضمن نمط التصفّح الموجود حاليّا في التطبيق وإضافة أيقونة تحرير بسيطة ضمن قائمة التنقل ينتُج عنها بدء الإرشاد. يظهر يسار الصورة أدناه المستكشف الحالي، في ما يوجد المستكشف المُقترَح يمينها. على مستوى النظام، أسسنا ثلاث حالات للمستخدمين ستتحكم بمدى تقدّمهم في الإرشادات. نعلم اعتمادا على التوجّه العام الي اخترناه أن المسار سيتكون من خطوات رئيسية ثلاث (انظر المخطط في الأسفل) نريد جعلها أكثر سهولة وأخف وزنا قدر الإمكان. إن عملية الإرشاد واضحة جدا من حيث تصميم النظام. فهي مسار ثابت من البداية إلى النهاية، لكن المنطق يصبح أكثر تعقيدا عند أخذ حالات المستخدمين بالحسبان. نريدك أن تنتقل مباشرة إلى الجزء الأكثر صلة بحالتك عوضا عن إرغامك على المرور بعملية الإرشاد بكاملها. من المهمّ جدا أخذ خطوات خاصة بالمنصة بعين الاعتبار كأذونات الكاميرا. فليست كل خطوة شاشة جديدة. مرة ثانية، طبعت هذه المخططات وعلقت في قاعة العمل. غالبا ما يكون المهندسون أمام الجدار يدقّقون سير العملية، وقد يجدون حالة حرجة تتطلب منا إجراء تغييرات. هكذا يبدو المخطَّط النهائي لخطوات الإرشاد. التنفيذ أصبح لدينا الأساس لنبني عليه كل جزء من الأجزاء. يحصل التصميم المرئي والتفاعلي لحظيًّا، مع معرفة أننا سنستمر بتعديل المرئيات أثناء بنائها. وجدنا بأنه يجب أن تكتمل التفاصيل المتعلقة بالتفاعلات المعقدة والرسوم المتحركة بأسرع ما يمكن (وهو السبب الذي تعدّ من أجله نماذج الوثوقية العالية عظيمة). لأنه من الصعب تغييرها لاحقا على عكس التعديلات على التصميم المرئي كتحديث الموجودات والألوان وغيرها. استخدمنا Framer JS كطريقة لوضع نماذج أولية للأفكار التفاعلية الأولى، ومناقشتها مع المهندسين والاتفاق على ما يمكن عمله.حصلنا على مخطّط نهائي لتطبيق iOS بعد حوالي 12 نموذجًا أوليًّا. من وجهة نظر التصميم المرئي، تتبع تطبيقات جوالاتنا عن كثب علامتنا التجارية. ويجب على أي تصميم جديد أن يحافظ على تلك اللغة بالإضافة إلى إعادة استخدام أية أنماط مطلوبة. عملنا مع فريق تصميم علامتنا التجارية على الرسوم التوضيحية لشاشات الافتتاح والتأكيد. كان المحتوى هاما جدا لمشكلة التثقيف. توجب علينا أن نشرح أهمية الملفات الشخصية بطريقة موجزة. عمل التصميم عن قرب مع Elizabeth McGuane محللتنا الإستراتيجية التي تُعنَى بالمحتوى، لخلق تجربة أكثر إقناعا ومساعدة المستخدمين في فهم أهمية الملف الشخصي الجيد. في ما يلي مثال على توثيق إستراتيجية المحتوى. الاختبار والتطويع كنا مدركين للتشتت الذي سيحصل خلال العملية وأن عددا من الناس على الأغلب سيتجاوزون الإرشادات، حتى بعد إضافة خيار تذكير المستخدمين بإكمال ملفاتهم الشخصية لاحقا. كان إعداد مقاييس لمدى التقدّم في إكمال الملف هو الحل، بالإضافة إلى السماح بمدة تجريبية للتعديل بناءً على النتائج. بالنسبة لنسختنا التجريبية الأولى، كان معدل الإكمال الأوّلي منخفضا جدا وبخاصة في أندرويد. قمنا بمجموعة من التعديلات على التصميم كإزالة نتوء زر “ذكرني لاحقا” وتبديل التخطيط وتعديل المحتوى ليصبح أكثر تسلية وأقل إملاءً للتعليمات. بعد حوالي أسبوع من التعديلات السريعة والمراقبة، ازداد معدل الإتمام على نحو مفاجئ. بفضل تدخل عدة فرق ارتفع معدل إكمال الملفات الشخصية الإجمالي من 14% إلى 46% خلال مدة شهر. لعبت عملية الإرشاد في الجوّال دورا هاما في هذا الارتفاع. خرجنا أيضا مع مجموعة كبيرة من النصائح الجاهزة التي يمكن أن نطبقها على مشروعنا التالي: تأكد من وضوح المشكلة لجميع المشاركين في العمل. ضع المشكلة تحت البحث والقياس، واستخدم أهدافا عامة لتوجيه حلولك. بغض النظر عما تقوم بصنعه، فكر بالكبير وابدأ بالصغير. يجب أن يعمل المصمّم إلى جانب المهندس في وقت مبكر وعلى نحو مستمر للحصول على الأفكار والتحقق من المفاهيم. يجب أن ينجز التصميم التفاعلي في أقرب وقت ممكن كونه من الأسهل التعديل على التصميم البصري أثناء إنشائه. اعرف عوامل نجاحك وتتبع نجاح حلولك وتأكد من وجود وقت للتعديل. إن اتباع عملية منطقية وواضحة كهذه سيزيد بقدر كبير من فرصنا في إنتاج ميزة يستخدمها الناس فعلا. قد يبدو الأمر وكأنه مليء بالتفاصيل في البداية، لكن بمجرد أن تأخذها كعادة ستصبح جزءا من طبيعتك. ترجمة - بتصرّف - للمقال Design principles: what to do when nobody is using your feature لصاحبه Brendan Fagan. حقوق الصورة البارزة محفوظة لـ Freepik
×
×
  • أضف...