جلب عملية تصميم أفضل لمؤسستك

بصفتنا مصممي وباحثين لتجربة المستخدم (UX) ، فإن الشكوى الأكثر شيوعًا التي نسمعها من المستخدمين هي:

"لماذا لا يفكرون فيما أحتاجه؟"

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

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

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

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

يلخص Ugent بإيجاز مشكلة السجلات الطبية الإلكترونية:

"الأشخاص الذين صمموه [نظام EMR] لا يفهمون سير العمل الخاص بي. إذا فعلوا ذلك ، فسيصممون نظامًا مختلفًا ".

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

"لماذا لا أجد ما أحتاجه؟"

"لماذا يجعلون الأمر بهذه الصعوبة؟"

"لماذا يتعين علي إنشاء معلومات تسجيل دخول عندما أرغب ببساطة في شراء هذا المنتج. أنا أعطيهم المال. ألا يكفي ذلك؟ "

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

1. تعقيد
2. متلازمة الإصدار القادم
3. الوقت غير الكافي لتكرار التصميم
4. تسليم التحكم للبائعين الخارجيين

1. التعقيد

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

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

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

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

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

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

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

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

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

المحلول

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

عند إجراء اختبارات قابلية الاستخدام ، يجب على باحثي تجربة المستخدم اتخاذ ثلاث خطوات لإدارة التعقيد المرتبط بلوائح إدارة الغذاء والدواء:

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

2. الإصدار القادم من متلازمة

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

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

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

الحل: ارفض عقلية Fix-It-Next-Time

الحل هو معالجة مشاكل التصميم الخطيرة الآن. يبدو واضحا. ولكن كيف تقنع صانعي القرار بتغيير عقلية "الإصلاح لاحقًا"؟

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

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

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

3. الوقت غير الكافي لتكرار التصميم

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

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

الحل: تصميم المسامير

يأتي أحد الحلول من عالم الترميز. في مقالته "ملاءمة Big-Picture UX في التطوير السريع" ، يقدم Damon Dimmick فكرة ارتفاعات التصميم ، "فقاعات الوقت التي تسمح للمصممين بالتركيز على مشكلات UX المعقدة." أنها تتناسب مع إطار عمل سكروم من خلال أخذ مؤقتًا مكان العدو العادي.

تقدم مسامير التصميم العديد من المزايا:

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

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

4. الاعتماد بشدة على البائعين

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

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

أثناء العمل في هذه الشركة كمصمم UX ، واجهت هذه الديناميكية بشكل متكرر:

المدير : "مرحبًا ، إيريك ، هل يمكنك تقييم برنامج المطالبات هذا الذي نخطط لشرائه؟ نريد فقط التأكد من أنه يعمل على النحو المنشود ".

أنا : "بالتأكيد ، سأرسل لك نتائجي الأولية بنهاية الأسبوع."

المدير : "عظيم"

الأسبوع التالي:

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

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

المدير : "جيد حقًا أن أعرف. لقد أرسلت الشيك للتو. سأطلب من البائع إصلاح المشكلات قبل الشحن ".

أنا (أصرخ من الداخل): "Noooooooooooooooo!"

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

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

المحلول

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

خاتمة

في هذه المقالة ، حددنا أربعة عوائق شائعة لتصميم الجودة والحلول المقابلة:

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

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