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

فلوچارت (Flowchart) چیست؟

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

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

و بیشتر فایدهٔ فلوچارت از همین‌جا می‌آید، نه از زیبایی نمودار.

تعریف

فلوچارت نموداری است که جریان‌ها و کارهای کاربر را در یک فرایند تصویر می‌کند — با نمادهای استاندارد و برچسب‌خورده که با خط به هم وصل شده‌اند.

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

چهار نماد

• - بیضی: نقطهٔ شروع و پایان. مثل «کاربر وارد صفحهٔ اصلی می‌شود».
• - مستطیل: فرایند یا کنش کاربر یا عملیات سیستم. مثل «ایمیل را وارد می‌کند».
• - لوزی: نقطهٔ تصمیم که کاربر باید انتخاب کند. مثل «رمز معتبر است؟»
• - خط با پیکان: جهت حرکت کاربر در جریان.

و یک قرارداد چیدمانی هم هست: داده از چپ به راست و از بالا به پایین ارائه می‌شود.

این قرارداد در فارسی مسئله‌ساز می‌شود و در بخش آخر به آن برمی‌گردم.

سه نوع

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

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

ساختنش

پنج قدم برای یک اپ موبایل:

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

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

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

قاعده‌ها

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

و خطاهایی که باید از آن‌ها پرهیز کرد، آینهٔ همین‌هاست:

• - نادیده‌گرفتن تصمیم‌های کاربر و مسیرهای جایگزین.
• - شلوغ‌کردن نمودار با جزئیات زیاد.
• - برچسب مبهم.
• - قدم شناور و بی‌اتصال.
• - و نبودِ حلقهٔ بازخورد و حالت خطا.

یک قاعدهٔ عملی

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

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

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

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

کجا بس نیست

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

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

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

در بافت فارسی

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

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

دو: برچسب‌های دوزبانه، نمودار را ناخوانا می‌کنند. مستطیلی که «Enter OTP» نوشته کنار مستطیلی که «تأیید شماره» نوشته، چشم را در هر قدم می‌چرخاند.

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

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

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

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

این‌ها را معمولاً نمی‌کشند چون «مال ما نیستند». ولی اگر کاربر از آن‌ها عبور می‌کند، بخشی از جریان‌اند — و بن‌بست‌های واقعی اغلب دقیقاً همان‌جا هستند.

جمع‌بندی

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