منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · ترجمه: ۶ شهریور ۱۴۰۵ · زمان مطالعه: حدود ۱۴ دقیقه

داستان کاربر (User Story) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

یک جملهٔ پانزده‌کلمه‌ای روی یک برگهٔ چسبان، می‌تواند کار یک سند نیازمندی صدصفحه‌ای را بکند. داستان کاربر همین جمله است.

تعریف

داستان کاربر یک گزارهٔ کوتاه دربارهٔ یک قابلیت است، نوشته‌شده از زبان کاربر.

نکتهٔ اصلی در چیزی است که این گزاره نمی‌گوید. داستان خوب، خودِ قابلیت را تعیین نمی‌کند.

داستان می‌گوید کاربر می‌خواهد به چه چیزی برسد. انتخاب بهترین راه پیاده‌سازی به تیم واگذار می‌شود.

قالب رایجش سه‌بخشی است: «به‌عنوان یک ‹نقش›، می‌خواهم ‹کنش›، تا اینکه ‹نتیجه›».

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

داستان کاربر در تیم‌های توسعهٔ چابک ابزار برنامه‌ریزی است. هر داستان باید آن‌قدر کوچک باشد که در یک اسپرینت جا شود.

حالت آرمانی‌اش این است که تیم داستان‌ها را با ذی‌نفعان و پژوهشگران کاربر با هم بنویسد. داستانی که یک نفر تنها در اتاق خودش نوشته باشد، فقط ذهن همان یک نفر را منتقل می‌کند.

خاستگاهش هم روشن است. در دههٔ ۱۹۹۰ توسعهٔ نرم‌افزار از دوره‌های طولانی برنامه‌ریزی فاصله گرفت و داستان کاربر بخشی از همین حرکت بود.

سه جای خالی: کاربر، کنش، دلیل

داستان سه جای خالی دارد. هر سه باید پر شوند.

• - ۱. کاربر (نقش): چه کسی. باید یک نوع مشخص از کاربر باشد، نه «مشتری». «به‌عنوان یک خریدارِ بازگشته» بهتر از «به‌عنوان یک کاربر» است.
• - ۲. کنش: چه کاری. یک کار معنادار و واحد، نه یک بستهٔ کامل از کارها.
• - ۳. دلیل (نتیجه): چرا آن کار مهم است. همین بخش تضمین می‌کند قابلیت هدف روشنی دارد.

یک مثال ساده برای اپ رستوران‌یابی: «به‌عنوان مشتری رستوران، می‌خواهم زود رستوران خوب پیدا کنم، تا اینکه سریع غذای خوب بخورم».

در این جمله هیچ قابلیتی نام برده نشده است. قابلیت‌ها بعداً می‌آیند، وقتی تیم از داستان به سمت راه‌حل حرکت می‌کند.

برای همین یک داستان، چند راه‌حل ممکن است: ذخیرهٔ رستوران‌های محبوب، مرتب‌سازی بر اساس مکان یا زمان تحویل، و نمایش پیشنهاد دوستان.

گاهی داستان از زبان کاربر نهایی نوشته نمی‌شود. تیم‌ها می‌توانند آن را از دید ذی‌نفع کسب‌وکار، شریک تجاری یا حتی کارمند خودشان بنویسند.

نوشتن داستانِ خوب سخت‌تر از آن است که به نظر می‌رسد. اینجا جای پژوهش کیفی است.

مشاهده، مصاحبهٔ در بافت و روش‌های مردم‌نگارانه، مادهٔ خام داستان را می‌سازند. بستهٔ پژوهشی هم کار می‌کند: از کاربر بخواهید روز خودش را مستند کند.

بعد تیم با هم مرتبط‌ترین یافته‌ها را برای مسئلهٔ طراحی انتخاب می‌کند و آن‌ها را در چند داستان منسجم جمع می‌کند.

نتیجهٔ سنجش‌پذیر و معیار پذیرش

بهترین داستان‌ها به نتیجهٔ سنجش‌پذیر می‌رسند.

نمونه‌اش افزایش چند درصدی نرخ تکمیل پروفایل، یا افت خطاها در مسیر پرداخت است.

نتیجه‌ای که به هدف کاربر یا هدف کسب‌وکار گره خورده باشد، تیم را از تولید انبوه قابلیت آزاد می‌کند. تیم به‌جای بیرون‌دادن قابلیت برای بیرون‌دادن چیزی، دنبال حل مسئله می‌رود.

داستان کاربر عمداً دربارهٔ قابلیت مبهم است. پس تیم وقتی کار را شروع می‌کند، همیشه دامنهٔ کامل کار را نمی‌داند.

پاسخ این ابهام، معیار پذیرش است: شرط‌هایی که قابلیت باید برآورده کند تا «انجام‌شده» شمرده شود.

مدیر محصول، طراح و پژوهشگر معمولاً این معیارها را کنار داستان می‌نویسند تا همه بر سر یک برداشت از آن جمله بمانند.

اپیک، و اندازهٔ درست یک داستان

داستان‌ها معمولاً روی برگه‌های چسبان نوشته می‌شوند. تعدادشان اول کار زیاد به نظر می‌رسد. با این حال از یک سند نیازمندی بی‌پایان قابل‌مدیریت‌تر است.

یک سطح بالاتر از داستان، اپیک است. اپیک نمایی کلی از قابلیت‌های لازم می‌دهد و مجموعه‌ای از داستان‌ها را در خود جمع می‌کند.

اگر با نمودار خویشاوندی کار کرده‌اید، اپیک همان نامی است که روی یک دستهٔ داستان می‌گذارید. برای اولویت‌بندی ویژگی‌ها هم واحد مفیدتری از داستان تک‌تک است.

اپیک به همه اجازه می‌دهد طرح را از زاویهٔ کاربران مختلف ببینند. آن‌قدر کامل که اگر کاربری بخواهد کاری بکند که پیش‌بینی نشده، همان‌جا گره‌اش بیرون بزند.

داستان در مقابل باید مشخص باشد. آن‌قدر مشخص که تیم بتواند برشش دارد و در یک اسپرینت رویش کار کند.

پیش از آن هم تیم باید به جزئیات برسد و مسائل کاربردپذیری را همان اول حل کند. طراح رابط باید بخشی از همان تیم باشد تا داستان به چیزی واقعی و قابل‌استفاده تبدیل شود.

زبان سادهٔ داستان به همه کمک می‌کند بفهمند در هر اسپرینت چه چیزی ساخته می‌شود. همهٔ ذی‌نفعان می‌توانند ببینند نگرانی خودشان کجا پاسخ گرفته است.

سطح جزئیاتش هم درست است. برای همین وقتی پروژه به سمت تورم قابلیت می‌رود، زود معلوم می‌شود.

داستان کاربر در برابر مورد کاربرد

مورد کاربرد (Use Case) شکل قدیمی‌ترِ همین ایده است و بخشی از همان فرایندهای طولانی بود.

مورد کاربرد گام‌به‌گام تعامل کاربر و سامانه را می‌نویسد، به‌همراه مسیرهای جایگزین و رفتار در خطا.

مورد کاربردِ پرداخت، گام‌هایی مثل ورود اطلاعات کارت، اعتبارسنجی کارت و تأیید نهایی خرید را فهرست می‌کند.

داستان کاربر در مقابل کوتاه است و به زبان ساده فقط هدف و دلیل را می‌گوید.

تفاوت مهم‌تر، تفاوت دستور زبان است. مورد کاربرد گرامر و ساختار مشخصی دارد، پس همه در نوشتنش شرکت نمی‌کنند. معمولاً فقط کسی می‌نویسدش که مسئول تعریف نیازمندی‌ها است.

داستان کاربر این سد را برمی‌دارد. هر کسی در تیم می‌تواند سراغش برود، چون فقط باید معنای آن سه جای خالی را بفهمد. منحنی یادگیری‌اش کوتاه است.

اگر رویکردتان طراحی مشارکتی است، حتی می‌توانید خود کاربران را در نوشتن داستان شریک کنید.

داستان کاربر در بسیاری از موقعیت‌ها جای مورد کاربرد را گرفت. الهامش را هم از همان می‌گیرد. وقتی به شرح دقیق‌تری نیاز دارید، تیم‌ها از داستان شروع می‌کنند و آن را به مورد کاربرد گسترش می‌دهند.

این همان نقطه‌ای است که نیازمندی‌های کارکردی از داستان بیرون می‌آید.

داستان پرسونا: وقتی «به‌عنوان یک کاربر» هیچ نمی‌گوید

داستان کاربر روی برچسبِ سادهٔ نقش می‌نشیند. برچسب نقش، اطلاعات کمی دارد.

وقتی داستان با «به‌عنوان یک کاربر» شروع می‌شود، هیچ چیزی دربارهٔ آن آدم نمی‌دانید. نمی‌دانید چه چیزی برایش مهم است و چه چیزی رفتارش را شکل می‌دهد.

نتیجه‌اش این است که طراحی بر پایهٔ نیاز واقعی سخت‌تر می‌شود. فهم اینکه آن آدم راه‌حل شما را چطور تجربه می‌کند هم سخت‌تر می‌شود.

داستان پرسونا راه روشن‌تری می‌دهد. به‌جای یک نقش بی‌نام، از زبان یک پرسونای مشخص می‌نویسید، با هدف و انگیزه و بافت واقعی.

این کار به شما اجازه می‌دهد وارد جهان کاربر شوید. نه‌فقط بفهمید چه می‌خواهد، بلکه بفهمید چرا می‌خواهد.

با همین روشنی می‌توانید تصمیم بهتری بگیرید، دشواری‌ها را پیش‌بینی کنید و راه‌حلی بسازید که برای آن آدم طبیعی به نظر برسد.

نسبت این دو با هم روشن است. داستان پرسونا «چرا» را می‌دهد، داستان کاربر «چگونه» و کنش‌های لازم را.

پرسونا همچنین کمک می‌کند مطمئن شوید داستان بازتاب کاربر واقعی است، نه فرض شما. چهره و بدنی به کاربر می‌دهد که دادهٔ خام نمی‌دهد.

خطاهای رایج

• - ۱. مبهم‌بودن: «به‌عنوان یک کاربر، داشبورد بهتری می‌خواهم» هیچ‌کدام از سه جای خالی را پر نمی‌کند. جایگزینش مشخص است: «به‌عنوان مدیر فروش، داشبوردی می‌خواهم که روند درآمد ماهانه را نشان دهد، تا اینکه عملکرد را پیگیری کنم».
• - ۲. تمرکز روی قابلیت به‌جای نیاز: داستان می‌گوید کاربر می‌خواهد به چه برسد، نه اینکه چه کارکردی ساخته شود.
• - ۳. داستان‌های بزرگ: هر داستان یک کنش. اگر بیش از حد گسترده شد، آن را به داستان‌های کوچک‌تر بشکنید.
• - ۴. نادیده‌گرفتن پژوهش: داستان باید از بازخورد و دادهٔ واقعی بیرون بیاید. فرض‌های خودتان دربارهٔ کاربر را باید در پژوهش بیازمایید.

خطای پنجمی هم هست که به ذی‌نفعان مربوط می‌شود. ذی‌نفع باید در نوشتن داستان شرکت کند، اما نباید تنها بنویسدش.

مدیر محصول و تیم بازاریابی، هدف کسب‌وکار و نقاط درد مشتری را می‌دانند. مدیر پشتیبانی می‌داند شکایت تکرارشده کجاست. ورودی این آدم‌ها هدف کسب‌وکار را به نیاز کاربر گره می‌زند.

در مقابل، ذی‌نفع گاهی مستقیم قابلیت سفارش می‌دهد. «یک چت‌بات اضافه کنید» یک راه‌حل است، نه یک داستان. کار طراح این است که آن درخواست را به هدف کاربر برگرداند: «کمک کنیم کاربر جواب سؤالش را راحت پیدا کند».

پس کار طراح در این جلسه، مهار فرض‌هایی است که پیش از موعد به فضای راه‌حل سرک می‌کشند.

ریسک تکیهٔ بیش از حد بر داستان

تکیهٔ زیاده بر داستان کاربر، فرایند طراحی را ناقص و جانب‌دار می‌کند.

یک: نبودِ بافت. داستان کوتاه است و همیشه نمی‌گوید کاربر در زندگی واقعی چطور رفتار می‌کند.

«به‌عنوان خریدار، پرداخت سریع‌تر می‌خواهم» چرا؟ چون فرم‌ها طولانی‌اند یا چون به درگاه پرداخت اعتماد ندارد؟ پاسخ این دو پرسش، دو محصول کاملاً متفاوت می‌سازد.

دو: قابلیت‌محورشدن. اگر تیم فقط داستان‌ها را دنبال کند، به قابلیت‌های تک‌تک می‌رسد و کل گردش کاربر را از دست می‌دهد.

قابلیتی که امروز ضروری به نظر می‌رسد، در تجربهٔ کامل ممکن است فقط شلوغی باشد. چیزی که «خوب است داشته باشیم» به‌راحتی به مانع تبدیل می‌شود.

سه: کنارگذاشتن پژوهش گسترده‌تر. داستان باید به مصاحبه، آزمون کاربردپذیری و داده تکیه کند.

تکیه بر داستان تنها، طراحی برای فرض است. فرض هم در آزمون کاربردپذیری خودش را نشان می‌دهد، آن هم دیر.

جای خالی سوم، تنها بخشی است که دلیل را حمل می‌کند

این بخش افزودهٔ من است، چون سه جای خالی معمولاً کنار هم و هم‌ارز فهرست می‌شوند.

هم‌ارز نیستند. اگر داستان‌های هر بک‌لاگ واقعی را باز کنید، احتمالاً دو جای خالی اول پر است و سومی حذف شده.

دلیلش هم مکانیکی است. جای خالی اول و دوم به چیزهایی نگاشت می‌شوند که ابزار از قبل دارد: نقش و عنوان تیکت. جای خالی سوم به هیچ فیلدی نگاشت نمی‌شود.

اثرش دقیقاً یک اثر هندسی است: فضای راه‌حل جمع می‌شود.

«می‌خواهم رستوران خوب پیدا کنم» به‌تنهایی یک دستور است. یک فهرست رستوران بسازید و داستان بسته می‌شود.

همان جمله با «تا اینکه سریع غذا بخورم»، چند راه‌حل ممکن باز می‌کند و هیچ‌کدام «فهرست» نیست: مرتب‌سازی بر اساس زمان تحویل، ذخیرهٔ محبوب‌ها، پیشنهاد دوستان.

پس آزمون سلامت یک داستان، آزمون گرامری نیست. داستان سالم بیش از یک راه‌حل مجاز دارد.

اگر از داستان شما فقط یک پیاده‌سازی بیرون می‌آید، آن داستان نیست. یک تیکت است که لباس داستان پوشیده.

آزمون دومی هم هست که ارزان‌تر است. جای خالی سوم را بپوشانید و از تیم بپرسید این داستان چه چیزی را بهتر می‌کند.

اگر کسی جواب نداشت، آن جمله هرگز داستان نبوده. اگر همه یک جواب داشتند، همان جواب را بنویسید و جای خالی سوم را پر کنید.

نقشهٔ داستان: بک‌لاگ یک ستون نیست

این بخش هم افزودهٔ من است، چون بک‌لاگ در عمل به یک فهرست تک‌ستونی تبدیل می‌شود.

فهرست یک محور دارد: اولویت. با یک محور نمی‌توانید بگویید کدام ترکیب از داستان‌ها یک سفر کامل می‌سازد.

راهش این است که همان داستان‌ها را روی دو محور بچینید.

محور افقی، فعالیت‌های کاربر است. از کشف تا جست‌وجو، سبد، پرداخت و پیگیری سفارش. این ترتیب همان ترتیبی است که کاربر طی می‌کند.

محور عمودی، اولویت است. زیر هر فعالیت، داستان‌های آن فعالیت از ضروری به دلخواه پایین می‌روند.

حالا یک خط افقی بکشید. هر چیزی بالای خط، انتشار اول است.

سود این کار در همان خط است. برش افقی همیشه یک سفر کامل می‌دهد.

در مقابل، برش از بالای یک فهرست ممکن است پنج داستان از سبد خرید بدهد و صفر داستان از پرداخت. محصولی که سبد دارد و پرداخت ندارد، محصول نیست.

ستون خالی هم خودش اطلاعات است. اگر زیر «پیگیری سفارش» هیچ داستانی نیست، یعنی آن فعالیت را ندیده‌اید. در یک فهرست، غیبت هیچ شکلی ندارد.

نسبتش با تخته‌های کانبان هم مکمل است. کانبان می‌گوید کار الان کجاست، نقشهٔ داستان می‌گوید کار در کدام بخش از سفر می‌نشیند.

اپیک هم در این تصویر جای طبیعی خودش را پیدا می‌کند. ستون‌های محور افقی، همان اپیک‌ها هستند که به‌ترتیب سفر چیده شده‌اند.

در بافت فارسی

یک: داستان به فارسی، بک‌لاگ به انگلیسی. در بیشتر تیم‌های اینجا داستان در جلسه فارسی گفته می‌شود و در ابزار انگلیسی ثبت می‌شود.

در این جابه‌جایی، چیز مشخصی می‌افتد. عنوان تیکت انگلیسی ناچار نامِ قابلیت می‌شود: add saved cards. نه نقشی در آن است و نه دلیلی.

نام شاخه هم همین را تکرار می‌کند و پیام کامیت هم از نام شاخه می‌آید. پس تا وقتی کار به بازبینی کد برسد، از آن جملهٔ سه‌بخشی فقط قابلیت مانده است.

راهش ساده است. جملهٔ کامل فارسی را خط اول بدنهٔ تیکت بگذارید و عنوان انگلیسی را فقط یک برچسب بدانید.

دو: «به‌عنوان یک کاربر» در فارسی از این هم بی‌چهره‌تر است. فارسی حرف تعریف ندارد و «کاربر» جنسیت و سن و نقش را هم نمی‌رساند.

پس همان جملهٔ بی‌فایدهٔ انگلیسی، در فارسی یک درجه بی‌فایده‌تر می‌شود. نام پرسونا را بنویسید، نه نقش عام.

سه: معیار پذیرش را به زبان تصمیم بنویسید. معیار پذیرش انگلیسی نوشته می‌شود و بعد در جلسه‌ای فارسی پذیرفته می‌شود.

هر ابهامی که در ترجمهٔ لحظه‌ای بماند، درست سر همان جلسه بیرون می‌زند. اگر بحث فارسی است، معیار را هم فارسی بنویسید.

منطق لین یو‌ایکس هم همین است: سند برای گرفتن تصمیم نوشته می‌شود، نه برای بایگانی.

چهار: داستان‌هایی که در هیچ الگوی وارداتی نیستند. تاریخ شمسی، نیم‌فاصله در جست‌وجو، شمارهٔ موبایل با صفر آغازین، و درگاه پرداختی که ناموفق برمی‌گردد.

هیچ‌کدام از این‌ها در قالب‌های آمادهٔ انگلیسی نیست. با این حال هر چهار مورد، داستان واقعی کاربر ایرانی‌اند.

پس نوشتن این چهار داستان بر عهدهٔ خود تیم است. هیچ الگویی آن‌ها را به شما یادآوری نمی‌کند.

جمع‌بندی

• - داستان کاربر: گزارهٔ کوتاهی دربارهٔ یک قابلیت، از زبان کاربر — که خودِ قابلیت را تعیین نمی‌کند
• - قالب سه‌بخشی: به‌عنوان یک ‹نقش› · می‌خواهم ‹کنش› · تا اینکه ‹نتیجه›
• - سه جزء: کاربرِ مشخص · یک کنش معنادار · دلیلی که هدف قابلیت را روشن می‌کند
• - نتیجهٔ خوب سنجش‌پذیر است، و معیار پذیرش ابهام عمدی داستان را مهار می‌کند
• - اندازه: داستان به‌اندازهٔ یک اسپرینت · اپیک به‌اندازهٔ یک دستهٔ داستان
• - در برابر مورد کاربرد: یکی کوتاه و همه‌فهم است · دیگری گام‌به‌گام و برای شرح رفتار سامانه
• - داستان پرسونا «چرا» را می‌دهد، داستان کاربر «چگونه» را
• - خطاهای رایج: ابهام · قابلیت‌محوری · داستان بزرگ · بی‌اعتنایی به پژوهش · نوشتن به‌دست ذی‌نفع تنها
• - ریسک‌ها: نبود بافت · تمرکز بر قابلیت به‌جای سفر · کنارگذاشتن پژوهش گسترده‌تر
• - جای خالی سوم تنها بخشی است که دلیل را حمل می‌کند: با حذفش فضای راه‌حل به یک پیاده‌سازی جمع می‌شود
• - آزمون سلامت: داستان سالم بیش از یک راه‌حل مجاز دارد
• - نقشهٔ داستان: فعالیت‌ها روی محور افقی · اولویت روی محور عمودی · و برش افقی همیشه یک سفر کامل
• - در فارسی: جملهٔ کامل را در بدنهٔ تیکت بگذارید · نام پرسونا را بنویسید · معیار پذیرش را به زبان بحث بنویسید · و چهار داستان محلی را خودتان اضافه کنید