طلب Alexey Skorik من وكالة Vinci Agency خصيصًا لمدونة Netology للشركات الناشئة وشركات التكنولوجيا التنفيذيين كيفية إنشاء فرقهم لواجهات المستخدم. ما تعلمناه من هذه المحادثة:
- الشيء الرئيسي هو المنتج ، وليس التصميم ؛
- يتيح التواصل مع المستخدمين وتحليلات المستخدم جعل الواجهة سهلة الاستخدام قدر الإمكان (لكن هذا غير دقيق) ؛
- إحدى أكثر الطرق فعالية لتقييم إجراءات المستخدم هي مهمة الاختبار ؛
- لا تنظر في واجهة المستخدم بمعزل عن واجهة المستخدم - الأول دائمًا ما يكون على أهبة الاستعداد ؛
- الذوق الشخصي في الواجهات جيد ، لكن النهج القائم على البيانات لا يزال أفضل ؛
- إن أبسط وأرخص طريقة لاختبار المنتج هي "اختبار الممرات" ، وهو في أي حال أفضل بكثير من عدم وجود أي اختبار مستخدم على الإطلاق ؛
- في أغلب الأحيان ، تهدف التكرارات الجديدة لبعض الوظائف الجاهزة إلى تبسيطها ، وليس إلى زيادة القدرات: وكل ذلك لأن المستخدم النهائي لا يريد حقًا الدخول في الواجهة ؛
- حتى إذا قمت بعرض نتائج اختبار A / B للعميل ، فقد لا يزال لديه تعليقات غير بناءة - فهي تساعد على تهدئة العمل المنهجي والحوار المستمر حول القضايا المهمة ؛
- يجب أن تساعد واجهة المستخدم المستخدم في حل مهامه في الواجهة ، والنظر في الأمر خارج هذا السياق ، هناك خطر في تحويل المعنى من الفائدة إلى الزخرفة ؛
- اسأل نفسك دائمًا: لماذا نفعل هذا؟ هل هذا يحل مشكلتنا؟ ما هي الفوائد التي ستجلبها؟
ألكساندر بيترمان ، مؤسس شبكة Notify.Network :
"لجعل واجهة المستخدم مريحة قدر الإمكان ، نستخدم التحليلات الخاصة بنا والتواصل المباشر مع المستخدمين"
لدينا فريق متكامل من مصممي التطوير لجميع المشاريع التي نشارك فيها: من الشركة الأم لصندوق الاستثمار إلى المشاريع الرئيسية التي تولد التدفق النقدي. يتيح لك ذلك استخدام الموارد بفعالية ، وتزويد المطورين دائمًا بمهام شيقة وجديدة ، والمصممين لتحسين مهاراتهم من خلال تطبيق الأساليب من مختلف الصناعات. الأهم من ذلك ، يتيح لنا النهج الذي نتبعه اجتذاب الأشخاص الأكثر موهبة من الصناعة الذين لديهم خبرة في نفس الوقت وليسوا مقيدين في تنفيذها الإبداعي. يعمل المصممون من Sberbank CIB وعدد من البنوك الأوروبية بشكل جيد للغاية هنا.
نظرًا لأن مجال النشاط الرئيسي مرتبط بالاستثمارات وسوق الشركات ، فنحن نقوم بإنشاء واجهات وأساليب أكثر طلبًا في بيئة الأعمال ، وبالتالي فإن الرموز التعبيرية والرموز الشخصية للذات ليست متعلقة بنا.
ما الخوارزمية التي نستخدمها للموافقة على المخططات؟
- بيان المشكلة.
- دراسة المراجع.
- تحليل المراجع من أجل تحديد النقاط الرئيسية للتحسين.
- تطوير المصممين عدة تخطيطات الأولية.
- اختيار اتجاه من المخططات المقدمة أو تطوير واحدة جديدة.
- تحسين الفكرة الرئيسية للتخطيط المحدد.
- تقديم للتخطيط.
بعد تطوير التصميم والتكامل ، نقوم بوضع اللمسات الأخيرة عليه في بيئة معيشية. لم يكن من الضروري أبدًا تغيير شيء ما بشكل جذري ، نظرًا لأن لدينا إستراتيجية التنمية المرحلية الصحيحة.
لجعل واجهة المستخدم مريحة قدر الإمكان ، نستخدم التحليلات الخاصة بنا والتواصل المباشر مع المستخدمين.
نحن نعتمد أيضًا على محترفين ذوي خبرة يعملون في هذه الصناعة منذ عدة سنوات ونعرف على وجه اليقين ما سيكون مفيدًا للمستخدم.
في النهاية ، أود أن أقول إنني تعلمت منذ عدة سنوات القاعدة: "إذا لم تكن هناك حاجة إلى المنتج ، فبغض النظر عن كيفية تعبئته ، فلن يكون هناك معنى". الشيء الرئيسي هو المنتج ، وليس التصميم.
سيرجي بودشيفالين ، CPO Movista :
"من المستحيل صنع المنتج المثالي على الفور ، لذا لا تخف من تطوير الخدمة مع المستخدمين"
بالنسبة إلى Movista ، إحدى خدمات تخطيط السفر ، قمنا أولاً وقبل كل شيء بفحص المنافسين المحتملين الموجودين في السوق: المباشر وغير المباشر ، المحلي والأجنبي.
ثم قاموا بتجميع الإصدار الأول من خريطة سلوك المستخدم في الخدمة وقاموا بتجميع أول نموذج أولي تم تصوره في Figma. لقد حدث ذلك لتقييم وظيفة الخدمة واختبار الفرضيات والتحضير للتجارب مع مجموعات التركيز من أجل تنفيذ المفاهيم مع وكالة تصميم مع نتائج واعية.
عند الإدخال ، تم تكوين مفهوم المنتج عن طريق التسويق الاستراتيجي لدينا على أساس أن الميزة التنافسية الرئيسية هي القدرة على إنشاء طرق متعددة الوسائط معقدة. نحتاج إلى الجمع بين العديد من النماذج السلوكية الحالية لشراء تذاكر السكك الحديدية والجوية والحافلات في واجهة واحدة ، بالإضافة إلى دمج البحث والبيع لجميع أنواع النقل في سلة واحدة.
عند اختيار التخطيطات والموافقة عليها ، تم توجيهنا من جانبين: تقييم القدرات الفنية لتنفيذ جميع الوظائف الضرورية ومجموعات التركيز التالية لتحديد نقاط القوة والضعف في التخطيطات.
الطريقة الأكثر فعالية لتقييم إجراءات المستخدم في الخدمة التي نعتبرها مهمة اختبار.
للقيام بذلك ، نطلب من المستخدم شراء مسار معين ومعرفة كيف يفعل ذلك بالضبط. نحتفل بالخطوات التي يقضيها كثيرًا من الوقت أو يبدأ في طرح الأسئلة كحظات للتحليل والتنقيح ، وتعتبر الإجراءات التي يقوم بها بسرعة ملائمة ومفهومة. ننفذ هذه التكرارات بعد إدخال التغييرات وعلى مجموعات مختلفة من المستخدمين ، مما يسمح لنا بجعل الخدمة أكثر عالمية ومفهومة.
لقد تمكنا من الابتعاد عن الفكرة النمطية للخدمة للعثور على طرق وشراء التذاكر ، حيث يحتاج المستخدمون إلى ملء نافذتين مناظرتين "حيث" و "أين". في مجموعات التركيز ، قام المستخدمون بتقييم الرسالة النصية القصيرة والموجزة "أريد الحصول على ..." وخصها كميزة مميزة من خدمات النقل الأخرى.
هناك أنواع مختلفة من السلوكيات في سوق مبيعات التذاكر: غالبًا ما يتم شراء تذاكر الطيران ذهابًا وإيابًا ، ويريد المستخدمون رؤية المسار بالكامل مرة واحدة ، بينما في قطاع السكك الحديدية ، من المعتاد شراء تذكرة أولاً ثم الأخرى. الميزات السلوكية وتنفيذ إصدار عالمي من الطرق الأولى هناك ثم العودة. نخطط الآن لتحقيق هذه الميزة ، لأنه عندما يعتاد المستخدم على شراء تذكرة لإحدى وسائل النقل ، سيكون من السهل عليه شراء تذكرة لوسيلة نقل أخرى.
الشيء الرئيسي هو عدم الخوف من التجربة ، من البداية إلى اختبار المنتج على مجموعات المستخدمين المختلفة وتحسين واجهة المستخدم.
من المستحيل عمل المنتج المثالي فورًا ، فلا تخف من تطوير الخدمة مع المستخدمين.
إيفان Ardintsev ، CPD Worki:
"في المكون المرئي ، نحن لا نثق في ذوق المذاق ، لكننا نستخدم النهج القائم على البيانات ، لذلك نحن ندير فقط إصدارات مختلفة من حلول الواجهة من خلال اختبار A / B"
نحن لا نعتبر UI بمعزل عن UX. الأول دائما يحرس الثاني. في العمل على واجهة المستخدم ، نحن لسنا مختلفين تمامًا عن معظم الزملاء: نحن نعمل على العرض التقديمي الرسومي أخيرًا ، عندما تم حل جميع المشكلات بالفعل. إذا كانت المهمة أكثر بساطة ، فإننا نقوم بإنشاء حل على الفور ، وإذا كانت صعبة ، فإننا نتحلل ونصنع نماذج أولية.
تتم جميع الأعمال الفنية على الواجهات في Sketch باستخدام نظام التحكم في إصدار Abstract. عندما تكون المخططات جاهزة ، نقوم بتوصيلها من خلال Overflow ، التي تنشئ خريطة ملائمة للوظائف. قم بتنزيل أكواد المصدر للمطورين في Zeppelin.
ترتبط واجهة المستخدم الخاصة بنا بـ UX و UX - مع الخوارزميات الذكية لتشكيل شريط من الشواغر والمرشحين. نحن نستخدم التعلم الآلي لإظهار المرشحين أنسب الوظائف الشاغرة ولموظفي التوظيف - أنسب المرشحين عند إجراء بحث بارد في قاعدة البيانات. نحقق ذلك من خلال أربعة جوانب:
الخصائص الاجتماعية والديموغرافية للمرشحين. لقد جمعنا تاريخًا كبيرًا من وجهات نظر واستجابات الشواغر من المرشحين ، والآن نستخدمها لتحسين المنتج ، مع الاستفادة من هذه البيانات. على سبيل المثال ، فتاة تبلغ من العمر ثمانية عشر عامًا ، على الأرجح ، ليست مهتمة بالوظائف الشاغرة في اللودر أو السائق ، ولكن قد يكون رجل من أربعين عامًا مهتمًا. بالإضافة إلى ذلك ، سنحصل قريبًا على "المهن المطلوبة" ، وسيكون المرشح قادرًا على الإشارة بالضبط إلى من يريد أن يعمل في المقام الأول. هذا سوف يزيد من تحسين الشريط ML. الآن نقوم بإنشاء موجز مخصص باستخدام 150 ميزة.
مصلحة فورية. إذا نظر رجل يبلغ من العمر أربعين عامًا في كثير من الأحيان إلى الوظائف الشاغرة للصراف أو يضيف إليها ، فإن خوارزمياتنا تدرك أنه مهتم بشواغر أمين الصندوق ، وليس على جميع المستغلين أو السائقين.
الغرامات. إذا لم يقم المجند بمعالجة الردود في غضون فترة زمنية معينة ، فإننا نستنتج أن الحاجة إلى المرشحين لهذا المنصب الشاغر تكون راضية ، ونخفضها في الإصدار. لذلك نشجع المجندين على الاستجابة بسرعة أكبر للمرشحين.
مجموعات العمل. هناك بالفعل شواغر هائلة ، مثل الصرافين في مطعم كنتاكي. لكي يرى المرشح تيارًا أكثر تنوعًا ، نقوم بتجميعهم في وظيفة شاغرة واحدة ، بينما نظهر في الشريط الأكثر ملائمة له.
في المكون المرئي ، لا نثق في مذاق الذوق ، لكننا نستخدم النهج القائم على البيانات ، لذلك نحن ندير فقط إصدارات مختلفة من حلول الواجهة من خلال اختبار A / B. جنبا إلى جنب مع قسم التحليلات ، نراقب بعناية المؤشرات المستهدفة لكل حل وبعد مرور بعض الوقت نتركها فعالة بقدر الإمكان.
من الصعب أن نفهم مقدما ما سيكون مناسبًا وما هو غير مناسب. في عملية العمل على واجهات ، تكون تجربة المصمم مهمة عندما يعرف بالفعل أنماط السلوك التي تكون مألوفة لدى المستخدم ، وأي منها سيؤدي بالتأكيد إلى صعوبات. هذا لا يستبعد إمكانية التجريب ، ولكن من الأفضل عدم استخدام حلول متشددة للجمهور.
الطريقة الأسهل والأرخص لاختبار نفسك هي إظهار زملائك وإجراء "اختبار الممر". معظم الأشياء غير المنطقية أو الغامضة تظهر على الفور.
أكثر تعقيدًا ومكلفة: UX تختبر المستخدمين الحقيقيين بسجل لجميع التفاعلات مع الواجهة على الكاميرا ومقابلة مصغرة لاحقة. في بدء التشغيل ، لا يتوفر هذا دائمًا على الوقت والموارد ، ولكن بالنسبة للشركات الناضجة ، قد يكون هذا هو الخيار الرئيسي ، خاصةً إذا كان لدى الخدمة جمهور كبير.
أكثر الحالات شيوعًا لإجراء التغييرات هي أن المستخدم النهائي لا يريد حقًا الدخول في الواجهة. غالبًا ما يهدف كل تكرار جديد لوظائف جاهزة إلى تبسيطها ، وليس زيادة القدرات ، رغم أن هذا مهم أيضًا.
مع كل تكرار جديد ، تحتاج إلى التدقيق بين الواجهات وتقديم العناصر الأكثر أهمية والعناصر الثانوية للدخول إلى الواجهة.
إذا كنت لا تعمل على واجهة متخصصة للغاية ، فيجب أن تأتي قاعدة "أسهل أفضل" أولاً.
يجب ألا تحاول إقناع المستخدم بوفرة من الفرص ، وتحميل كل شاشة وظيفية إلى الحد الأقصى: في أفضل الأحوال ، لن يتم استخدام معظم العروض المقدمة.
"إذا بدأت كل العمل بتكوين لغة بصرية شائعة ، فسوف يسهل هذا العمل كثيرًا في اتجاهات متعددة في وقت واحد في المستقبل وفي نفس الوقت لن يكلف شيئًا تقريبًا"
عندما تكون مسؤولاً عن منتج ما ، خاصةً عند بدء التشغيل ، فأنت تحمي القرارات داخل الفريق ، ثم أمام المستخدمين مباشرة. تستمع إلى الملاحظات ، وتتفاعل مع الأعمال ، وتعمل على تحسين الحلول. يمكنك دائمًا تحليل الأرقام الحية على الفور. ولكن في أعمال التصميم ، كل شيء أكثر تعقيدًا. يجب عليك هنا تقديم تنازلات - لإقناع العميل بأن الحل هو الأمثل ، وأن مهام العمل لها نفس أولوية تجربة المستخدم. وإذا كان استخدام UX أسهل قليلاً ، فمع كل واجهة المستخدم ، أصبح كل شيء أكثر ذاتية. حتى إذا قمت بعرض نتائج اختبار A / B ، فسيكون لدى العديد من العملاء تعليقات غير بناءة. هنا يساعد العمل الهادئ والمنتظم مع العميل - يجب أن يحضر إلى حوار بناء حول القضايا المهمة. كما أنه يساعد على وضع واعتماد مبدأ توجيهي قبل العمل - وهذه حجة قوية في النزاعات غير البناءة في المستقبل.
لفهم ما هو مناسب للمستخدم وما هو غير مناسب ، في المراحل المبكرة من التصميم ، تحتاج إلى المضي قدماً بنفسك ، واختبار كل شيء في الخدمات في مرحلة النموذج الأولي ، وتحديد ملفات تعريف المستخدمين الرئيسية وتسجيل الحالات لهم.
جميع الحالات ، بالطبع ، يجب أن تنتهي بنجاح ، ويجب أيضًا تحديد معايير النجاح ومعلماته. ستختفي معظم المشكلات مع التجربة وفهم سلوك المستخدم وستظهر أنماط تفاعلهم. كل هذا سيوفر الكثير من الوقت في المراحل الأولية في المستقبل.
تلك الأيام التي مرت فيها أكثر من عام بين الإصدارات مرت منذ فترة طويلة. كل شيء تسارع. في العالم الحالي ، تتغير أهداف العمل والمهام والبيئة بشكل أسرع بكثير من إصدار المنتج. وبالتالي فإن المنتج ليس متراصة. هذا هو النظام الذي يجب أن يتغير ويتكيف مع بيئة متغيرة من ناحية ومهام العمل من ناحية أخرى.
من المهم أيضًا وجود لغة بصرية بسيطة ومفهومة وفي الوقت نفسه لغة مرئية وتعبيرية ، حتى إذا كان ذلك ممكنًا حتى قبل بدء العمل على الشاشات. نمط ، القوافي ، والحيل ، والقيود. كل هذا يحتاج إلى وصف ، التفكير ، وصياغة وإضفاء الطابع الرسمي. يمكنك اختبار النمط على وسائط بلا اتصال وحتى على الطباعة. لن يكون هذا أمرًا ضروريًا أبدًا ، ولكن في المستقبل سوف تتخلص من مشاكل عدم التناسق بين المنتجات والتسويق والعروض التقديمية والوثائق والمواد غير المتصلة بالإنترنت والصفحات المقصودة والإعلانات.
يفتقد العديد من الأشخاص هذا لسبب ما ، ولكن إذا بدأت كل العمل بتكوين لغة بصرية شائعة ، فسوف يسهل هذا العمل كثيرًا في عدة اتجاهات مرة واحدة في المستقبل وفي الوقت نفسه لن يكلفك شيء تقريبًا. حتى لو الآن يبدو لك لا لزوم لها على الاطلاق.
نيكيتا أوشاكوف ، المؤسس المشارك ومدير التسويق في TraceAir و Alexander Smetanka ، مصمم TraceAir:
"من أجل فهم ما يراه مستخدمونا مناسبًا أو غير مريح ، عليك أن تعرفهم ، ولهذا عليك التحدث معهم كثيرًا"
نصنع برامج لإدارة البناء الفعالة باستخدام طائرات بدون طيار. على الرغم من أن هذا منتج B2B ، إلا أننا نجعله مثل B2C. على عكس العديد من الشركات التي تصنع برامج مماثلة للبناء ، فإن مهمتنا هي جعلها مفيدة للموظفين الميدانيين ، وليس فقط للمهندسين الذين هم أكثر تقنياً من الناحية الفنية ويعملون بالفعل في مختلف البرامج الهندسية المعقدة. نتيجةً لذلك ، نتخلص من نقص المعلومات الخاصة بالبنائين الذين ليس لديهم وقت للانتظار حتى يقدم لهم المساحون أحدث المعلومات حول الموقع أو يحصلون على المعلومات اللازمة في البرامج الهندسية المعقدة. لذلك ، نجعل برنامجنا بسيط للغاية. يمكن أن يتعلم الجميع تقريبًا استخدام منتجاتنا خلال نصف ساعة أو أقل.
لدينا مبيعات B2B ، ولكن من حيث استخدام المنتج ، لدينا المزيد من B2C. نحن نتجنب عدم الرضا ، من الصعب فهم واستخدام واجهات متعددة الطبقات التي هي مشتركة بين العديد من المنتجات B2B. نستمع بعناية إلى المستخدمين والأشخاص وكيفية استخدامهم للمنتج ، ونقوم بتكييف الواجهة حتى يصبح حلها أكثر ملاءمة وأسهل. لا تختلف عملية تطوير واجهة المستخدم كثيرًا عن تلك الخاصة بمنتجات B2C: فالناس وراحتهم في المقدمة.
لدينا جبهتان لجمع التعليقات - فريق داخلي وعملاء. يؤثر الفريق بأكمله على التصميم ، حيث يمكن للجميع إجراء تغييراتهم الخاصة. بعد ذلك ، نقوم باختبار النماذج الأولية على العملاء الأكثر ولاءً ، مما يساعد على إيصالها إلى إصدار العمل. تبقى الكلمة الأخيرة مع المصمم ، ومن المهم أن نفهم أن هذا مصمم للمنتج ، والقرارات دائمًا ما تكون مبررة ومتوازنة ، وتشمل إمكانية التنفيذ في الوقت المحدد مع موارد تطوير محددة.
لفهم ما يبدو مناسبًا أو غير مريح لمستخدمينا ، تحتاج إلى معرفتهم ، ولهذا تحتاج إلى التواصل معهم كثيرًا. يوفر التواصل المستمر والغمر في جوهر مهنهم فهمًا أوليًا لما هو مناسب لهم. لكن الابتكار لا يتم فقط من خلال التواصل مع المستخدمين. كما يأتي من الفريق ، والأهداف الاستراتيجية التي حددتها لنفسك ، والمبادئ التي تتبعها لتحقيق هذا الهدف. هدفنا هو بناء الأتمتة. أحد المبادئ هو جعل المنتج بسيطًا قدر الإمكان ، والذي يمكن للجميع استخدامه. التواصل الفعال مع العملاء والجمع بين أهدافنا ومبادئنا ، نقوم بصياغة فرضيات حول ما سيكون مناسبًا أو غير مريح ، ثم نقوم باختبارها.
لدينا أيضًا مدراء خدمة عملاء يتواصلون باستمرار مع العملاء ويتلقون تعليقات. إنهم يجيدون بشكل خاص اكتشاف ما لا ينجح كما يحلو لهم - يتم إخبارهم بفارغ الصبر حول هذا الموضوع. المستخدمين متحمسون لمنتجاتنا وتطويرهم ليس غير مبال بهم.
على الرغم من أننا لا نزال شركة ناشئة ، فهناك قيود على الوقت والموارد ، وغالبًا ما يتعذر حساب كل شيء ، إلا أن الأخطاء لا مفر منها. على سبيل المثال ، لا نجري اختبارات A / B واسعة النطاق للواجهات نظرًا لعدم كفاية قاعدة المستخدمين لذلك. نحن نعمل على تطوير واجهة باستخدام تعليقات مفصلة من العملاء الأكثر ولاء. هذا سريع ومريح ، لكن الاستنتاجات المستخلصة من التواصل مع مثل هذا الجمهور المحدود تتعرض لخطر عدم إعجاب العديد من المستخدمين الآخرين للمنتج. لم نواجه أية أخطاء حرجة في الواجهة من شأنها أن تمنع العمل ، ولكن كان علينا القيام بإصلاحات سريعة للواجهة. هنا مرة أخرى ، ساعدنا التواصل السريع والاستباقي من عملائنا كثيرًا.
سيرجي كيريف ، رئيس قسم التصميم AIC :
"نحن نحب واجهات جميلة ومتطورة ، ولكن إذا كان المنتج لا يعمل بشكل جيد ، فإن واجهة المستخدم لن تجبر الناس على استخدامه"
يجب أن تساعد واجهة المستخدم المستخدم في حل مهامه في الواجهة. فحصه خارج هذا السياق محفوف بتحول في المعنى من الفائدة إلى الزينة. لذلك ، بالنسبة للمنتجات الصغيرة ، يجب أن يكون ناقل التطوير في العمل مع واجهة المستخدم كما يلي: المساعدة الأولى والمشاركة ، ثم تكوين العادات وإنشاء تجربة فريدة جديدة.
كل صناعة لها خصائصها الخاصة ، وأنماط السلوك والاتجاهات الخاصة بها. ولكن هناك تصاميم عالمية تستخدم في كل مكان. إن تتبعهم وتفسيرهم وتطبيقهم بشكل صحيح هي مهمة مصمم محترف ، والوعي هو المعيار الرئيسي في العمل مع واجهة المستخدم. اسأل نفسك دائمًا: لماذا نفعل هذا؟ هل هذا يحل مشكلتنا؟ ما هي الفوائد التي ستجلبها؟
فيما يلي بعض القواعد للعمل بفعالية مع واجهة المستخدم التي حددتها بنفسي:
- اختبار المنتج باستمرار. من المهم إجراء الاختبارات الكمية والنوعية. ستساعد السيناريوهات الكمية في تحسين السيناريوهات وفهم أين تكمن المشكلة ، في حين ستساعد السيناريوهات النوعية في الوصول إلى أسفل المشكلة وتعلم الرؤى العميقة.
- التصميم هو العمل المستمر على الخلل. من المهم أن تستجيب بسرعة وتصحيح وتجربة من كل ملكة جمال ، لإصلاحها لمنع أخطاء مماثلة في المستقبل.
- تصرف بعناية. لا تطرح تصميمًا جديدًا مرة واحدة لجميع المستخدمين - يخاف الناس من كل شيء جديد وغير معروف. نحتاج إلى تحديد المقاييس الأساسية والعثور على جمهور مخلص والبدء به. اجمع التعليقات ، وفهم أين توجد الأخطاء ، وقم بالإصلاح والتحديث. تصرف بتكرار قصير.
- قم بصياغة 10 مبادئ تحدد التصميم الجيد للمنتج الذي تعمل عليه. دعهم يصبحوا دليلًا واختبارًا لقرارات فريق التصميم. يمكن أن تغطي هذه المبادئ مجموعة متنوعة من الجوانب التي تعتبرها مهمة لمنتجك أو لشركتك ، ولكن لا ينبغي أن يكون لها تفسير مزدوج أو مجردة. يمكن العثور على أمثلة على هذه المبادئ في designprinciplesftw.com .
- اجعل فريق التصميم يوثق قراراته ومراجعة التخطيطات وإنشاء مكتبات للعناصر والأنماط. يعد هذا ضروريًا لتلك المواقف التي يكون فيها خطر الحصول على عناصر واجهة تبدو مختلفة ، على الرغم من أنها تؤدي الوظيفة نفسها ، أو العكس.
من المحررين
دورات Netology لمصممي الواجهة: