لا تدافع عن التصميم بذوقك: كيف تعرض قراراتك للعميل باحتراف؟

1. ابدأ بالمشكلة

ذكّر بالبريف والجمهور والهدف قبل إظهار التصميم. هذه المقدمة تبني معيارًا مشتركًا للحكم.

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

2. اعرض الفكرة قبل التفاصيل

اشرح Concept في جملة وصورة مرجعية، ثم انتقل للتكوين واللون. لا تبدأ بالدفاع عن درجة لون قبل فهم الاتجاه.

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

3. اربط كل قرار بهدف

قل إن التباين يسرع قراءة العرض، لا إن اللون أجمل. اللغة الوظيفية تجعل الحوار قابلًا للاختبار.

جرّب تبص للمسألة من زاوية المستخدم اللي مش شايف البريف ولا يعرف كواليس المشروع. في عرض العميل، نظّم الحكاية بحيث يرى السبب قبل النتيجة ولا تترك الـMockup يتحدث وحده. عند مراجعة «اربط كل قرار بهدف»، ما تكتفيش بالسؤال هل شكلها حلو؛ اسأل ماذا تغيّر في فهم المشاهد أو سلوكه بسببها. اطلب من شخص من الجمهور المتوقع أن يشرح ما فهمه؛ تفسيره أهم من شرحك أنت للتصميم.

4. لا تعرض اختيارات بلا سبب

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

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

5. اعرض داخل السياق

استخدم Mockup واقعيًا ثم اعرض النسخة المسطحة والحجم الحقيقي. السياق يشرح الاستخدام، والنسخة المسطحة تكشف التفاصيل.

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

6. التعامل مع «كبّر اللوجو»

اسأل ما المشكلة: ضعف التعرف أم ازدحام أم ترتيب؟ قد يكون الحل مساحة أو تباينًا بدل زيادة الحجم.

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

7. الملاحظة والطلب والحل

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

جرّب تبص للمسألة من زاوية المستخدم اللي مش شايف البريف ولا يعرف كواليس المشروع. في عرض العميل، نظّم الحكاية بحيث يرى السبب قبل النتيجة ولا تترك الـMockup يتحدث وحده. عند مراجعة «الملاحظة والطلب والحل»، ما تكتفيش بالسؤال هل شكلها حلو؛ اسأل ماذا تغيّر في فهم المشاهد أو سلوكه بسببها. اطلب من شخص من الجمهور المتوقع أن يشرح ما فهمه؛ تفسيره أهم من شرحك أنت للتصميم.

8. متى تقبل التعديل؟

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

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

9. متى تقترح بديلًا؟

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

خلّينا نحوّل الفكرة لموقف عملي بدل ما تفضل كلامًا نظريًا. في عرض العميل، نظّم الحكاية بحيث يرى السبب قبل النتيجة ولا تترك الـMockup يتحدث وحده. عند مراجعة «متى تقترح بديلًا؟»، ما تكتفيش بالسؤال هل شكلها حلو؛ اسأل ماذا تغيّر في فهم المشاهد أو سلوكه بسببها. اعرض النتيجة بالحجم الحقيقي لمدة خمس ثوانٍ، وبعدها اكتب أول معلومة وصلت لك من غير تجميل للإجابة.

10. اختم بقرار وخطوة

سجّل ما تم اعتماده والتعديلات والمسؤول والموعد. الاجتماع الجيد ينتهي بمسار واضح لا بانطباعات متفرقة.

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

قائمة مراجعة عملية

قبل ما تعتبر الشغل خلص، اقفل الملف لدقائق وارجع راجعه كأنك أول مرة تشوفه. القائمة دي تمنع تفاصيل صغيرة من إنها تقلل قيمة قرار كبير:

• العرض يبدأ بالهدف
• الـConcept مكتوب في جملة
• لكل قرار سبب
• النسخة المسطحة معروضة
• الملاحظات والقرار النهائي موثقان

الخلاصة

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

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