دفترچه تصمیم: چرا طراحان برتر تصمیم‌هایی را مستند می‌کنند که هیچ‌کس نپرسیده بود

یک طراح ارشد و یک طراح میان‌رده می‌توانند دقیقاً یک صفحه‌ی یکسان را تحویل بدهند. طراح ارشد یادش می‌ماند «چرا». طراح میان‌رده فقط یادش می‌ماند «چه چیزی».

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

تیم‌هایی که در ۲۰۲۶ سطح را تعیین می‌کنند همین حالا از آن استفاده می‌کنند. Linear دارد design RFCها. Vercel مشخصات محصول را کنار مشخصات مهندسی منتشر می‌کند. Anthropic یادداشت‌های پژوهشی منتشر می‌کند. Stripe اسناد بازبینی طراحی را اجرا می‌کند. Brian Lovin دفترچه‌اش را روی یک سایت شخصی عمومی نگه می‌دارد. Jordan Singer محصولات کوچک را همراه با دفتر خاطرات طراحی عمومی منتشر می‌کند. در هر اتاق همان مصنوع است.

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

مصنوعی که بیشتر طراحان نگه نمی‌دارند

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

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

دفترچه تصمیم واقعاً چیست

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

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

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

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

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

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

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

این عادت از کجا آمد

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

نرم‌افزار آن را از طریق فرهنگ RFC به ارث برد. IETF از ۱۹۶۹ اسناد Request for Comments منتشر می‌کند. ADRها (سوابق تصمیم معماری) در Spotify، Pivotal و Thoughtworks همان مصنوع در مقیاس کوچک‌ترند. تازه‌ترین وراثت از آزمایشگاه‌های پژوهشی است. Anthropic یادداشت‌های پژوهشی منتشر می‌کند که در سطح مدل مثل دفترچه تصمیم خوانده می‌شوند.

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

قالب شش‌فیلدی، کپی‌اش کنید

شش فیلد. Decision، Alternatives، Constraints، Reasoning، Owner، Outcome. قالب عمداً کوتاه است. انضباط در نوشتن آن است، نه طراحی‌اش. این بلوک را کپی کنید. فردا استفاده‌اش کنید.

Date: 2026-04-30 Project: Acme Onboarding v3 Decision Stack email and password vertically on the signup screen, no inline social login row. Alternatives 1. Inline social login row (Google, Apple, GitHub) above the fields. 2. Two-step flow, email first then password on screen 2. 3. Magic-link only, no password field. Constraints - Mobile-first, 360px min width, single column. - Engineering will not ship social OAuth this quarter. - Support flagged 14% of tickets as password reset confusion. - [Brand voice](/paper/glossary/brand-voice) rejects "Continue with" social patterns as generic. Reasoning Vertical stack ships fastest and matches the brand register. Two-step tested cleaner in 2024 but added a screen we cannot afford given the 38% drop on screen 2. Magic-link only blocks the password manager flow 22% of paid users rely on. Owner Maya Chen, design. Reviewer: Jordan Park, eng lead. Outcome (filled 2 weeks post-ship) Conversion +6.1% vs v2. Password reset tickets dropped 9%. Re-evaluate magic-link as v3.1 when OAuth lands in Q3.

Copy

یک مورد برای هر تصمیم واقعی. پنج تا ده مورد برای هر پروژه. صفحه‌ی جلد را رها کنید. بلوک بالا همان کار است.

هر فیلد را چطور بدون طفره نوشت

هر فیلد یک قاعده دارد. قاعده را رد کنید و دفترچه تبدیل به نمایش می‌شود.

Decision. یک جمله، زمان حال، مشخص. «email و password را عمودی روی هم بچین.» نه «حس کردیم شاید عمودی جواب بدهد.» اگر تصمیم هنوز گرفته نشده، هنوز موردش را ننویس.

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

Constraints. فهرست نقطه‌ای، نام‌دار، با منبع. ظرفیت مهندسی، قواعد برند، تیکت‌های پشتیبانی، کف دسترس‌پذیری، بودجه‌ی عملکرد. بدون آن‌ها دفترچه مثل شستن سلیقه به نظر می‌رسد.

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

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

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

دفترچه را کجا نگه داریم

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

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

اسناد Linear. انتخاب درست اگر مهندسی و طراحی از قبل آنجا زندگی می‌کنند. تصمیم‌ها کنار issueهایی که آن‌ها را برانگیخته‌اند می‌نشینند و تبدیل به RFC مهندسی یک کلیک است.

یک فایل markdown در ریپو. انتخاب درست برای مهندسان طراحی و صاحبان سیستم طراحی. یک decisions.md در ریشه‌ی ریپو یا زیر /docs/decisions/ جدی به نظر می‌رسد چون همراه کد نسخه‌بندی می‌شود. مهندسان این قالب را همان لحظه‌ی اول محترم می‌شمارند.

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

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

design RFCهای Linear و مشخصات محصول Vercel

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

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

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

یادداشت‌های پژوهشی Anthropic و اسناد بازبینی طراحی Stripe

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

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

اگر برای ساختن این در مهارت تیمتان کمک می‌خواهید، Brainy را استخدام کنید. BrandBrainy لایه‌ی مهارتی را تحویل می‌دهد که هوش مصنوعی نمی‌تواند جعل کند. ClaudeBrainy Skill packها و کتابخانه‌های پرامپت را تحویل می‌دهد که دفترچه را از یک انضباط به یک پیش‌فرض تبدیل می‌کنند.

Brian Lovin و Jordan Singer دفترچه‌شان را عمومی نگه می‌دارند

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

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

هر دو قالبی‌اند که هر طراح شاغلی می‌تواند همین هفته کپی کند. سایت استاتیک، موارد شش‌فیلدی، تاریخ‌دار، عمومی، لینک‌شده. پانزده دقیقه برای هر مورد. ماهی سه تا. یک سال بعد، دفترچه عمومی به شکلی ارشد خوانده می‌شود که هیچ case study در Behance نمی‌شود.

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

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

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

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

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

استفاده از دفترچه در مصاحبه‌ها و بازبینی‌ها

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

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

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

طراحی که بتواند از دفترچه دفاع کند از کار دفاع می‌کند. طراحی که دفترچه ندارد از هیچ دفاع نمی‌کند.

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

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

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

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

FAQ

دفترچه تصمیم طراحی چیست؟

یک سابقه‌ی کوتاه ساختارمند از انتخاب‌های طراحی همراه با استدلال. شش فیلد برای هر مورد: Decision، Alternatives، Constraints، Reasoning، Owner، Outcome. تاریخ‌دار، مشخص، پیوند‌خورده به مصنوعات.

با case study چه فرقی دارد؟

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

کجا نگهش دارم؟

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

هر مورد چقدر باید طول بکشد؟

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

اگر شرکتم این را نپذیرد چه؟

شخصی اجرایش کنید. دفترچه‌ی فردی یک طراح در طول شغل‌ها انباشته می‌شود. Brian Lovin و Jordan Singer دفترچه‌شان را عمومی نگه می‌دارند. این عادت مال شماست، نه کارفرمایتان، و مصنوع با شما حرکت می‌کند.

همین هفته دفترچه را شروع کنید

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

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

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

اگر برای ساختن عادت دفترچه تصمیم در مهارت تیمتان کمک می‌خواهید، Brainy را استخدام کنید. BrandBrainy لایه‌ی برند و مهارت را تحویل می‌دهد که هوش مصنوعی نمی‌تواند جعل کند. ClaudeBrainy Skill packها و کتابخانه‌های پرامپت را تحویل می‌دهد که دفترچه را از یک انضباط به یک پیش‌فرض تبدیل می‌کنند. تیم‌هایی که همین حالا اجرایش می‌کنند دارند جلو می‌افتند. سطح در حال بالا رفتن است و طراحی که همین هفته شروع کند همان کسی است که تیم‌های نام‌برده یک فصل بعد او را می‌خوانند.