مدونات حول التصميم

10 دروس من خبرة 10 سنوات

 10 دروس من خبرة 10 سنوات

 لمساعدة مصممي تجربة المستخدم في التأكد من أن المطورين يطورون تجربة المستخدم بالشكل الصحيح.

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

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

جلسة اختبار المستخدم مع المهندسين في موقع التبريد (الدنمارك ، 2006)

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

ورشة عمل تجربة المستخدم مع فرق التطوير في بكين ، 2013

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

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

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

1. يجب “تصميم” التفاعلات بعناية

فريق تطوير تطبيقات الويب ، الهند

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

أمضيت بالفعل ما يقرب من عام من العمل مع فريق التكنولوجيا من Brijj.com ، والتي كانت في ذلك الوقت بوابة الشبكات المهنية القائمة على المجتمع في محاولة للتنافس مع الوافد المنافس في السوق الهندية Linkedin.com

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

لقطة لنموذج أولي تفاعلي لبوابة الشبكات المهنية المذكورة أعلاه (2007)

2. منطق البرمجة هو أن المصمم يؤدي مهمة بنفس قيمة مهمة المطور  (2009)

فرق تطوير منصة المؤسسة في الهند

كتابة التعليمات البرمجية هي جزء من حل أي  لغز والذي يحدث فقط في النهاية.

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

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

3. قضاء وقت كثير (جلسات) مع المطورين في أغلب الأحيان. والأفضل من ذلك، نقل مكتب العمل الخاص بك بالقرب من مكتبهم (2010)

فريق تطوير تطبيقات المؤسسة في الولايات المتحدة

تقوم الفرق الهندسية بتحويل رؤيتك إلى شيء يستفيد منه الناس في النهاية  ويلبي احتياجاتهم، وهذا هو الهدف النهائي الذي يهمك أكثر.

لقد عشت خلال 10 سنوات جميع أنواع توزيعات الفريق. قضيت معظم سنواتي في SAS أتفاعل عن قرب مع وظائف مختلفة (تطوير ، اختبار ، نظام مطابقة بانتون ، وما إلى ذلك) ، ولا سيما أقرب إلى فريق التطوير. جعلتني هذه السنوات أدرك أن إلقاء نظرة خاطفة عدة مرات في اليوم على مكاتب أعضاء فريق التطوير والعكس صحيح يمكن أن يكون وصفة مضمونة لمنتج “يفي بمعايير تجربة المستخدم”. إن مجرد مشاهدة كيف أن “لوحة الترميز” التي يطورها مطوّري البرامج تغير نظرتك إلى منتج وظيفي يمكن أن تؤدي إلى العديد من الأفكار المختلفة حول ما يمكنك القيام به لمساعدتهم على فهم التفاصيل الدقيقة لحل التصميم الخاص بك.

4. لا تنبثق تجربة المستخدم الجيدة من كراهية الأنظمة القديمة؛ بل تنشأ من فهم دقيق للمنهجية 5W1H  (2011) ( من، ماذا، أين، متى، لماذا، كيف)

فرق متعددة الوظائف تقع في مواقع مختلفة (الولايات المتحدة وأوروبا والهند)

قد تجد أن معظم النظم القديمة قد تم “تصميمها” من قبل المهندسين الدقيقين الموقرين في مؤسستك. تعتمد صحة هذا البيان إلى حد كبير على تعريف المرء للنظام الموروث. 

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

ماذا ستفعل إذا كانت تصميماتك الجديدة تحتاج إلى إعادة كتابة النظام القديم بالكامل، والذي تم ترميزه في الأصل من قبل الرئيس التنفيذي أو أحد مؤسسي شركتك؟

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

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

5. قبل أن تدخل للتصميمات الخاصة بك في دورة التطوير ، تأكد من إجراء مراجعات صارمة مع مدير المنتج ، قائد التطوير ، قائد الاختبار ، مستخدم تمثيلي ، ربما واحد من دعم العملاء ، مدير إدارة المشروع الرشيق ، وكل ذلك في غرفة واحدة (2012)

فريق تطوير تطبيقات B2B للصناعة في الولايات المتحدة

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

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

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

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

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

جلسة مراجعة جميع أصحاب المصلحة أو جلسة مفاهيم التصميم لبرنامج ميكانيكا التبريد ، الدنمارك 2006

 

6. مواصفات التصميم لا معنى لها ما لم يتم إثباتها من خلال قصص ذات صلة وجذابة من سياق المستخدمين (2013)

فريق متعدد الوظائف في بانكوك

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

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

تطبيق مثل الملخص التفاعلي لجميع القصص ذات الصلة التي تم التقاطها خلال جلسات الاكتشاف مع محلل المخاطر في بانكوك ، 2013

7. يمكن أن تكون عروض الفيديو التوضيحية مع التعليق الصوتي والتعليقات التوضيحية السياقية وثائق تصميم مقنعة يحب معظم المطورين التعامل معها (2014)

مطوري منصة المؤسسة في بكين ، الصين

 صاغ عالم النفس ألان بايفيو نظرية الترميز المزدوج في عام 1971. باختصار ، تقترح النظرية أنه يمكن تعزيز التعرف والتعلم بشكل كبير من خلال تقديم معلومات جديدة في كل من الشكل المرئي واللفظي.

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

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

مثال على إعداد بوابة توثيق التصميم لفرق التطوير عن بُعد. يحتوي موقع البوابة على عروض فيديو تفاعلية ، وملاحظات UX ، ونماذج ، ومراجعة التعليقات في مكان واحد (بكين 2014/15)

8. لا تكره الترميز. تقبله. على الأقل كن على دراية بالإمكانيات (2015)

فرق متعددة الوظائف في المملكة العربية السعودية

غالبًا ما يكون إجراء تجارب ممتعة وذات صلة رحلة شاقة  ومليئة بالتحديات التي قد لا يكون لدى المصممين دائمًا حل مثالي لها.

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

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

كل ما يتطلبه الأمر هو بداية صادقة. لا يوجد رضا أفضل للمصمم أكثر من مشاهدة المستخدمين النهائيين وهم يستمتعون بالرضا والبهجة  بفضل الحلول المصممة بشكل لا تشوبه شائبة.

9. مهما كان حجم العمل الشاق الذي قمت به  في توثيق دقيق لحلول تصميم تجربة المستخدم كبيرا فهو ليس كافيا  (2016)

فرق تطوير مختلفة (مصر ، الهند ، المملكة العربية السعودية ، الأردن)

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

نميل إلى رفع المستوى إلى أعلى مستوى ممكن عندما يتعلق الأمر بتصميم “حلول” ذات صلة تمامًا بالمستخدمين النهائيين. غالبًا ما نعطي الأولوية لـ “المعنى” على الجدوى التكنولوجية الفورية. في أغلب الأحيان يساعدنا هذا في دفع الحدود التكنولوجية  في أي سياق معين. بينما تحاول فرق التطوير بذل قصارى جهدها في تنفيذ التصميمات ، هناك احتمال أكبر لحدوث الفجوات بسبب حقيقة أنه في مرحلة التصميم تم تعيين مستوى أعلى مما هو ممكن القيام به على الفور ، في الوقت المحدد ، ووفق الموارد والمهارات المتوفرة.

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

خطة جدول لوحة التحكم أداة مساعدة  AR

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

مكتبة قوية من الفيديو التفاعلي لتصميم تفاعلات لوحة التحكم المتعمقة ) تطبيق ( iOS لفرق التطوير والمنتج وفرق ضمان الجودة

10. أنت (بصفتك مصمم تجربة المستخدم) هو ضمان الجودة النهائي للتجارب الهادفة التي تجلبها تصميماتك (2017)

فرق تطوير مختلفة (مصر ، الهند ، المملكة العربية السعودية)

لا يمكن القول أن التفاصيل الدقيقة غير الموثقة ، والتي لم يتم قولها في كثير من الأحيان للتجربة المتصورة ، لا يمكن إجراؤها بالكامل إلا من قبل الشخص الذي صممها. من منظور الشخص غير المتخصص ، هذا هو الفرق بين الاختبار الوظيفي واختبار الخبرة.

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

إن إنجاز مهام المستخدمين ليس كافيًا. غالبًا ما يكون الهدف من إنجاز مهامهم هو خلق الرغبة في العودة لديهم. يحتاج جزء “الرغبة” في تفاعل المستخدم إلى التحقق من صحته من خلال اختبار تجريبي صارم يتخصص فيه مصممي تجربة المستخدم.

اختبار الخبرة (لأبنية التطبيقات المشتركة من قبل فريق التطوير) التي يجريها فريق UX ، المملكة العربية السعودية 2017

Design Studio

نحن نحاول باستمرار إحداث تأثير إيجابي ، وإحداث فرق إيجابي.
مختبرات الابتكار
ابتكار المنتجات
تصميم تجربة المستخدم
تصميم الخدمات
البحوث، الأفكار والرؤى
تقييم تجربة المستخدم (UX)