خطوات تصميم واجهة تطبيق من الصفر وفق المعايير الصحيحة باستعمال تطبيق رسم الإطارات Balsamiq

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

مراحل العملية هي:

جمع المتطلّبات
تحديد الأفكار
إرسال المقترحات إلى المجموعة الأساسيّة
دمج المراجعات في الإطارات الشّبكيّة
الانتقال إلى المجموعة الأكبر
إنشاء نموذج أوّليّ عالي الدّقة /اختياري -غير مستحسن
العمل الوثيق مع المطوّرين
المساعدة في الاختبار والنّشر والتّسويق
مراقبة ردود الفعل تجاه العمل

الخطوة 1: جمع المتطلبات

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

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

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

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

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

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

الخطوة 2: تحديد الأفكار

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

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

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

الخطوة 3: إرسال المقترحات إلى المجموعة الأساسية

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

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

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

كلمة تحذير

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

الخطوة 4: دمج الردود في الإطارات الشبكية

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

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

قد نرغب في استخدام ميزة الرّموز Symbols feature للرّؤوس والتّذييلات، وقد نرغب في ربط الصفحات معًا للمساعدة في التّنقل بينها، رغم أنّ ذلك غير مطلوب عمومًا طالما أننا نفرز الإطارات الشّبكية بطريقة تعمل فيها طبيعيًّا.

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

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

الخطوة 5: الانتقال إلى المجموعة الأكبر

بمجرّد الانتهاء من التّصميم بعد بضعة أيّام من العمل عليه -أي يكون قد عُمّم ربّما إلكترونيًّا مع الفريق الأساسيّ مجدّدًا للمراجعة النّهائية-، فهذا يعني أنّه قد حان الوقت لتقديمه للجميع، حيث سيكون هذا اجتماع مبيعات أكثر منه اجتماع تبادل أفكار brainstorming meeting، وفيه نستعرض التّصميم على أصحاب العمل وكلّنا ثقة بتلبيته للمتطلّبات، ويجب تقبّل المراجعات دون توقّع الكثير منها، وبصرف النّظر عن جميع أصحاب العمل، ففي الخطوة الأولى يجب الحرص على دعوة من يتمتّع بدرجة عالية بما يكفي ليكون قادرًا على الموافقة على التّصميم، بحيث يمكن البدأ بالتّطوير - الذي عادةً ما يكون في القسم التّنفيذي أو عميلًا- وهذا هو الهدف الرّئيسي في هذا الاجتماع.

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

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

الخطوة 6: إنشاء نموذج أولي عالي الدقة

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

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

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

تستخدم بعض الشّركات الكبيرة عادةً، نماذج أوليّة عالية الدقة ليشتريها المديرون التّنفيذيّون، ففي عالم المؤسّسات لا يريد أصحاب القرار رؤية أشياء منخفضة الدّقة وذات مظهر سطحيّ، بل يريدون رؤية الشّيء الحقيقي بكلّ مجده المميّز. وهناك استخدام آخر للنّماذج الأوّلية عالية الدّقة هو خدمة اختبار الاستخدام الذاتية self-service user-testing.

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

الخطوة 7: العمل الوثيق مع المطورين

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

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

الخطوة 8: المساعدة في الاختبار والنشر والتسويق

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

الخطوة 9: مراقبة ردود الفعل تجاه العمل

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

أفكار ختامية للعملية

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

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

ترجمة -وبتصرف- للمقال An Opinionated Guide to Creating Software من موقع Balsamiq.com