تحطيم بودكاست الحلقة 9 مع ستيفاني والتر: كيف يمكنني العمل مع أطر عمل واجهة المستخدم؟

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

وتظهر الملاحظات

• موقع ستيفاني
• ستيفاني على تويتر

تحديث اسبوعي

• "كيفية إنشاء لعبة مطابقة البطاقات باستخدام Angular و RxJS" بقلم آنا برينزل
• "كيفية إنشاء موقع WordPress مقطوع الرأس على JAMstack" بقلم سارة دراسنر
• "Magic Flip Cards: حل مشكلة شائعة في الحجم" بقلم دان هاليداي
• "يسلط الضوء على Django: نماذج المستخدم والمصادقة (الجزء الأول)" بقلم فيليب كيلي
• "كيفية إنشاء خرائط باستخدام رد الفعل والنشرة" بقلم شاجية عبيدي

نسخة طبق الأصل

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

ستيفاني والتر: مرحبًا ، أنا محطمة وأحببت المقدمة.

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

ستيفاني: نعم ، إنه شيء رأيته كثيرًا ، خاصة في السنوات القليلة الماضية لأنني بدأت العمل مع وكالة والآن أعمل داخل الشركة. لذلك ، في تلك الفرق التقنية الكبيرة جدًا لتكنولوجيا المعلومات ونعم ، يوجد في الوقت الحالي الكثير من واجهات المستخدم لإطار العمل مثل تلك التي رأيتها أكثر من غيرها هي Material-UI ، في الأساس التصميم متعدد الأبعاد هو نوع من إرشادات التصميم من Google والأشياء ، والمواد -UI هو فريق من Angular ، ولكنه أيضًا فريق من React. لقد أنشأوا إطار العمل الخاص بهم باستخدام نوع من شكل وأسلوب التصميم متعدد الأبعاد من Google. لكن لا علاقة له بـ Google بعد الآن. إنه مثلهم تمامًا ، لا أعرف ، أعتقد أنهم أحبوا الشكل والمظهر. في الوقت الحالي ، هذان هما إطارا العمل الرئيسيان لواجهة المستخدم التي أعمل بها. وهناك أيضًا شيء يسمى Ant Design ، والذي نما بشكل كبير.

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

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

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

درو: هل من الممكن ، هل تعتقد أن تكون قادرًا على إنشاء واجهة مستخدم قابلة للاستخدام باستخدام إطار عمل لواجهة مستخدم جاهزة ، أم أنها ستكون دائمًا بمثابة حل وسط؟

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

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

ستيفاني: نعم ، عادة ما تقوم بالكثير من التنازلات.

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

ستيفاني: عادة. نعم.

درو: هل يتجاوز هذا التخصيص التخصيص؟

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

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

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

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

ستيفاني: نعم.

درو: هل هذا عادل؟

ستيفاني: يجب عليك ذلك. تحتاج. لذا نعم ، يمكنك عادةً الحصول على جميع المكونات التي تريدها. ما زلت بحاجة إلى معرفة ما يحتاجه المستخدمون على الصفحات ، كيف سيتنقلون؟ أنت بحاجة لبناء تدفق. لذلك عادة حتى قبل اتخاذ قرار بشأن إطار عمل ، ما نفعله هو أن نذهب إلى مستخدمينا ، ونتحدث معهم ، ونحاول فهم احتياجاتهم. لذلك أنا محظوظ في الوقت الحالي لأن المستخدمين داخل البنك. لذلك نقوم بالعديد من ورش العمل معهم وعليك أن تتخيل أنها واجهة معقدة للغاية. نحن نهاجر من شيء تم إنشاؤه ، لا أعرف ، أعتقد أنه قبل 10 أو حتى 15 عامًا إلى شيء جديد تمامًا باستخدام Material-UI React. لذا فهو تغيير كبير جدًا وعليك أن تفهم أنه خلال تلك السنوات الخمس عشرة ، يمكن لأي شخص يريد شيئًا أن يذهب إلى الدعم ثم يطلب من فريق تكنولوجيا المعلومات تنفيذه. لذا في الوقت الحالي ، تشبه واجهتي 400 صفحة بها جداول ، وداخل جداول ، وداخل جداول ، وجداول أخرى ، وأشياء لا ينبغي أن تكون موجودة حتى في الجداول.

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

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

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

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

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

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

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

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

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

ستيفاني: يجب أن تعرف من سيكونون ، وإلا فسيؤدي عمل الأشخاص التسويقيين قبل بناء المنتج. لكن نعم ، لقد أجرينا بعض اختبارات حرب العصابات على سبيل المثال ، لا يزال بإمكانك استخدام InVision على سبيل المثال. لذا يمكنك بناء بعض النماذج الأولية في InVision ومن ثم يمكنك تجنيد المستخدمين من خلال وسائل التواصل الاجتماعي ، على سبيل المثال. كنت أعمل لدى أحد المنتجات التي ساعدتني ، ما هو الاسم ، ميكانيكي وكلاء السيارات الذين يقومون بإصلاح الأشياء ومن ثم إبلاغ العميل أيضًا بالإصلاحات الإضافية ، وأشياء من هذا القبيل. لذلك كان لدينا بالفعل نوع من المجتمع المتنامي على LinkedIn و Facebook. لذا ما يمكنك فعله هو أنه يمكنك تجنيد هؤلاء الأشخاص. يمكنك إجراء اختبار عن بُعد ، مثل أننا نجري محادثة في أداة مثل أداة عبر الإنترنت. يمكنك القيام ببعض مشاركة الشاشة. لذلك فعلنا ذلك لبعض المشاريع أيضًا.

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

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

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

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

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

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

درو: إذا وجدت نفسك تعمل في مشروع لم تتم فيه هذه العملية وتم بالفعل اختيار إطار عمل لواجهة المستخدم ، فهل هناك خطر أن تبدأ واجهة المستخدم في التأثر بالمكونات الموجودة بالفعل داخل هذا الإطار بدلاً من أن تكون مدفوعة باحتياجات المستخدم؟

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

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

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

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

ستيفاني: أعتقد أن الأمر يعتمد حقًا. المشكلة على سبيل المثال مع Material-UI هي أن شكل تطبيق الويب الخاص بك وجوهره سيكونان أساسًا منتجات Google التي تمت تهيئتها. لذلك إذا لم تقم بتغيير الخط فعليًا ، وتغيير بعض الألوان ونوعًا من إحضار هوية علامتك التجارية الخاصة وفعلت ذلك ، فسيكون لديك منتج يشبه أي منتج من منتجات Google ، والذي قد يكون شيئًا جيدًا لأنه إذا اعتاد المستخدمون لديك على منتجات Google ، فقد يساعدهم ذلك في فهمها. لذلك عادة إذا لم يكن لديك مصمم في الفريق ، فهل لديك أي خيار؟ مثل الكثير من الأعمال المختلفة التي رأيتها ، فإنها تأتي مع سمات مخصصة بحيث يمكنك على الأقل تغيير الألوان. أعتقد أنه يمكنك تغيير الخطوط بسهولة تامة. ولكن مرة أخرى ، كما لو قمت بتغيير الألوان ولم تكن جيدًا في التصميم أو حتى إمكانية الوصول ، فربما تتعارض الألوان التي ستستخدمها ، وقد تواجه مشاكل في التباين.

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

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

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

درو: إذا كنت كمصمم ، يُطلب منك تغيير تصميم بعض المكونات ، فهل ستحاول فقط تغيير كل التصميم؟ هل يمكنك تخصيص كل ذلك أم أن هناك مناطق معينة ستركز عليها؟

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

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

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. هل تعرف؟

Drew: Yup.

Stephanie: It does. تمام. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.