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

جریان کاربر (User Flow) چیست؟

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

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

در مقالهٔ استوری‌بورد گفتیم که این ابزارها هرکدام به یک سؤال متفاوت جواب می‌دهند. جریان کاربر به این سؤال جواب می‌دهد: «مسیرهای ممکن میان صفحه‌ها کدام‌اند و کجا شاخه می‌خورند؟» نه احساس، نه زمینه، نه قصه — فقط ساختار. و همین محدودبودنش، قوتش است.

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

چهار شکلی که همه یک‌جور می‌خوانند

جریان کاربر یک زبان بصری مشترک دارد که از فلوچارت‌های مهندسی آمده. رعایتش مهم است، چون هدف اصلی این نمودار ارتباط است و زبان اختراعی، ارتباط را خراب می‌کند:

• - بیضی — نقطهٔ شروع و پایان جریان.
• - مستطیل — یک فرایند یا صفحه؛ چیزی که سامانه نشان می‌دهد یا گامی که برداشته می‌شود.
• - لوزی — نقطهٔ تصمیم و شاخه‌شدن مسیر.
• - متوازی‌الاضلاع — ورودی یا خروجی؛ داده‌ای که کاربر می‌دهد یا می‌گیرد.

یک قاعدهٔ ساده که خیلی کمک می‌کند: هر لوزی باید دست‌کم دو خروجی داشته باشد و هر خروجی باید برچسب داشته باشد. لوزی بدون برچسب، یعنی کسی نمی‌داند کدام شاخه کدام است — و نمودار به یک تصویر تزئینی تبدیل می‌شود.

چهار نوع جریان

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

• - تسک‌فلو (Task flow): یک مسیر، بدون شاخه. وقتی همهٔ کاربران دقیقاً یک کار را یک‌جور انجام می‌دهند. ساده و سریع، اما واقعیت را ساده‌سازی می‌کند.
• - جریان کاربر (User flow): با شاخه و تصمیم. آدم‌های مختلف، مسیرهای مختلف. این چیزی است که معمولاً واقعاً به آن نیاز دارید.
• - وایرفلو (Wireflow): جریانی که به‌جای مستطیل ساده، با وایرفریم کشیده شده. هم‌زمان چیدمان و ترتیب را نشان می‌دهد و برای تحویل به تیم توسعه فوق‌العاده است — اما سنگین‌تر است و با هر تغییر طراحی قدیمی می‌شود.
• - جریان داده (Data flow): اینکه اطلاعات چطور میان سامانه‌ها جابه‌جا می‌شود. دربارهٔ سامانه‌هاست، نه آدم‌ها — و به‌همین دلیل نباید با جریان کاربر یکی گرفته شود.

نقاط ورود: جریان از صفحهٔ اول شروع نمی‌شود

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

کسی که از جست‌وجوی «قیمت اشتراک» آمده، با کسی که روی تبلیغ اینستاگرام کلیک کرده، یک آدم نیست — حتی اگر هر دو به یک صفحه برسند. اولی می‌داند دنبال چیست؛ دومی شاید حتی اسم شما را نشنیده باشد.

نتیجهٔ عملی: نمودار جریانی که فقط یک نقطهٔ ورود دارد، احتمالاً فقط تجربهٔ خودِ تیم را ترسیم کرده است — چون تیم همیشه از صفحهٔ اصلی وارد می‌شود. برای هر جریان مهم، دست‌کم دو یا سه ورودی واقعی را از داده‌های تحلیلی بردارید و ببینید مسیر از آنجا چه شکلی می‌شود.

مسیر خوش‌بینانه، نیمهٔ آسان کار است

اینجا مهم‌ترین بخش این نوشته است و اتفاقاً همان‌جایی که بیشتر نمودارها شکست می‌خورند. کشیدن مسیر موفق — همان «مسیر خوش‌بینانه» یا happy path — کار سختی نیست. ارزش واقعی جریان کاربر در شاخه‌هایی است که کسی نکشیده:

پنج سؤالی که در تصویر آمده، در عمل بیشترین بازده را دارند. برای هر صفحهٔ جریان بپرسید:

• - اگر داده‌ای وجود نداشته باشد چه؟ (حالت خالی — که تقریباً همیشه فراموش می‌شود)
• - اگر وسط کار اینترنت قطع شود چه؟
• - اگر کاربر از قبل وارد حساب شده باشد چه؟
• - اگر دکمهٔ بازگشت را بزند چه؟
• - اگر کار شکست بخورد، می‌تواند بدون شروع از صفر جبران کند؟

سؤال آخر از همه مهم‌تر است. تفاوت میان محصولی که «گاهی اذیت می‌کند» و محصولی که «غیرقابل‌تحمل است»، معمولاً در همین است: آیا بعد از خطا، کاربر از همان‌جا ادامه می‌دهد یا باید همه‌چیز را از نو وارد کند؟

شش قدم برای رسم یک جریان

• - ۱. سفر کاربر را بفهمید و پرسونا بسازید. جریان بدون اینکه بدانید برای چه کسی است، فقط نمودار سامانه است. اینجا پرسونا و تحقیق کاربر ورودی کارند.
• - ۲. هدف سازمان را با هدف کاربر تطبیق بدهید. اگر این دو در تضاد باشند، نمودار شما آن تضاد را پنهان نمی‌کند — بلکه دقیقاً همان‌جایی که کاربر رها می‌کند، نشانش می‌دهد.
• - ۳. نقاط ورود را مشخص کنید.
• - ۴. گام‌ها را بر اساس دغدغه‌های کاربر بچینید، نه بر اساس ساختار داخلی سامانه. (کاربر نمی‌داند و برایش مهم نیست که این دو صفحه در دو سرویس مختلف‌اند.)
• - ۵. با نمادهای استاندارد بکشید.
• - ۶. با بازخورد اصلاح کنید و دوباره دور بزنید.

یک توصیهٔ عملی که در منبع نیست: جریان را با یک مهندس و یک نفر از پشتیبانی مرور کنید. مهندس شاخه‌هایی را می‌بیند که در کد وجود دارند و شما نکشیده‌اید؛ پشتیبانی حالت‌هایی را می‌شناسد که کاربران واقعی هر هفته در آن‌ها گیر می‌کنند. این دو نفر معمولاً بیشتر از هر جلسهٔ طراحی به نمودار شما اضافه می‌کنند.

چه وقت و چرا از جریان کاربر استفاده کنیم؟

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

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

تفاوت با نقشهٔ سفر، سایت‌مپ و وایرفریم

• - نقشهٔ سفر مشتری کل تجربهٔ کاربر با محصول یا خدمت را می‌گیرد — نگاهی پهن که احساس‌ها، نقاط درد و لحظه‌های لذت را هم دربر دارد. جریان کاربر در مقابل، روی توالی گام‌های یک کار مشخص متمرکز است. اولی پهن و کم‌عمق، دومی باریک و دقیق.
• - سایت‌مپ ساختار محتوا را نشان می‌دهد: چه چیزی زیر چه چیزی قرار دارد. جریان کاربر ساختار رفتار را نشان می‌دهد: کاربر از کجا به کجا می‌رود. یک سایت‌مپ سلسله‌مراتبی است و یک جریان، شبکه‌ای. برای همین است که معماری اطلاعات خوب، جریان‌ها را ساده‌تر می‌کند اما جایشان را نمی‌گیرد.
• - وایرفریم می‌گوید یک صفحه چه شکلی است؛ جریان می‌گوید صفحه‌ها چطور به هم وصل می‌شوند. معمولاً جریان اول می‌آید و بعد وایرفریم — چون تا ندانید چند صفحه لازم دارید، نمی‌دانید چه چیزی را باید طراحی کنید.

اشتباه‌های رایج

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

چند نکتهٔ عملی

• - یک جریان، یک هدف. اگر عنوان نمودارتان «و» دارد، احتمالاً دو نمودار است.
• - جهت را ثابت نگه دارید. در رابط فارسی هم بهتر است جریان‌ها را از بالا به پایین بکشید؛ جهت افقی در متن راست‌به‌چپ سریع گیج‌کننده می‌شود.
• - شاخه‌های خطا را رنگی کنید. نگاه اول باید بگوید مسیر اصلی کدام است.
• - شمارهٔ صفحه‌ها را با وایرفریم هماهنگ کنید تا مهندس بتواند بین دو سند رفت‌وبرگشت کند.
• - تاریخ بگذارید. جریان‌ها سریع قدیمی می‌شوند و نمودار بی‌تاریخ، بدتر از نبودنش است.

رسم جریان برای محصول راست‌به‌چپ

این بخش افزودهٔ مترجم است و به پرسشی جواب می‌دهد که در هیچ راهنمای انگلیسی‌زبانی مطرح نمی‌شود: نمودار جریان برای محصولی که رابطش راست‌به‌چپ است، خودش باید از کدام سمت شروع شود؟

پاسخ عملی: جهت نمودار را از جهت خواندنِ متنِ نمودار تعیین کنید، نه از جهت رابط. اگر برچسب‌های نمودار فارسی است، نمودار هم باید از راست به چپ جریان پیدا کند؛ چشمِ خوانندهٔ فارسی‌زبان از راست شروع می‌کند و نموداری که برچسب فارسی دارد ولی از چپ به راست می‌رود، در هر گام یک پرش اضافه تحمیل می‌کند. این هزینه در نمودارهای بزرگ جدی می‌شود.

و چند نکتهٔ عملی که از همین انتخاب بیرون می‌آید:

• - پیکان‌ها را قرینه کنید. در جریان راست‌به‌چپ، «قدم بعدی» با پیکان به چپ نشان داده می‌شود. اگر قالب آمادهٔ لاتین را قرض بگیرید و فقط متن‌ها را فارسی کنید، همهٔ پیکان‌ها پیام معکوس می‌دهند.
• - لوزی تصمیم و ترتیب شاخه‌ها. در نمودار راست‌به‌چپ، شاخهٔ «بله» را در امتداد جریان اصلی بگذارید و «خیر» را به پایین منحرف کنید. ترتیب چپ و راست شاخه‌ها را از قالب لاتین کپی نکنید.
• - یکدست بمانید. بدترین حالت نموداری است که نیمی راست‌به‌چپ و نیمی چپ‌به‌راست است — که وقتی چند نفر روی یک فایل کار می‌کنند زیاد پیش می‌آید. جهت را در ابتدای فایل بنویسید.
• - اگر مخاطب نمودار انگلیسی‌زبان است (مثلاً تیم فنی برون‌سپاری‌شده)، نمودار را چپ‌به‌راست و با برچسب انگلیسی بکشید. مهم این است که یک نمودار، یک جهت و یک زبان داشته باشد.

از نمودار به کد: چیزی که در جریان باید نوشته شود

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

• - شرط دقیق هر تصمیم. لوزی‌ای که رویش نوشته «کاربر وارد شده؟» کافی نیست. توسعه‌دهنده باید بداند بر اساس چه چیزی سنجیده می‌شود و اگر وضعیت نامعلوم بود چه اتفاقی می‌افتد. حالت سوم — «نمی‌دانیم» — تقریباً همیشه فراموش می‌شود و در محصول به باگ تبدیل می‌شود.
• - حالت انتظار. بین دو گام معمولاً یک درخواست شبکه هست. اگر در نمودار «در حال ارسال» و «مهلت تمام شد» را نکشیده باشید، هیچ‌کس آن حالت‌ها را طراحی نمی‌کند — و در بازارِ ما با اینترنت ناپایدار، این حالت‌ها اقلیت نیستند.
• - بازگشت‌پذیری. برای هر گام مشخص کنید کاربر می‌تواند برگردد یا نه، و اگر برگشت، داده‌های واردشده می‌مانند یا پاک می‌شوند. این یکی از پرهزینه‌ترین ابهام‌ها در تحویل به توسعه است.
• - مقصد خروج. هر مسیر بی‌بازگشت — انصراف، خطای نهایی، اتمام مهلت — باید به یک صفحهٔ مشخص برسد. جریانی که در آن یک پیکان به هوا می‌رود، در محصول به صفحهٔ سفید تبدیل می‌شود.

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

جمع‌بندی

• - جریان کاربر نموداری است از مسیرهای ممکن برای انجام یک کار؛ به این سؤال جواب می‌دهد که مسیرها کجا شاخه می‌خورند.
• - بیشتر مشکلات جدی در فاصلهٔ میان صفحه‌هاست، نه در خودِ صفحه‌ها.
• - چهار شکل استاندارد: بیضی، مستطیل، لوزی و متوازی‌الاضلاع — و هر لوزی دست‌کم دو خروجی برچسب‌دار می‌خواهد.
• - چهار نوع جریان: تسک‌فلو، جریان کاربر، وایرفلو و جریان داده.
• - کاربران از نقاط ورود مختلف با قصدهای مختلف می‌آیند؛ جریان تک‌ورودی معمولاً تجربهٔ خودِ تیم را ترسیم کرده است.
• - مسیر خوش‌بینانه نیمهٔ آسان کار است؛ ارزش واقعی در شاخه‌های خطا و حالت‌های حاشیه‌ای است.
• - جریان با نقشهٔ سفر، سایت‌مپ و وایرفریم فرق دارد و جای هیچ‌کدام را نمی‌گیرد.
• - هر مسیر نمودار، یک تسک آمادهٔ تست کاربردپذیری است.
• - جهت نمودار را از زبان برچسب‌هایش تعیین کنید: نمودار با برچسب فارسی باید از راست به چپ جریان پیدا کند و پیکان‌هایش قرینه شوند.
• - یک نمودار، یک جهت و یک زبان — نیمه‌قرینه بودن بدترین حالت است و وقتی چند نفر روی یک فایل کار می‌کنند زیاد پیش می‌آید.
• - چهار چیزی که همیشه از قلم می‌افتد: شرط دقیق هر تصمیم و حالت «نمی‌دانیم»، حالت انتظار و اتمام مهلت، بازگشت‌پذیری و سرنوشت داده‌ها، و مقصد هر مسیر خروج.
• - سنجهٔ کیفیت نمودار: آن را به توسعه‌دهنده بدهید و بپرسید کجا باید حدس بزنی؟ هر حدس، تصمیمی است که شما نگرفته‌اید.