هفت عادت داستان سرایی عالی برای مدیران محصول و طراحان تجربه کاربری- الهام گرفته شده از پیکسار

“قدرتمند ترین فرد دنیا داستان پرداز است. داستان پرداز چشم انداز، ارزش ها و برنامه های نسل جدید را تعیین می­کند.”استیو جابز

وقتی که مردم در دورهمی ها از شغل من می­پرسند خودم را یک “داستان سرا” معرفی می­کنم. این روشِ بهتری برای شروع مکالمه است تا این که خودم را یک مدیر محصول در یک شرکت نرم افزاری معرفی کنم. در حقیقت، مدیران محصول و طراحان تجربه کاربری، داستان پرداز هستند. ما دائما باید هنگام برقراری ارتباط با هرکسی داستان هایی را تعریف کنیم. ما:

• داستان هایی را به برنامه نویسان می_­­گوییم تا یک محصول شگفت انگیز را بسازند.
• داستان هایی را به بخش بازاریابی برای پخش یک پیام فریبنده در مورد چشم انداز پروژه می_­­گوییم.
• داستان هایی را به مشتریان برای جذب آنها و به دست آوردن چیز های فوق العاده می_­­گوییم.
• داستان هایی را به هیت مدیره برای توجیه صرفه اقتصادی و بازگشت سرمایه محصول می_­­گوییم. و این لیست ادامه دارد…

یک داستان پرداز خوب بودن تفاوت بین یک مدیر محصول، بازاریاب و طراح، خوب یا عالی است.

 

 

بیاید یک داستان پرداز خوب باشیم!

“اما کت (Emma Coats)” وقتی در پیکسار بود یک سری از اصول پایه داستان سرایی را توییت کرد. آنها با عنوان “قوانین داستان سرایی پیکسار” شناخته می­شوند. او درس های ارزشمندی را از بهترین داستان سرای نسل ما، یعنی پیکسار به اشتراک گذاشته است. درس های “اما” از دورانی که در پیکسار بود، الهام بخش من بود تا خودم را به عنوان یک مدیر محصول داستان پرداز معرفی کنم. در این چند دهه گذشته که تولید نرم افزار انجام می­دادم، داستان های بدون ساختار زیادی را گفتم تا یاد بگیرم یک داستان خوب را سرهم کنم. من دیدم که یک داستان خوب از طرف مدیر محصول منجر به جذب مشتریان شاد و بدون داستان تبدیل به یک ویژگی بدون استفاده می­شود.

من در اینجا “قوانین اما” را تفسیر کرده و ارائه میدهم:

هفت عادت داستان سرایی عالی برای مدیران محصول و طراحان تجربه کاربری- الهام گرفته شده از پیکسار

   

1. بدون هدف هیچ داستانی وجود ندارد

ما از تکنیک هایی مثل user stories، scenario narrations، storyboards و journey maps استفاده می­کنیم. ما تصور خوبی داریم از این که چه اتفاقی خواهد افتاد اگر کاربر با یکی از ویژگی های محصول تعامل برقرار کند. با این حال، ما اغلب تعیین میکنیم که چه چیزی باید ساخته بشود یا این که به چه شکل باید از آن استفاده کرد و هدف اساسی را نادیده می­گیریم.

پیام اصلی یک داستان چیست؟ همان طور که کلایتون کریستنسن می­گوید، “مردم نمی­خواهند یک دریل بخرند، مردم یک حفره می­خواهند.” از خودتان بپرسید، آیا من مشخصات یک دریل را تعیین میکنم؟ یا این که به مردم توضیح می­دهم چگونه یک حفره با استفاده از دریل ایجاد کنند؟ به جای این که بگوییم چرا کاربر به یک حفره در دیوار نیاز دارد؟

قبل از این که شروع به نوشتن کنیم، ما باید بدانیم برای چه می­نویسیم و هدف از این داستان چیست. به قول “اما”:

قانون #۱۴__ چرا باید این داستان را بگویید؟ ایمانی که درون شماست داستان را زنده نگه می­دارد و این قلب یک داستان است.

 

2. به من توجه کن

در یک داستان خوب، همدلی و تحسین با دیدن تلاش یک نفر در موقعیت های دشوار متولد می­شوند. بدون نشان دادن ماجراها و سختی هایی که شخصیت اصلی (کاربران نهایی) با آنها درگیر است، بینندگان (برنامه نویسان) به اندازه کافی همدردی نمی­کنند تا مشکلات آنها را حل کنند. “اما” به ما یادآوری می­کند که ما چقدر یک داستان خوب از یک شخصیت بازنده را دوست داریم:

قانون #۱__ شما شخصیت‌ها را بیشتر برای تلاش‌هایشان تحسین می کنید نه برای موفقیت‌هایشان.

 

3. یک قهرمان برای حمایت کردن

هر کسی به یک قهرمان نیاز دارد تا آنرا حمایت کند. به من یک دلیل بدهید که چرا باید به انجام شدن کار قهرمان اهمیت بدهم. چرا باید او را به خاطر موفقیت هایش تشویق کنم؟ چه اتفاقی می افتد اگر کاربر(قهرمان داستان) نتواند کار خود را با استفاده از محصول ما انجام دهد؟

شما ممکن است قالب های عالی از شخصیت کاربران و پرسونا را داشته باشید و یا حتی اسم کوچک یا رنگ چشم آنها را بدانید! اما متاسفانه این فقط یک شخصیت بازنده در یک داستان خسته کننده است. اگر موفقیت مشتری اهداف پایانی باشد، خواندن پرسونا چه اهمیتی دارد؟

 

 

چه اتفاقی خواهد افتاد اگر کاربر(قهرمان داستان) نتواند موانع را برای انجام دادن کارش از سر راه بردارد؟ آیا آنها کارشان را ازدست می­دهند؟ آیا پروژه شکست می­خورد و میلیون ها دلار ضرر خواهیم کرد؟ “اما” پا را فراتر می­گذارد و پیشنهاد می­کند که وقتی داستان کسی را می­نویسید شرایط را برعلیه او کنید.

 

قانون #۱۶__ مخاطرات شخصیت های داستان چه چیزهایی هستند؟ به ما اجازه دهید تا شخصیت را همراهی کنیم. اگر شخصیتها موفق نشوند چه اتفاق خواهد افتاد؟ اوضاع را خراب کنید.

 

4. یک خط داستانی معتبر

هر صحنه از داستان باید قابل باور باشد. همه ما داستان هایی را می­شنویم که پر شدند از مقدار زیادی چرندیات، و ما دیگر از قهرمان داستان حمایت نمی­کنیم.

اگر داستان ما اعتبارش را از دست بدهد مخاطبان ما نیز از دست می­روند– هدف کاربر چیست، اوضاع چطور است و آنها چگونه موانع را از سر راه بر می­دارند. به جای این که برنامه نویسان را مسئول ساخت ویژگی های قابل پذیرش برای کاربر کنید، آنها را تبدیل به حامیان شخصیت اصلی داستان کنید.

قانون#۱۵__ اگر شما جای شخصیت داستان بودید، در این وضعیت چه احساسی داشتید؟ صداقت شما باعث می‌شود به موقعیت های غیرقابل باور، اعتبار و حس واقعی بودن را ببخشید.

 

 

5. ساختار یک داستان تاثیر گذار

هر داستان دارای شروع، وسط و پایان است. یک داستان خوب وسط داستان را در بهترین ساختار ارائه می­دهد. مانند یک سخنرانی خوب، وقتی برای گفتن داستان محصول از تکنیک “بگو-نشون بده-بگو (Tell-Show-Tell)” استفاده می­کنید تاثیر گذاری بیشتری خواهید داشت: ابتدا به آنها درباره چیزی که در حال پیاده سازی آن هستید بگویید ، بگویید که کاربران، نیازهایشان و کاری که می­خواهند انجام دهند را فهمیده اید. در ادامه شما به آنها نمایش می­دهید که چگونه اتفاق می­افتد. و در آخر برای جمع بندی کردن، به آنها می­گویید چرا باید توجه کنند. و این که اگر کار را انجام ندهند چه اتفاقی خواهد افتاد.

“بگو-نشون بده-بگو” تکنیکی است که اغلب برای پیش فروش کردن استفاده می­شود. اما برای مدیریت محصول و طراحی تجربه کاربری نیز قابل استفاده است. برای تعمیم این متد در سطح پیکسار می­توانیم از پیشنهاد “اما” استفاده کنیم که ساختار “کن آدام” است برای ستون اصلی داستان:

قانون#۴__ روزی روزگاری یک _____ بود. هرروز، _____ . یک روز _____. در نتیجه آن _____ و در ادامه و نتیجه آن _____ . در نهایت داستان هم_____.

 

این ساختار درخشان است! برای کسی که می­خواهد محصول شما را بخرد یا از آن استفاده کند باید هزینه وضعیت فعلی بیشتر از هزینه تغییر باشد. در ساختار بالا(قانون#۴)، “هر روز” وضعیت فعلی است، “یک روز” وقتی است که تغییر ایجاد می­شود، “در نتیجه آن” اصطلاحاتی است که توضیح می­دهد افراد چه مزایایی هنگام تعویض و استفاده از محصول شما به دست می­آورند و “در نهایت” هم برای گسترش بازی است. این ساختار فوق العاده است.

 

6. خلاقیت داستان شما چیست؟

چه کسی می­خواهد یک داستان را دوبار بشنود، این بار از زبان یک فروشنده محصول دیگر؟ تفاوت شما با آنها چیست؟ ممکن است شما یک روش دیگر برای یک “پایان خوب” باشید، اما چگونه می­خواهید داستان متفاوتی را نقل کنید؟ “اما” توصیه می­کند که از دور انداختن اولین ایده نترسید حتی اگر چندین بار این اتفاق بیافتد، از ابتدا شروع کنید و تا موفقیت ادامه بدید:

قانون#۱۲__ اولین چیزی که به ذهنتان میرسد را به حساب نیاورید. دومین، سومین، چهارمین، پنجمین … را امتحان کنید. بدیهیات را دور بریزد. خودتان را غافل گیر کنید.

 

7. از پایان شروع کنید

قانون#۷__ ابتدا پایان داستان را مشخص کنید، سپس به سراغ وسط داستان بروید. پایان ها، بسیار سخت و نقطه مهم داستان هستند، شما باید مقدمه و زمینه چینی خوبی را برای آن داشته باشید.

به سختی می­توان راهی را پیدا کرد تا موفقیت پروژه را بعد از انجام شدن تمام کارها اندازه بگیریم. ویژگی ها ساخته و منتشر می­شوند… حالا چی؟ هدف شما چی بود؟ نتایج کلیدی مورد انتظار شما چیست؟ از پایان شروع کنید.

این رویکرد یک عامل ارزیابی برای ما ایجاد می­کند تا دوباره اعتبار تصمیم هایمان را بسنجیم، داستان را بازگو و طرح نهایی را تنظیم کنیم.

از عادت نوشتن داستان کاربر و لیست معیار های قابل پذیرش دوری کنید. از ساخت نسخه معرفی ویژگی ها و لیست کردن مزایای محصول دست بکشید. یک داستان خوب ارائه کنید، تا در نهایت یک تیم پرشور داشته باشید که روی محصولی کار می­کنند که مشتریان شما عاشقش هستند.

منبع : https://medium.com/galvanize/pixars-rules-of-storytelling-applied-to-product-managers-ux-designers-420cec0a18a6