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

پنج مرحله در فرایند تفکر طراحی

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

تفکر طراحی (Design Thinking) یک روش‌شناسی انسان‌محور برای رویارویی با مسئله‌هایی است که پیچیده، مبهم یا بدتعریف‌اند؛ همان مسئله‌هایی که با روش‌های تحلیلی معمول به‌سادگی حل نمی‌شوند. در میان مدل‌های گوناگونی که برای این رویکرد ارائه شده، مدل پنج‌مرحله‌ای مؤسسهٔ طراحی دانشگاه استنفورد (d.school) شناخته‌شده‌ترین است: همدلی، تعریف، ایده‌پردازی، نمونه‌سازی و آزمایش.

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

مرحلهٔ ۱: همدلی — نیازهای کاربران‌تان را بشناسید

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

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

مرحلهٔ ۲: تعریف — نیازها و مسئله‌های کاربران را بیان کنید

حالا وقت آن است که یافته‌های مرحلهٔ همدلی را کنار هم بگذارید، مشاهدات‌تان را تحلیل کنید و مسئلهٔ اصلی را از دل آن‌ها بیرون بکشید. خروجی این مرحله، «بیانیهٔ مسئله» (Problem Statement) است.

بیانیهٔ مسئله باید انسان‌محور نوشته شود؛ یعنی از زاویهٔ نیاز کاربر، نه هدف کسب‌وکار. برای مثال به‌جای اینکه بگویید «باید سهم بازار محصول در میان دختران نوجوان را ۵٪ افزایش دهیم»، بنویسید «دختران نوجوان برای سالم‌ماندن به غذای مقوی نیاز دارند». همین جابه‌جایی زاویهٔ دید، مسیر تمام راه‌حل‌های بعدی را عوض می‌کند.

مرحلهٔ ۳: ایده‌پردازی — فرضیه‌ها را به چالش بکشید و ایده بسازید

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

تکنیک‌های شناخته‌شده‌ای برای این کار وجود دارد؛ از جمله طوفان فکری (Brainstorm)، نگارش فکری (Brainwrite)، بدترین ایدهٔ ممکن (Worst Possible Idea) و اسکمپر (SCAMPER). تکنیک‌هایی مثل «بدترین ایدهٔ ممکن» عمداً ذهن را از قضاوت آزاد می‌کنند تا ایده‌های غیرمنتظره فرصت ظهور پیدا کنند. در پایان این مرحله، چند ایدهٔ برتر را برای ادامهٔ مسیر انتخاب می‌کنید.

مرحلهٔ ۴: نمونه‌سازی — ساختن راه‌حل‌ها را شروع کنید

در این مرحله، تیم نسخه‌های کم‌هزینه و ساده‌شده از محصول (یا از قابلیت‌های خاصی از آن) می‌سازد تا راه‌حل‌های مرحلهٔ قبل را در عمل بررسی کند. نمونهٔ اولیه می‌تواند به‌سادگی یک ماکت کاغذی یا به‌پیچیدگی یک پروتوتایپ تعاملی باشد.

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

مرحلهٔ ۵: آزمایش — راه‌حل‌های‌تان را امتحان کنید

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

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

آیا می‌دانستید تفکر طراحی فرایندی غیرخطی است؟

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

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

این پنج مرحله از کجا آمد

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

ریشهٔ فکری این رویکرد قدیمی‌تر از خودِ اصطلاح است. هربرت سایمون در کتاب The Sciences of the Artificial (۱۹۶۹) طراحی را به‌عنوان شکلی از حل مسئله صورت‌بندی کرد و بسیاری از عناصری که امروز در تفکر طراحی می‌بینیم — نمونه‌سازی، آزمون، تکرار — همان‌جا هستند. آنچه در دههٔ ۲۰۰۰ اتفاق افتاد، بسته‌بندی این ایده‌ها در قالبی آموزش‌پذیر بود: مدرسهٔ طراحی استنفورد (d.school) آن را به پنج مرحله تقسیم کرد و شرکت IDEO و نوشته‌های تیم براون آن را از دنیای طراحی به دنیای مدیریت بردند.

و همین‌جاست که نکتهٔ مهم روشن می‌شود: پنج‌مرحله‌ای‌بودن یک انتخاب آموزشی است، نه کشف علمی. شورای طراحی بریتانیا همان فرایند را در چهار مرحله و در قالب «دو الماس» (Double Diamond) توضیح می‌دهد؛ جایی که تأکید روی رفت‌وبرگشت میان واگرایی و همگرایی است، دو بار: یک بار برای پیدا‌کردن مسئلهٔ درست و یک بار برای پیدا‌کردن راه‌حل درست. تقسیم‌بندی‌های دیگری هم وجود دارد. اگر تیمی سرِ «ما در مرحلهٔ سه هستیم یا چهار؟» بحث می‌کند، انرژی‌اش را جای غلط می‌گذارد.

دامِ هر مرحله

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

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

چه وقت این فرایند جواب نمی‌دهد

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

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

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

تفکر طراحی در سازمان‌های ایرانی

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

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

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

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

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

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

جمع‌بندی

مدل پنج‌مرحله‌ای استنفورد چارچوبی روشن برای حل خلاقانه و انسان‌محور مسئله‌هاست:

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

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