قصة إعادة تصميم واحدة غيرت نهج التطوير في ISPsystem.
انضممت إلى ISPsystem في أبريل 2016. في ذلك الوقت ، كان الوضع مع تصميم المنتج على النحو التالي: تم اتخاذ قرارات المنتج من قبل الإدارة والمبرمجين ، ولم يكن هناك مصممين أو مصممين. تطلب وضع السوق منتجات ذات "واجهات أخرى" ، لذلك قررت الإدارة إعادة تصميم جزء عميل
BILLmanager . كان من المفترض أن يكون هذا بالون اختبار ، المحاولة الأولى للقيام بشيء بتصميم جديد.
لقد كنت مصمم UX الوحيد في الشركة: لقد درست منتجًا حاليًا ، وشاركت في أبحاث المستخدمين ، وتعرفت على تعليقات الشركاء والمسوقين. هذه هي الممارسات المعتادة لتصميم المنتج ، مع مراعاة تفاصيل المنتج المعقد. قدم لي مدير المنتج مساعدة كبيرة ، لأنه كان يعرف المنتج على أفضل وجه.
في كل أسبوع ، عرضت النتيجة على شكل نماذج أولية ودوائر وما إلى ذلك لإدارة الشركة. هذا مشابه لكيفية عمل مصممي العملاء مع العملاء ، مع كل الإيجابيات والسلبيات: يمكنك إعفاء نفسك من المسؤولية عن القرارات ، والشيء الرئيسي هو "بيعها" إلى الإدارة. ولكن بما أن لدي خبرة بالفعل في شركة منتجات وقد وثقتني الإدارة في هذه الأمور ، فقد توصلنا بسرعة إلى العمل معًا على الحلول التي طورتها وتحولت إلى نموذج أولي.
يلتقي المطورون بالنموذج الأولي
بحلول أغسطس 2016 ، كانت النماذج الأولية لعميل BILLmanager جاهزة في شكلها المفاهيمي. تم نقل وظيفة الإصدار القديم من المنتج بالكامل إلى الواجهة الجديدة ، مع بعض التحسينات. تم تطوير النماذج الأولية بشكل جيد من وجهة نظر بصرية ، لكنني أردت المزيد ، لذلك طلبت تصميمًا مرئيًا من شركة خارجية. ومع ذلك ، أدركنا بسرعة أن هذه المحاولة كانت فاشلة ، وكان العمل التكراري المستمر مطلوبًا على المكون البصري ، وكنا بحاجة إلى مصمم بصري في الموظفين. في غضون شهرين ، قمنا بتطوير لغتنا البصرية الخاصة. في الواقع ، كان لدينا في تلك اللحظة عدة أجزاء من نظام التصميم المستقبلي: لغة بصرية وعناصر وقوالب.
في موازاة ذلك ، من حوالي أغسطس 2016 ، بدأ المطورون في تنفيذ واجهة جديدة. اعتبر الرجال النموذج الأولي كبديل للمهمة التقنية. كما يحدث في مثل هذه اللحظات ، بدأت الأسئلة تظهر على نطاق واسع ، والتي تتلخص في شيء واحد: هل نفعل ما يفعله المبرمجون بسرعة وببساطة ، أو ما اخترعه المصمم وصممه؟ لحل هذه المشكلات بسرعة وتبسيط الاتصال ، أنشأنا فريقًا من المصممين والواجهة الأمامية.
قسم UX كفريق من المصممين والعرض الأمامي
بحلول منتصف خريف 2016 ، تم تشكيل قسم UX في الشركة تحت قيادتي ، والذي تألف من مصممي UX ، ومصمم مرئي ، ومناقصات أمامية ، ومختبرين. كانت مهمتنا الفورية هي إطلاق حساب ISPsystem الشخصي بواجهة جديدة (نستخدم BILLmanager في مكاننا) بحلول نهاية مارس 2017 وكان لدينا مجموعتان من المشاكل. توقع المطورون بشكل سيئ توقيت عملهم ، ولم نفهم تمامًا كيفية بناء التفاعل بين المطورين والمصممين.
ما نقدمه للمطورين
عند استخدام Sketch و Zeplin ، يكون التفاعل بين المصممين والمطورين بسيطًا جدًا. ولكن كان لدينا أكثر من 150 صفحة في نموذج أولي تفاعلي تعلمنا استخدامه كبديل للمعارف التقليدية للمبرمجين ومواصفات للمختبرين. لم نرغب في عرض جميع الصفحات التي يزيد عددها عن 150 صفحة مع حالات مختلفة في Sketch ، وقد توصلنا إلى استنتاج مفاده أننا لن نقوم بذلك إلا للصفحات الفريدة. أيضًا ، يجب أن تظهر جميع العناصر في Zeplin: الأزرار وحقول النموذج وما إلى ذلك. بعد مرور بعض الوقت ، تعلمنا اسم مثل هذا النهج - هذا
نظام تصميم يعتمد على التصميم الذري . لا يزال قيد التطوير ، ولكن كل من المصممين والمطورين يستخدمونه بالفعل. آخر مصمم في الشركة لنظام التصميم هو المصمم المرئي.
نتيجة لذلك ، نوفر للمطورين نوعين من القطع الأثرية:
- تخطيطات لما سيصبح نظام تصميم في Zeplin (أو بالأحرى في Figma) ،
- نماذج أولية للمنتج ، بديلاً عن المعارف التقليدية في شكل HTML تم إنشاؤه من Axure.
في الوقت نفسه ، مصمم UX جاهز دائمًا لإخبار المطورين والمختبرين بما يجب أن يعمل وكيف يبدو.
سكروم مع المصممين
في فبراير 2017 ، قررنا تحسين دقة التنبؤ بالمواعيد النهائية وحاولنا تنفيذ سكروم. تعقيد سكروم لدينا هو أن أعضاء الفريق مختلفون للغاية من حيث الكفاءات والثقافة. المصممون ليسوا مثل المبرمجين: نخطط مهامنا بشكل مختلف ، لدينا مواقف مختلفة لما يعتبر نتيجة جيدة.
إليك كيفية بناء العملية:
- المصممين يتقدمون إلى الأمام ؛
- هناك تراكم نموذج أولي ، تم وضعه بعبارات عامة ، حيث يمكنك أن ترى كيف يجب أن يكون المنتج بأكمله ؛
- في وقت التخطيط للسباق ، يقدم المصممون نماذج أولية ونماذج نموذجية لجزء من المنتج الذي من المقرر القيام به في السباق. قام مصمم UX بتفصيل هذه النماذج الأولية ووصفها إلى درجة تمكن المطورين من تعيين مهامهم وتفكيكها ؛
- في وقت التخطيط ، ينصح مصمم UX بنشاط المطورين والمختبرين بشأن ماذا وكيف يجب أن يعملوا ؛
- في وقت التخطيط ، يجب على مدير المنتج إخبار مصمم UX بأي جزء من المنتج المخطط القيام به في السباق التالي حتى يتمكن مصمم UX من التخطيط لعمله.
أدرك المطورون بسرعة قيمة مصمم UX ، والذي يمكن معالجته بسرعة عندما لا يكون واضحًا كيف وكيف يجب أن يعمل. لا تزال الصراعات تحدث ، لكن ممارسات سكروم والعمل الجماعي والأهداف المشتركة تساعد على التغلب عليها.
ما علاقة المختبر بها؟
كان دور المختبر في العمليات مهمًا جدًا. هذا هو الشخص الذي يعرف وظائف المنتج على أفضل وجه. كان المختبر هو أول شخص ينظر إلى النماذج الأولية لمصمم UX ويعطي ملاحظات سريعة من حيث امتثال النموذج الأولي ووظيفته. تصبح النماذج الأولية المعتمدة مصدرًا للمعرفة للمختبر حول كيفية عمل المنتج. كان الجانبان مهتمين بالتعاون الوثيق.
ونتيجة لذلك ، أطلق الفريق في الوقت المحدد الواجهة الجديدة للحساب الشخصي لـ ISPsystem. تعلمنا كيفية العمل على سكروم للتنبؤ بعمل قسم UX كفريق من الواجهة الأمامية والمصممين. وبحلول صيف عام 2017 ، واجهوا مشكلة جديدة.
BILLmanager منتج مرن. وهذه مشكلة للمصمم
عندما يقوم المصمم برسم ملصق أو طباعة كتاب أو عمل غلاف لمجلة ، فإنه يعمل بمعلومات ثابتة. يحتوي على نص معين وصور معينة ومحتويات أخرى.
عندما يقوم المصمم بتصميم واجهة تطبيق أو موقع ، فإن المعلومات ليست ثابتة. هناك معلومات حول البيانات ، ولكن البيانات نفسها ليست كذلك. لنفترض أن هناك مدونة ، كل إدخال مدونة له عنوان ، تعليق توضيحي ، تاريخ إصدار ما بعد ، صورة ، إلخ. لا يوجد عنوان محدد ، ولكن هناك فهم بأنه سيكون هناك عنوان دائمًا ، وسيكون للتاريخ دائمًا تنسيق التاريخ. أصبحت المهمة أكثر تعقيدًا ، ولدينا أنواع بيانات ، ولكن لا توجد بيانات: نحن بحاجة إلى التفكير في المحتوى الذي قد يكون ، والقيود التي يمكن ويجب فرضها عليه. على الأرجح ، ستكون هناك قيمة فنية أقل من الملصق ، لكن المصمم يريد الحصول على نتيجة ستكون جميلة ومريحة ومفهومة.
في حالة BILLmanager ، يمكن لمسؤول موفر الاستضافة تغيير الإعدادات بحيث ، على سبيل المثال ، بالنسبة لنموذج طلب خادم مخصص ، يمكن أن تكون مجموعة الحقول مختلفة. في إحدى الحالات ، سيكون لدينا بالتأكيد معالج وقرص وذاكرة ، وفي الحالة الأخرى ، لن يكون (أو سوف ، ولكن ، على سبيل المثال ، حقل واحد) ، وهذا لا يمكن التنبؤ به. في هذه الحالة ، لا يمتلك المصمم حتى مجموعة بيانات ثابتة ، فنحن لا نعرف فقط بيانات محددة ، ولا نعرف أنواع هذه البيانات ... وهذا يعقد العمل.
عندما بدأنا في عمل النسخة المعبأة ، بدأ المختبرون بالتحقق من جميع الإعدادات الممكنة في BILLmanager. ثم أصبح من الواضح أن النماذج الأولية ، من ناحية ، ليست كاملة بما يكفي لتغطية إمكانات الإعدادات المرنة لـ BILLmanager. من ناحية أخرى ، لم تكن بنية المنتج القديم مرنة بما يكفي لتنفيذ عدد كبير من أفكار التصميم. من خريف عام 2017 إلى ربيع عام 2018 ، أعدنا تصميم النماذج الأولية وبحثنا عن حلول وسط لحل هذه المشكلة. ومع بعض القيود على الإعدادات ، أصدروا
إصدارًا محاصرًا من جزء العميل من BILLmanager 6 Beta في مايو 2018.
قسم المصممين UX
بينما كان قسم UX يحل المشاكل بمرونة BILLmanager ، قررت الإدارة معالجة واجهات المنتجات الأخرى للشركة وتنفيذ عمليات سكروم والتصميم في فرق أخرى. بدأنا مع VMmanager 6 ، وقمنا بتجميع فريق منتج كامل من المشاركين من الكفاءات المختلفة ، والاكتفاء الذاتي لإنشاء منتج: الواجهة الخلفية ، والواجهة الأمامية ، والمختبرين ، ومصمم UX ، ومديري المنتجات والمشاريع. أصبح من الواضح أن جميع المنتجات الأخرى سيتم تطويرها تدريجيًا من قبل نفس الفرق ، وبدأنا في الانتقال التدريجي إلى هيكل المصفوفة لإدارة تطوير المنتج.
في هذا السياق ، كان من المفترض ألا يكون قسم UX أحد فرق المنتجات. بعد إصدار الجزء الخاص بالعميل من BILLmanager 6 Beta ، أصبح معظم قسم UX جزءًا من فريق BILLmanager ويشارك الآن في حل المشكلات المعمارية والنسخة المحمولة من جزء العميل. في الوقت نفسه ، بدأنا العمل على تشكيل قسم UX يمكنه العمل مع جميع المنتجات في وقت واحد.
مصمم UX لكل فريق منتج. مركز كفاءات التصميم
لدى ISPsystem أربعة منتجات معقدة. تأكدنا من أن كل فريق لديه مصمم UX الخاص به. هذا هو الشخص المسؤول عن تصميم منتجه. تشمل مسؤولياته إعداد نماذج أولية لتخطيط العدو والتحكم في أن كل ما هو ضروري للمطورين موجود في نسخة pixelperfect. هو قائد سياسة تصميم الشركة لفريقه. تتمثل إحدى مهامه في التأكد من أن نتيجة التطوير هي منتج يتناسب مع التصميم.
لدينا أيضًا العديد من الأشخاص الذين يشكلون مركز الكفاءات التصميمية للشركة. يتضمن مصمم بصري. يشكل هذا المركز سياسة التصميم لمنتجات الشركة ويعمل على نظام التصميم. كما تقوم بتدريس مصممي UX في فرق ، وحل مشكلات التصميم الأكثر تعقيدًا ، وتعليم المطورين ، ومديري المنتجات والمشاريع كيفية العمل مع مصممي UX ، وتنفيذ عمليات التصميم في فرق Scrum.