تصميم المنتج بدون مصمم



لقد عملت في KORUS Consulting CIS لمدة 3 سنوات ، وخلال هذا الوقت شاركت في تصميم تسعة عشر خدمات B2B. يرتبط تصميم التفاعل عادة بـ Axure و InVision و Moqups و Framer ، (أدخل الخيار المفضل لديك) ، ولكن أدواتي هي HTML و SCSS و AngularJs. سأخبرك كيف نمت الممارسة المعتادة لحفظ قوالب HTML في التقويم الخاص بالتخطيطات الكاملة ، وكيف قامت مجموعة من الحروف المطبوعة بقيادة مدير فني بتصميم التفاعل مع واجهات جميع منتجات KORUS Consulting CIS لمدة ست سنوات.

ولماذا عملت.

في "مستشفى للأمراض العقلية في أيدي المرضى" في فصل "من أين يأتي مصممو التفاعل" ، يكتب ألان كوبر أنه من السهل العثور على المهارات اللازمة في أي مشارك في التطوير. يمكن تنفيذ التصميم من قبل مدير المشروع ، المحلل ، الكاتب التقني ، المسوق ، المطور. من الجيد أن يتولى هذه الوظيفة أخصائي منفصل ، ويفضل أن يكون مصممًا. أعطت KORUS هذا الدور للمبرمجين. لكن ليس في الحال.

فوتوشوب مرفوض


حتى عام 2019 ، لم يكن هناك مصممين في KORUS. وحتى عام 2011 ، لم يكن هناك أحد يسمع عن شيء مثل تجربة المستخدم. بصفتها مطور برامج يحترم نفسه ، سعت الشركة إلى طرح المنتج بسرعة في السوق ، وكان المحللون والمطورون مسؤولين عن مظهر وسلوك الواجهة. معظمهم من المطورين.

لذلك ، عندما ظهر في عام 2011 مبرمج بمهارات مصمم في الشركة ، قبل التطوير ، لم يُسمح به إلا في المراحل النهائية.

واجه (جديد - غير عادي) لمتخصص KORUS مخطط تطوير نموذجي ، حيث سُمح له بتحريك وحدات البكسل والطلاء ، عندما تم تنفيذ الميزات الرئيسية بالفعل. يبدو التصميم بعد التطوير. وهذا موضح بالتفصيل في مستشفى الطب النفسي ، السيد كوبر. يمكن اعتبار KORUS بطلاً في الكتاب المدرسي لقصصه.

دخل Photoshop أو محرر رسومات آخر في عملية التطوير هذه بصعوبة. منذ البداية ، اعتمدنا بشكل أكبر على التخطيط لأنه أسهل في التعديل ، خاصة في مواجهة المتطلبات المتغيرة باستمرار. ويمكنك إعطاء التصميم للمطور. يعد تصميم الجمال وتنضيده وإلهامه في نفس الوقت أكثر كفاءة. باستخدام هذا النهج ، يعد الرسم في أي محرر رابطًا وسيطًا غير ضروري ، وربما يوافق الكثيرون على ذلك في عام 2011.

ساعد رفض أدوات التصميم على وضع مسار جديد فوق المخطط الراسخ والبدء في طريق طويل إلى التصميم الصحيح للواجهات. عندما يكون وقت التطوير محدودًا ، يصبح تخطيط PSD مجرد توصية ، ويكون التخطيط أشبه بمجموعة من القواعد ، فمن الصعب الاستدارة ونسيان الحالة غير المرئية. أو فكر في ذلك ، بناءً على أفكارك الخاصة حول الراحة.

يسمح لك التخطيط أيضًا بحفظ المكونات الفردية حتى لا تضيع الوقت عليها في المرة القادمة ، وتظهر أدناه صفحة HTML الأولى مع هذه المكونات:



أصبحت أول لبنة لمستودع المجموعة المستقبلية على AngularJs. في البداية ، تمت إضافة النماذج المطبوعة والصفحات الفردية لخدمة إدارة المستندات الإلكترونية (المشار إليها فيما يلي باسم البريد السريع).

عندما نما المستودع ، وكان هناك المزيد من التخطيطات فيه ، كان يطلق عليه UIKIT و kitten-ninja على الشعار:



في عام 2015 ، بذلت شركتنا كل جهودها في التفاعل مع Sberbank ، وثار السؤال عن إعادة طلاء الخدمة. استخدمت KORUS مرارًا وتكرارًا حقيقة أن هناك بالفعل إنجازات في المكونات والأنماط: يكفي تغيير الألوان لتتناسب مع نمط الشركة من Beeline ، Alfa Bank ، إلخ. وبفضل هذه التجربة ، تم إعادة طلاء Courier في غضون ساعة واحدة فقط.



وتخيل ، إذا قام المصمم في البداية بإعادة رسم التخطيطات الرسومية ، ثم قام مصمم التخطيط بتغيير الأنماط؟ مهمتان - حل واحد: تخطيط بالفعل في UIKIT.

كيف تمنعهم من فعل "سيئ"؟


والمثير للدهشة ، خلال السنوات الأربع الأولى ، تعامل متخصص واحد فقط مع جميع مهام التصميم. تم حفظ التطورات في UIKIT ، وهذا توفير كبير للوقت: تمكن المصمم من الاتصال بالتطوير في أقرب وقت ممكن ومنع حلول الواجهة الرهيبة.

أدى التوسع في مجموعة المنتجات بشكل طبيعي إلى ظهور مصممي تخطيط جديدين. هذا سمح للنينجا الحيتان بتخصيص المزيد من الموارد ، وأصبحت التخطيطات أكثر تفاعلية. لا يكفي ربط روابط HTML مع بعضها البعض ، فقد أردنا المزيد. تم استخدام JQuery و AngularJs. تم تقييم النماذج الحية الحية في المقام الأول من قبل المحللين. يمكنك النقر على جميع الولايات ، والتقاط لقطات شاشة ولصقها في المعارف التقليدية.
"لقد قمنا بشيء مماثل لـ BEM ، ولكن ليس BEM ، وبالتالي ذهبنا إلى توحيد التخطيط في جميع المشاريع"
ومع ذلك ، إذا كان كل شيء واضحًا مع مصمم التخطيط ، فهل يمكن فقط أن يسترشد مصمم التخطيط بالإرشادات وتجربته الغنية في تنضيد التنسيقات المختلفة لتصميم شيء بسيط؟ يستطيع مصممو التخطيط تجميع الواجهة كمصمم ، ولا ينتظرون شخصًا يخبرك بمكان وضع الزر. لقد رأوا هذا الزر بالفعل في شريط الأدوات عدة مرات. يطلق المصممون هذا الغموض. وكانت KORUS بحاجة إلى حالات حياة مفهومة ، والتي تسمى "التصميم الطبيعي". وإذا كنت تتذكر أن منتجات نظام بيئي واحد عادة ما تكون متشابهة مع بعضها البعض ، وأن التفرد يؤذيها فقط ، فإن إجابتي هي نعم.

أدى ظهور UIKIT إلى تسريع عملية وضع النماذج. تم استخدام عرض تخطيط قابل للنقر للبيع المسبق ، وتنسيق التفاصيل مع العميل قبل بدء المشروع. وأخيرًا ، تلقى المطورون المدخلات اللازمة حول سلوك الواجهة ، حتى لا يأتوا بأنفسهم مباشرة في عملية الترميز.
"لقد سهلت الجبهات عليهم. جعلتني UIKIT جزئياً أقوم بذلك بشكل صحيح ".

التفاعل مع AngularJs


لقد كان مخطط العمل هذا بالضبط الذي جاء إلى KORUS بعد ظهور UIKIT: ظهرت الحاجة ، تم إضفاء الطابع الرسمي عليه في المتطلبات الفنية ، قام مصممو التخطيط بتجسيده على الفور في نموذج أولي على الويب.
بقيت للحصول على بعض الإطار من أعماق الإنترنت ، وإعادة رسمها تحت تسمية خضراء وتنفيذها في المنتجات لجعل ليس فقط الأزرار والرؤوس موحدة لجميع الخدمات.



بالإضافة إلى عناصر التحكم في الإطار ، تم تجديد UIKIT بمجموعة من الرموز والأدوات والتطورات والأنماط الخاصة.

إذا كانت هناك مهمة لتصميم صفحة مشابه لشيء ما من خدماتنا ، فقد أخذنا التصميم النهائي ، وقمنا بتغيير المحتوى إلى المتطلبات ، وظل الغلاف والمنطق كما هو. يمكن تكوين الانتقالات بين الصفحات ، وجميع الأزرار والحقول قابلة للنقر ، ويمكننا إظهار التحقق من الصحة والنوافذ المشروطة ونجاح تحميل الملف. يمكننا عرض مسار المستخدم بالكامل من البداية إلى النهاية مع السيناريوهات الإيجابية والسلبية ، في تمثيل نموذج القدوة بأكمله.

واجهات موحدة


إن إعادة استخدام الأجزاء المصممة مسبقًا من الواجهة ليست جديدة لعام 2015. حتى قبل عشر سنوات ، قام مصممو التخطيط في استوديوهات الويب بتحسين عملياتهم حتى لا يعادوا ضبط نفس العنصر في كل مرة. لم نكتشف المجرة ، لكن هذه كانت البداية فقط.

من الواضح أنه كلما أضفنا تنسيقات إلى UIKIT ، كلما قمنا بتغطية الحالات الحالية ويمكننا تطبيقها بشكل أكبر على المشاريع الجديدة.

هل تحتاج إلى تنسيق تسجيل مستخدم جديد؟ لدينا بالفعل هذا: لقد قمنا بتكييفه وفقًا لاحتياجات العمل ، ولا نقضي أكثر من بضع ساعات عليه ، والآن - التسجيل جاهز للنقل إلى المطورين ، ولكن في خدمة مختلفة.

هل تحتاج إلى جدول ببيانات الشركة؟ هذا الخير في خدماتنا بالجملة: CRTL + C CTRL + V.

الأكثر جاذبية لفريق التخطيط في هذا هو الأنماط الموحدة. المبادئ التوجيهية هي شيء يملي علينا ما يجب أن تبدو عليه العناصر الذرية للواجهة. يبدو من المعقول إصلاح نمط هذه المكونات وتغييرها فقط كملاذ أخير. بغض النظر عن عدد تخطيطات المنتجات الجديدة التي نقدمها في UIKIT ، فإن الأنماط في المكونات موجودة في مكان واحد. لاحتياجات المشروع نفسه ، هناك css منتج منفصل يمكنك فيه تخصيص شيء ما.

تحت تأثير المبادئ التوجيهية والتحسين وتجربتنا الخاصة ، كان لدينا دائمًا:

  • المدخلات والأزرار والقوائم المنسدلة.
  • الجداول ، والجانبين ، والقوائم ، وأشرطة الأدوات ؛
  • النماذج والجداول الزمنية والنوافذ المشروطة ؛
  • التدفق الكامل لمعالجة نوع من طلب القرض أو إنشاء مستند دفع.

من كل هذا ، كان من الممكن بالفعل تجميع واجهات كاملة ، وبفضل AngularJs ، على التخطيطات ، تم تحقيق تفاعل الإنتاج ، والذي كان شائعًا جدًا لدى العملاء.

في الخفاء ، سأقول أننا قدمنا ​​عرضًا توضيحيًا للعميل عدة مرات في UIKIT ، لأنه كان لدينا منصة اختبار تقع قبل العرض التوضيحي.

دارة العمل


مر الوقت ، أصبح الملهم الإيديولوجي ومبدع UIKIT مديرًا فنيًا ، وكان هناك المزيد والمزيد من المشاريع. من سيواصل هذا العمل الرائع - تصميم واجهات HTML باستخدام وظائف مطورة بالفعل؟ مصممي التخطيط ، بالطبع.

القول بأن مصممي التخطيط كانوا سعداء للغاية بشأن احتمال العمل عن كثب مع المحللين والتفكير المستقل من خلال سهولة الاستخدام هو خدعة صغيرة. ومع ذلك ، اعتاد الجميع (أنا؟) على حقيقة أن مصمم التخطيط هو متخصص يتلقى تخطيطًا من مصمم ، ويقطعه ويحوله إلى صفحة ويب. يضيف التصميم التفاعلي في أماكن العمل الميكانيكي مسؤولية غير عادية ، لم يتم دراستها بعد. لكن ساعدنا وجود شخص قام بمراجعة عملنا باستمرار ، واقترح كيفية القيام بذلك بشكل صحيح. ولم يطالب فقط ، بل أشار إلى مصادر موثوقة ، حتى نقرأها أيضًا ونرتكب أخطاء أقل. أشار المدير الفني باستمرار إلى بعض قوانين Fitts ، ثم إلى قواعد كتابة الأعمال ، ثم إلى تنسيق النص ، مع التأكيد على العناصر ... لقد قاومنا ، ولكننا استوعبنا المعلومات.

اليوم يمكننا وضع زرين أخضر جنبًا إلى جنب - غدًا لم نفعل ذلك لأننا علمنا: يجب أن يكون الزر مع الإجراء الهدف واحدًا لكل صفحة.

اليوم ، تم تعليق جميع الإدخالات بنفس العرض ، وغدًا سنجعل الحقل لرقم التعريف الضريبي للمحتوى بالضبط. لذلك يقرأ المستخدم بشكل أفضل المدة المتوقعة للبيانات منه.

بدأت العملية في التدفق. يقوم مصممو Layout بتجميع الواجهات ، بالاعتماد على متطلبات العمل من المحللين ، وتنسيق قرارهم مع المدير الفني ، ومنحهم التطوير.

لقد نشأنا كمصممين ، وتعلمنا اتخاذ القرارات ، ورعينا بأنفسنا الاستقلال لتوسيع نطاق المهام التي لا يتطلب فيها الانغماس العميق للمدير الفني.

في مكان ما في خط الأنابيب هذا ظهر GitLab ، مراجعة للتخطيط ، تحسين التصور باستخدام js.

إذا واجه مصمم التصميم مهمة صعبة وغير قياسية ، فقد اتصل المخرج الفني وساعد في التوصل إلى حل. في ذلك الوقت صمم هو نفسه مفهوم المنتجات الجديدة.
قدمنا ​​2-3 خيارات لفهمنا للمشكلة ، واختار أحد الخيارات وقال كيف يمكن تحسينها. من حين لآخر ، قال ببساطة "حسنًا" ، وكنا سعداء بفهم أننا وصلنا إلى العلامة. ومع ذلك ، في بعض الأحيان لم يكن لدينا ما يكفي من التعليقات لفهم كيف أن الحل الذي نقدمه مناسب ومفهوم للمستخدمين ، وحتى ما إذا كان واضحًا للمدير الفني. جعلنا الشك نحاول مرارًا وتكرارًا تفسير المتطلبات بعدة طرق.

كان لقائدنا رأيه الخاص في هذا الشأن. قال أن بهذه الطريقة جعلنا نفكر. كل بطريقته الخاصة تقييم العملية. ظننت أنني أنقذ نفسي ووقته. مثل ، دعني أريك ثلاثة خيارات في وقت واحد حتى لا أمشي ثلاث مرات. نوع من اختبار A / B / C على المدفعية بالنسبة لي.

على الرغم من أننا تعلمنا بالطبع الكثير (فقط انظر كيف يقتبس مصمم التصميم هذا كتب التصميم).



كما تفهم ، في هذه العملية لا يوجد مكان للتفكير التفصيلي حول تحليلات UX و UX. على الرغم من أن هذه الأداة مع اختبار واختبار. تم استخدام ما وضعه المدير الفني في الأصل في التخطيط في مرحلة النماذج الأولية. لقد تم بالفعل اختراع جميع الميزات الجديدة ووصفها من قبل أصحاب المصلحة والمديرين والمحللين. لا المبرمجين. كان هذا ناقصًا ، لأننا لم نتمكن دائمًا من شرح قاطع بشكل قاطع لماذا الحل الذي اخترعته الشركة بالفعل غير مناسب.

عند الإخراج ، تلقت آلة الطباعة بعض الوصف في Confluence من المحلل - مثل هذا:
:
:
: « »
« » checkbox .
tooltip .
تم تطبيق خريطة غير شخصية في المربعات في البازيليكا حتى على المهمة لإظهار موضع العناصر والغرض منها على الصفحة.

في بعض الأحيان تلقينا مهامًا من محللين بالصياغة التالية: على



الرغم من أن UIKIT دخلت مجموعة أدوات الشركة ، فبدون تحليلات UX ، لم تكن هناك حجج قوية ضد اتخاذ أي قرارات للواجهة ، باستثناء الكلمة الأخيرة للمدير الفني. لكن طريقنا إلى التفاعل المثالي استمر.

بمرور الوقت ، تمكنا من العثور على لغة مشتركة وتقسيم مجالات المسؤولية عن جودة الواجهة وسهولة استخدامها.

في المجموع ، بدت العملية الكاملة لإنشاء تخطيط المنتج كما يلي:

  1. - , UIKIT. , , , ;
  2. , . , -, , . ;
  3. أخذ مصمم التصميم حدود المشروع الجديد واستكمله ، وأخضعه لمهمة تقنية أكثر تفصيلاً. إذا أراد العميل في البداية ملء الطلب بخطوة واحدة ، ثم في خطوتين ، قام مصمم التخطيط بتنفيذ ذلك بسهولة. في المستقبل ، يمكن أن يتغير التخطيط بشكل لا يمكن التعرف عليه ، ومن الإصدار الأصلي لم يكن هناك سوى أنماط لم تتغير من حيث المبدأ. كل هذا يتم تدريجيًا مناقشته مع المدير الفني. في المرحلة الأولى ، تم تخصيص النموذج الأولي من يومين إلى أسبوعين ، ثم يمكن أن يستمر التطوير لسنوات. في مثل هذه المشاريع ، "تسابق" مديرنا أحيانًا بإعادة تصميم من أجل التعويض عن الكتلة الحرجة المتزايدة للميزات وإعادة التفكير في الواجهة بطريقة جديدة.

لقد استغرق فريق UIKIT عامين للوصول إلى هذه العملية.

مظاهرة بصرية


في جميع المراحل ، يكون التخطيط متاحًا للعرض على العميل والفريق. هذه واحدة من أقوى مزايا UIKIT.

ما الذي يمكن أن يكون أكثر ملاءمة ومفهومة للعميل من اتباع الرابط والنقر على التصميم بنفسك ، وإلقاء نظرة على سلوك الواجهة؟ يمكنه تقييم وتصحيح النصوص ، والتي تذهب بعد ذلك إلى الإنتاج. في بعض الأحيان ، غيّر التخطيط الذي وضعه العميل فكرة المهمة ، وكان بإمكانه أن يفهم أن فكرته لم تكن قابلة للتطبيق وتوافق على التغييرات. إذا كان على يقين بالكلمات من أن استبيانه الذي يحتوي على 150 حقلاً سوف يتناسب بسهولة مع الواجهة ، ثم في التخطيط رأى بوضوح أنه يتطلب تحسينات. الأهم من ذلك ، رمي هذا الملف الشخصي في UIKIT رخيص.

مثال صغير:

الشرط الأول غير القابل للجدل والنهائي:



التسوية التي شوهدت في العملية:



قد يلاحظ شخص ما أن Axure ، Figma ، Marvel لديها جميع مزايا UIKIT التي وصفتها ... ولكن بعضها لم يكن موجودًا في مرحلة اختيار التكنولوجيا ، وتم رفض البعض الآخر كحلقة وصل إضافية بين التصميم والتخطيط.
UIKIT هي فرصة لتجميع ليس حتى نموذج أولي ، ولكن واجهة منتج جاهزة ، والتي ستبدأ عندها الواجهة الأمامية في العمل.

اعتراف الشركة


بحلول عام 2020 ، كان لدى UIKIT 38 نموذجًا من المشاريع القائمة ، منها 13 قيد التطوير. هذه تجربة واسعة لمدة أربع سنوات ، حيث يمكنك العثور على ألف حل من المتخصصين المختلفين ، من المخرج الفني إلى المختبر. كلهم يطيعون القواعد العامة لـ css وبناء الصفحة.

بمرور الوقت ، احتجنا إلى توصيل مكونات إضافية جديدة ، وتنظيم العديد من المدرجات لـ UIKIT (لدينا الداخلية للتطوير الحالي والخارجي للنسخة الثابتة ، التي سيتم تطويرها) ، وإضافة إصدارات الأنماط ، وبدء استيراد حزمة الأنماط إلى المصنّع والربط ، ثم تسهيل حزمة npm نقل ملفات الوسائط إلى CDN. ثم انتقلنا إلى SASS. تحولت مجموعة الموقع التي تبدو عادية من التخطيطات إلى مشروع كامل مع عمليات النشر والتحديثات من الفريق ومناقشة نشطة للتحسينات المستقبلية. أي أن مشروعنا ، الذي كان في البداية مجرد مساعدة للنماذج الأولية السريعة ، تحول إلى منتج كامل مع عملياته المتأصلة.

كان UIKIT محبوبًا من قبل العملاء والمحللين والمطورين ، ثم قدر المختبرون ذلك أيضًا.

في أحد الأيام الجميلة ، تلقيت سؤالًا تاريخيًا فقط من فريق تطوير عملائنا:
"متى ستكون مخططات الحوت؟ إنهم أكثر ملاءمة من المتطلبات ".
بالنسبة لي ، كمصمم تخطيط ، هذه العبارة تملق. ولكن من الأفضل عدم القيام بذلك ، اقرأ المتطلبات.

حتى هذه اللحظة الهامة ، ذهب فريق UIKIT بعناد إلى التعرف على الأداة حتى بين الزملاء. كانت القيمة التجارية للمشروع صفرًا ، مما يعني أن تطويره يقع بالكامل على الآلة الكاتبة. بالإضافة إلى المهام الحالية ، استمروا في تحسين عملهم. أحب أن أرى مدى نمو مجموعة النينجا لدينا على مر السنين ، وليس أقل قوة في الشكل الحديث ، ولكن بفضل التصميم النهائي ، وتجاوزه.

ستتمحور قصتي التالية حول التفاصيل التقنية للتصميم باستخدام UIKIT ، حول الكيفية التي تجاوزت بها دائرتنا نفسها ، والخطوات التي اتخذناها للتطوير.

Source: https://habr.com/ru/post/undefined/


All Articles