1. الغرض: منتج عامل يستخدمه الناس

مثل هذا الهدف البسيط. سنحلل كل كلمة ، لأنها لم تصاغ بهذه الكلمات فقط.

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

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

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

على أي حال ، عد إلى الصياغة.

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

لنفترض أن المنتج لا يعمل. كل شيء واضح هنا: لن يتم استخدامها (على الأقل للغرض المقصود).

أم أنها ليست منتجًا: مجموعة من المكونات المتباينة غير المترابطة بأي علامة (يحدث هذا أيضًا).

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

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

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

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

PS روابط لأوصاف المنهجيات المدرجة في ويكيبيديا:

• Agile (Agile) - منهجية التطوير المرن
• سكروم (سكروم) - إطار لتطوير البرمجيات رشيقة (فريق العمل)
• كانبان (كانبان) - نظام تنظيم الإنتاج والإمداد ، يسمح بتنفيذ مبدأ "في الوقت المناسب"

2. دور المصمم في فريق سكروم

غالبًا ما يكون دور المصمم في فريق المنتج مبالغًا فيه لأنهم يعتقدون من حيث العمليات وتسلسل الإجراءات (الشلال) بدلاً من النتيجة.

(للتفكير بشكل صحيح من النتيجة ، حسب فئات الغرض.)

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

"نحن في انتظار التخطيطات" - إذا كان هذا يبدو ، فإن العمليات في الفريق ليست منظمة بشكل صحيح.

(للأسف ، العديد من المطورين والمصممين ليسوا على دراية بالمعايير - على الأقل W3C للويب ، وهناك الكثير من المبادئ الأساسية التي تساعد على بناء أفضل تجربة. عن طريق القياس ، هناك أوصاف / معايير لمنصات الهواتف المحمولة وأجهزة سطح المكتب الرائدة ؛ iOS ، المواد .)

انتبه إلى الشركات الناشئة - Facebook و Vkontakte و Odnoklassniki و Apple نفسها مع Microsoft: فهي تعتمد على الحلول الهندسية (Wozniak ، Gates) ، التي انضم إليها المصممون فيما بعد. قاموا بإنشاء منتجات وفقًا للغرض.

أولاً منتج منتج.

(وسيم ، من أجل العدالة ، فعل الرجال الأيديولوجيون في مختبر زيروكس ، لكن حجم العواقب مختلف تمامًا.)

•••

إذن ما هو دور المصمم؟

لإضافة قيمة .

يمكنك إضافة شيء موجود ، والانتباه.

القيمة في نظر العملاء والمستخدمين.

•••

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

•••

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

ابدأ بالكود بدلاً من التخطيطات.

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

هذا هو السبب في أن المصممين المتقدمين يهاجرون إلى نماذج أولية مع بيانات حقيقية. هل هذا جيد؟ أعتقد أن هذا أمر فائض - لماذا تبرمج نموذجًا أوليًا عندما يمكنك (ومنطقيًا) برمجة منتج على الفور؟

من الأفضل الانتقال من التطوير إلى التصميم على الفور. ابدأ بالكود - النموذج الأولي الذي يؤدي مهمة العميل بأدنى حد. نموذج أولي يمكن أن يدخل في العرض العامل (تذكر لاحقًا حول تطوير العملاء).

(يعد انفتاح ونضوج المطورين أمرًا مهمًا هنا - استعدادهم لتجربة البرنامج وتحسينه ، وربما حتى إعادة كتابة الرمز عدة مرات مرة أخرى. أنا متأكد من وجود العديد من الحلول الجاهزة لهذا لفترة طويلة.)

الوجبات الجاهزة

أدرك مهمة المستخدم.

ابدأ بالتطوير. العمل جنبًا إلى جنب مع المطور (كمدير فني وكاتب إعلانات).

تحسين منتج عمل بدلاً من التخطيطات.

فكر من حيث الأهداف والنتائج بدلاً من العمليات.

يقوم مصمم المنتج بإنشاء المنتج ، وليس التخطيطات.

3. الطريقة

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

أقترح العمل في التسلسل التالي:

1. التعرف على مهمة العميل (المستخدم) وتنفيذها كقصة مستخدم.
2. تحديد المقاييس. كيف نفهم أن مهمة المستخدم قد تم حلها؟ التزم.
3. صياغة الفرضيات. التزم.
4. خريطة رحلة العملاء.
5. نموذج أولي عامل. أفضل لاعب تطوير العملاء.
6. التخطيطات. (مع العمل الجماعي ونظام التصميم الحالي ، يمكنك الاستغناء عن التخطيطات).

مهمة العميل

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

يتم تحديد مهمة العميل إما على أساس الشكاوى ("ألم العملاء") أو احتياجات البحث.

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

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

للحصول على نظرة ثاقبة للمشكلة ، أوصي بشدة كتاب تخطيط قصة المستخدم: اكتشف القصة الكاملة ، ابني المنتج الصحيح (Jeff Patton and Peter Economy) .

نوعان من المقاييس (من المهم إصلاح كليهما!)

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

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

الفرضية - إجابة السؤال عن أسرع طريقة لحل مشكلة المستخدم

هناك دائمًا العديد من الحلول للمشكلة. في تطوير (التصميم) لا يمكن أن يقتصر على واحد! لا أحد يعرف مقدمًا أيهما سيعمل بشكل أفضل.

قم بالعمل العقلي وتوصل إلى ثلاثة حلول مختلفة على الأقل.

ضع في اعتبارك أن "تطوير" فكرة واحدة في شكل تخطيط يتغير تدريجيًا هو حل واحد وليس ثلاثة (أو عدد التخطيطات المختلفة التي تمكنت من إنشائها).

من أجل البساطة ، جرب ثلاث طرق:

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

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

خريطة رحلة العميل تغرق في السياق

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

إذا كانت المهمة هي تطوير ميزة في تطبيق موجود ، فإن CJM ينغمس في السياق ويوفر حلًا سلسًا وسلسًا للمشكلة. , , « », , .

CJM , .

« » .

. MVP. Customer Development.

. — ( MVP ), (Customer Development).

« . Lean Startup -» . .

MVP, . .

,

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

الوجبات الجاهزة

للعلم

أكبر شيء يمكنك القيام به

, / , . , .

.

, - , . , , . -. : , - , . , , , .

: , , . . , , .

, . ( ), , , , . , ( , «»; — ).

: , . , . — -: , — . -, . , , , , . ( «»), /. / , : / , , .

, .

, .

?

, / (), , , , . . , , .

, .

: ?

? ?

?

30 ? ?

? , ?

?

, ?

— , . .

, . — , : , . .

.

« », .

, . , . . , - . .

: .

? . ? .

. , — «» :-)

.

. : , , .

, , . ( ).

: , . : / .

:

1. , : , -, (// ). . ( ).
2. , , — . , : , «, » ( ), , «», . — .
3. , . , — . — /, . — , , , , . - . , — . « ».

المجموع

1. — .
2. — .
3. «» .
4. يتم إرسال كل ما يدعم فقط "رأي الخبراء" و "الخبرة" (في حلول واجهة / منتج محددة) بجرأة إلى سلة المهملات - تحتاج إلى التركيز فقط على مراقبة سلوك المستخدمين الحقيقيين.

ومكافأة أخرى

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

تنزيل ePub