قالب مطالعه موردی طراحی: چگونه مطالعههای موردی بنویسیم که واقعاً کار می‌آورند
یک قالب کاربردی برای مطالعههای موردی طراحی که به نتیجه می‌رسند. هشت بخشی که مدیران استخدام می‌خوانند، اعدادی که باید نشان بدهید و راهی برای ارائه فرایند بدون خواب‌آلود کردن خواننده.
همین حالا هر مدیر استخدامی ده‌ها پورتفولیوی طراحی را در تب‌های مرورگر باز دارد. روی هر کدام سی ثانیه وقت می‌گذارد. شاید شصت ثانیه، اگر هیرو کارش را درست انجام داده باشد. مطالعه موردی برنده آن است که در همین بازه به سؤال واقعی مدیر جواب میدهد، نه آن که قشنگ‌ترین موکاپ‌ها را دارد.
این قالب کاربردی است. هشت بخش با ترتیب ثابت، اعدادی که اهمیت دارند و تصاویر فرایندی که واقعاً وزن دارند. اگر پورتفولیوی فعلی‌تان شبیه پروژه مدرسه است، این الگوی بازنویسی آن است.
مدیران استخدام واقعاً چه چیزی را می‌خوانند
مدیر استخدام دنبال شواهدی است که نشان بدهد چیزی تحویل داده‌اید که یک عدد را جابه‌جا کرده است. بقیه‌اش زمینه است. نمودارهای فرایند، مود بورد و پاراگراف‌های «سفر من» در رتبه دوم‌اند، نه اول. مطالعه موردی بازنده با سفر شروع می‌شود. مطالعه موردی برنده با نتیجه شروع می‌شود.
طراحانی که این را شهودی می‌فهمند پورتفولیوهایی می‌سازند که تبدیل میشوند. طراحانی که نمی‌فهمند پورتفولیوهایی می‌سازند که «بازخورد خوب می‌گیرند» و هیچ مصاحبه‌ای نه. تفاوت ساختاری است، نه هنری.
قالب هشت‌بخشی
این هشت بخش، به همین ترتیب، هر مطالعه موردی‌ای را که یک طراح باید بنویسد پوشش می‌دهند. پروژه‌های اصلی با همه جزئیات کار میشوند. پروژه‌های کوچک‌تر نسخه فشرده می‌گیرند. بخش‌ها ثابت می‌مانند.
بخش ۱: نتیجه در یک خط
با نتیجه شروع کنید، نه مقدمه‌چینی. یک جمله. طراحی چه چیزی را تحویل داد و چه چیزی تغییر کرد.
«فرایند پرداخت یک SaaS بی‌تو‌بی بازطراحی شد و نرخ تبدیل در سه‌ماهه اول ۳۲٪ بالا رفت.» این شروع یک مطالعه موردی است. «از انجام این پروژه برای یک استارتاپ مخفی در حوزه فینتک هیجان‌زده بودم» مطالعه موردی‌ای است که در پنج ثانیه بسته می‌شود.
مدیران استخدام این جمله آغازین را با بقیه صفحه مقایسه میکنند. اگر بقیه آن را تأیید کند، به خواندن ادامه می‌دهند. اگر مبهم باشد (تجربه را متحول کردیم، سفر را از نو تصور کردیم، راه تازه‌ای برای فکر کردن ساختیم)، فرض میکنند اعداد نیستند چون بد بوده‌اند. نتیجه را همان‌قدر ساده بنویسید که تیتر یک روزنامه اقتصادی.
بخش ۲: مسئله در یک پاراگراف
بخش مسئله جایی است که بیشتر پورتفولیوها خواننده را از دست می‌دهند. مثل مرور ادبیات یک کسب‌وکار خوانده می‌شود. مدیران استخدام به تاریخچه شرکت نیاز ندارند، به محدودیتی نیاز دارند که چالش طراحی را ساخته است.
حداکثر دو تا چهار جمله. چه چیزی خراب بود. به چه کسی آسیب می‌زد. چرا خراب ماند. این است مسئله.
یک پاراگراف مسئله خوب:
فرایند پرداخت در سطح سازمانی ۶۳٪ نرخ رهاکردن داشت، چون تیم‌های خرید نمی‌توانستند بدون اسکرین‌شات یک پیش‌فاکتور را با مالی به اشتراک بگذارند. فرایند موجود یک خریدار تنها با کارت اعتباری را فرض می‌کرد. اصلاح آن یعنی بازطراحی برای خرید کمیته‌ای با فاکتور net-60.
بدون پیشینه. بدون «کارفرما سراغ ما آمد». مستقیم سراغ محدودیت. مقاله اصول طراحی لندینگ پیج همین انضباط را برای متن بازاریابی توضیح میدهد. قاعده برای مطالعه موردی هم همان است.
بخش ۳: محدودیتها
مطالعه موردی بدون محدودیت شبیه داستان تخیلی خوانده می‌شود. هر پروژه واقعی محدودیت دارد (زمان، تیم، پلتفرم، انطباق، بودجه، سیستم موجود). فهرست کردن آنها اعتماد می‌سازد، چون ثابت می‌کند طراح در دنیای واقعی کار می‌کرده، نه روی یک ریبرند شخصی از یک برند فورچون ۵۰۰.
پنج تا هفت بولت. ملموس نگهشان دارید.
- تیم دو طراح، یک مهندس، یک PM
- شش هفته از شروع تا تحویل
- سیستم طراحی موجود قفل بود، فقط افزودن مجاز بود، بدون بازنویسی
- فقط سطح سازمانی، پرداخت مصرف‌کننده دست‌نخورده ماند
- باید با فرایند خرید SAP موجود یکپارچه می‌شد
- هدف دسترس‌پذیری WCAG سطح AA از روز اول
- بدون کار جدید بک‌اند، فقط فرانت‌اند و یکپارچه‌سازی
محدودیتها گلایه نیستند. شواهدی‌اند که طراح جعبه را شناخته بود، پیش از آن که داخلش طراحی کند.
بخش ۴: فرایند، فشرده
بیشتر مطالعههای موردی پورتفولیو در فرایند زیادی سرمایه‌گذاری میکنند. هر اسکچ واگرا، هر محصول کارگاه، هر مود بورد را می‌گذارند. مدیران استخدام آنها را نمی‌خوانند. دنبال سه چیزند: طراح مسئله را چارچوببندی کرد؟ راه‌حل را اعتبارسنجی کرد؟ آنچه طراحی کرد را تحویل داد؟
برای هر کدام یک بار شواهد نشان دهید.
شواهد چارچوببندی: یک نمودار، فلو یا ماتریس تصمیم که نشان بدهد دامنه چگونه تعریف شد. یک نقشه سفر، یک service blueprint، خلاصه تحلیل رقبا، یا اسکرین‌شات لاگ تصمیم. یک مصنوع، با برچسبی که بگوید به چه سؤالی جواب داد.
شواهد اعتبارسنجی: یک مصنوع پژوهش یا تست. خلاصه تست کاربردپذیری با دو نقل‌قول، نتیجه A/B تست، اسکرین‌شات آنالیتیکس که وضعیت قبل را نشان میدهد، یا نسخه‌ای از پروتوتایپ با تغییرات حاشیه‌نویسی‌شده. یک مصنوع، با برچسبی که بگوید چه چیزی را عوض کرد.
شواهد تحویل: طراحی مستقر شده واقعی. نه کامپ نهایی Figma. آدرس مستقر شده، اسکرین‌شات App Store، فلو ضبط‌شده. مطالعههای موردی که کامپهای Figma را نشان می‌دهند و هرگز محصول تحویل‌شده را، شبیه طراحی روی کاغذ خوانده میشوند.
بخش ۵: لاگ تصمیم
این بخشی است که بیشتر طراحان از آن می‌گذرند. بخشی است که مدیران استخدام دوبار می‌خوانند.
لاگ تصمیم فهرست کوتاهی از انتخاب‌های غیربدیهی حین پروژه است، همراه با بده‌بستان و نتیجه. ثابت می‌کند طراح نظراتی داشته که با واقعیت محک خورده‌اند، که تنها و استخدام‌پذیرترین سیگنالی است که یک پورتفولیو می‌تواند داشته باشد.
سه تا پنج مورد. الگوی هر مورد:
- تصمیم: چه چیزی انتخاب شد
- جایگزین: چه چیزی رد شد
- دلیل: محدودیت یا بینشی که انتخاب را پیش برد
- نتیجه: بعد از تحویل چه شد
مثال:
- تصمیم: اشتراک‌گذاری پیش‌فاکتور به صورت لینک عمومی فقط‌خواندنی بازسازی شد، نه فلو بومی ارسال به مالی.
- جایگزین: ارسال رونوشت به مالی داخل محصول با اجبار به ساخت حساب.
- دلیل: تیم‌های خرید و مالی اغلب در سیستم‌های متفاوتی هستند و تیم خرید منتظر فرایند ساخت حساب نمی‌ماند.
- نتیجه: ۷۱٪ پیش‌فاکتورهای سازمانی ظرف ۲۴ ساعت پس از ساخت به اشتراک گذاشته شدند، در برابر ۱۲٪ پیش از بازطراحی.
لاگ‌های تصمیم نزدیک‌ترین چیز یک پورتفولیو به یک مصاحبه کاری واقعیاند. اول آنها را بنویسید، بعد بقیه مطالعه موردی را دورشان بنویسید.
بخش ۶: نتیجه، با عدد
بخش نتیجه حقوق ماهانه مطالعه موردی است. هرچه قبلش بود مقدمه بود. اعداد اینجا باید واقعی، مشخص و قابل انتساب باشند.
سه نوع عدد کار می‌کند.
اعداد کسب‌وکار. درآمد، تبدیل، حفظ مشتری، فعال‌سازی، زمان تا ارزش، CAC، LTV. این‌ها اعدادی‌اند که مدیران استخدام اول می‌خواهند، چون مستقیم به دلیل وجود تیم طراحی مربوط‌اند.
اعداد محصول. تکمیل وظیفه، نرخ خطا، حجم تیکت پشتیبانی، زمان انجام وظیفه، پذیرش ویژگی. این‌ها ثابت میکنند طراحی رفتار کاربر را تغییر داد، که ثابت می‌کند طراحی خوب بود.
اعداد کیفیت. امتیاز ممیزی دسترس‌پذیری، بهبود core web vitals، پذیرش سیستم طراحی، زمان صرفه‌جویی‌شده در هندآف. این‌ها اعداد رده دوم‌اند و وقتی اعداد کسب‌وکار و محصول در دسترس نیستند (NDA، یا خیلی زود برای اندازهگیری) به کار می‌آیند.
یکی از هر دسته کافی است. سه عدد در هر مطالعه موردی از ده عدد بهتر است، چون سه عدد مشخص صادقانه خوانده میشوند و ده عدد پرکننده.
اگر پروژه تحت NDA است، صریح بگویید. اعداد دقیق را با بازههای قابل راستیآزمایی جایگزین کنید («افزایش دورقمی پایین در تبدیل»، «فعال‌سازی دو برابر شد»). جعل نکنید. مدیران استخدام در هر شرکتی دوست دارند و می‌پرسند.
بخش ۷: نقش شما، ساده و روشن
هر مطالعه موردی باید پاسخ روشنی به سؤالی بدهد که مدیر استخدام واقعاً در ذهن دارد: این طراح شخصاً چه کرد.
دو تا سه جمله. وقتی کار انفرادی بود «من» بگویید، وقتی نبود «تیم چهارنفره ما»، و در هر دو حالت سهم مشخص خودتان را فهرست کنید.
خوب:
طراحی تعامل را رهبری کردم و مالک لاگ تصمیم بودم. روی فلو پرداخت با یک مهندس و روی تعیین دامنه با یک PM کار کردم. طراح دیگری در تیم مالک سیستم بصری بود که من آن را به کار بردم اما طراحی نکردم.
مبهم:
فرایند طراحی سرتاسری را رهبری کردم و با شرکای میان‌عملکردی از نزدیک همکاری کردم تا تجربه کاربری دلپذیری تحویل بدهم.
نسخه مبهم پرده دود به نظر می‌رسد. همیشه سؤال‌های مصاحبه بیشتری درمی‌آورد، نه کمتر. نسخه ساده را بنویسید و مصاحبه را برای گفت‌وگویی نگه دارید که واقعاً می‌خواهید داشته باشید.
بخش ۸: بازتاب
یک پاراگراف کوتاه. اگر پروژه را دوباره اجرا می‌کردید چه کار متفاوتی می‌کردید.
این نشانه ارشدیت است. طراحان جونیور کلی‌گویی میکنند («باید زودتر با کاربران بیشتر تکرار می‌کردم»). طراحان ارشد مشخص حرف می‌زنند («زمان یکپارچه‌سازی خرید را چهار هفته دست‌کم گرفتم و باید آن را از روز اول به‌عنوان یک جریان کاری جدا تعریف می‌کردم، نه این که در پروژه پرداخت ادغامش کنم»).
بازتاب بیش از حد مثبت («همه‌چیز عالی بود») پرچم قرمز اعتبار است. بازتاب بیش از حد منفی («شکست خوردم») غیرحرفه‌ای است. بازتاب مشخص و تاکتیکی یعنی کسی که از پروژه یاد گرفته و از پروژه بعدی هم یاد می‌گیرد.
چه چیزی را از بیشتر مطالعههای موردی باید حذف کرد
بیشتر مطالعههای موردی پورتفولیو درازتر از لازم‌اند، و برای همین مدیران استخدام مرورشان میکنند. این‌ها را حذف کنید:
پاراگراف «درباره کارفرما». اگر کارفرما شناخته‌شده است، مدیر استخدام می‌داند. اگر نیست، زمینه‌اش به بیانیه مسئله تعلق دارد، نه یک بلوک جدا.
مود بورد. تقریباً هرگز به تصمیم استخدام ربطی ندارد. مود بوردها را برای فایل‌های کاری داخلی و ارائه‌های کارفرما نگه دارید، جایی که ارزششان را ثابت میکنند.
شبکه ایده‌پردازی واگرا. نه کانسپت در یک صفحه که هشت‌تایش رد شده‌اند، مصنوع کارگاه است نه مصنوع پورتفولیو. جهت نهایی و یک جایگزین که رقیب واقعی بود را نشان بدهید.
ریل کامپهای تحویلنشده. کامپهای زیبای چیزهایی که هرگز تحویل نشدند به مدیر استخدام می‌گویند طراح شاید تحویل ندهد. این سیگنال اشتباه است. همیشه با کار تحویل‌شده شروع کنید.
مقاله سبک شخصی. بخشهای «فلسفه طراحی من» رد میشوند. اگر فلسفه واقعی است، مطالعههای موردی بدون اعلام آن را نشان می‌دهند.
طول مطالعه موردی بر اساس ارشدیت
طول مطالعه موردی با ارشدیت تغییر می‌کند، اما ساختار نه. هشت بخش می‌مانند. عمق درون آنها جابه‌جا می‌شود.
| ارشدیت | مسئله | محدودیتها | فرایند | تصمیمها | نتیجه | نقش | بازتاب | طول کل |
|---|---|---|---|---|---|---|---|---|
| جونیور | ۳ جمله | ۵ بولت | ۳ مصنوع | ۳ تصمیم | ۲ عدد | ۳ جمله | ۳ جمله | ۸۰۰ تا ۱۲۰۰ کلمه |
| میدلول | ۱ پاراگراف | ۶ بولت | ۳ مصنوع | ۴ تصمیم | ۳ عدد | ۳ جمله | ۱ پاراگراف | ۱۲۰۰ تا ۱۸۰۰ کلمه |
| ارشد | ۱ پاراگراف | ۷ بولت | ۳ مصنوع | ۵ تصمیم | ۳ تا ۵ عدد | ۳ جمله | ۱ پاراگراف | ۱۵۰۰ تا ۲۲۰۰ کلمه |
| استف | ۲ پاراگراف | ۷ بولت | ۳ مصنوع | ۵ تصمیم با بده‌بستان‌های سازمانی | ۵ عدد با ذکر منبع | ۳ جمله | ۱ پاراگراف | ۱۸۰۰ تا ۲۵۰۰ کلمه |
هر چیز بیش از ۲۵۰۰ کلمه مطالعه موردی‌ای است که کسی تمامش نمی‌کند. قاعده برای نقش‌های ارشد و استف تراکم است، نه طول. قضاوت بیشتر در هر پاراگراف، نه پاراگراف بیشتر.
چگونه پیش‌نویس اول را بنویسیم
سریع‌ترین راه به یک مطالعه موردی قابل انتشار این است که به این ترتیب بنویسید، که ترتیبی نیست که خواننده می‌بیند.
- اول لاگ تصمیم را بنویسید. سه تا پنج مورد. این سخت‌ترین بخش است و بقیه چیزها حول آن می‌چرخند.
- دوم بخش نتیجه را بنویسید. پیش از نوشتن دور اعداد، خود اعداد را دربیاورید.
- سوم مسئله و محدودیتها را بنویسید. حالا می‌دانید کدام محدودیتها مهم بودند چون می‌دانید کدام تصمیمها را پیش بردند.
- چهارم بخش فرایند را بنویسید. سه مصنوعی که جایشان را حق دارند انتخاب کنید.
- نقش و بازتاب را آخر بنویسید. کوتاه، صادقانه، تمام.
- نتیجه یکخطی بالای صفحه را آخر از همه بازنویسی کنید، بعد از نوشتن همه چیز. آخرین جمله‌ای است که نوشته می‌شود و اولین جمله‌ای که خوانده می‌شود.
این ترتیب تفکر سخت را به ابتدا می‌کشاند. طراحانی که به ترتیب خواندن می‌نویسند معمولاً با نثر قشنگ و محتوای گم‌شده تمام میکنند.
چگونه فرایند را بدون خسته کردن خواننده ارائه کنیم
بخشهای فرایند جایی‌اند که بیشتر پورتفولیوها تا سر حد مرگ مرور میشوند. راه‌حل تراکم است، نه حذف.
یک اسکرین‌شات حاشیه‌نویسی‌شده برای هر مصنوع. نه گالری کل فایل کاری. یک اسکرین‌شات با سه توضیح که بگوید مصنوع به چه جواب داد.
یک ویدیوی پروتوتایپ، حداکثر ۳۰ ثانیه. ضبط خام صفحه را کنار بگذارید. ویدیو را به یک لوپ فشرده از تعامل کلیدی برش بدهید، با برچسب.
همیشه قبل و بعد. هر مقایسه‌ای که «قبل» دارد از مقایسه بدون آن قوی‌تر است. حتی یک اسکچ مدادی کنار محصول تحویل‌شده پیشرفت را نشان میدهد. واژه‌نامه وایرفریم توضیح میدهد چه نوع مصنوعات اولیه وزن دارند.
یک ووکسل، اسکچ یا فریم کم‌دقت به جای یک کامپ صیقلی دیگر. تضاد میان تفکر کم‌دقت و تحویل پر‌دقت ثابت می‌کند طراح مسئله را حل کرده، نه این که تا راه‌حل استایل داده باشد.
اگر تیمی می‌خواهید که پورتفولیوها را ممیزی کند و مطالعههای موردی را با حضور مدیران استخدام بازنویسی کند، Brainy را استخدام کنید. بازبینی پورتفولیو یکی از سریع‌ترین خدمات ما برای طراحان ارشد و استف در جست‌وجوی کار است.
آزمون قبول یا رد مطالعه موردی
هر مطالعه موردی را پیش از انتشار در پورتفولیو از پنج بررسی رد کنید.
آزمون اسکن. آیا خواننده فقط از تیترها و جمله‌های اول می‌تواند مسئله، رویکرد و نتیجه را بگیرد. اگر نه، اسکن‌پذیری خراب است. مقاله طراحی سلسله‌مراتب بصری راه‌حل ساختاری را توضیح میدهد.
آزمون عدد. آیا حداقل دو عدد واقعی در صفحه هست. اگر نه، مطالعه موردی داستانی بدون پانچ‌لاین است.
آزمون نقش. آیا خواننده می‌تواند در کمتر از ۱۰ ثانیه بخواند و جواب «این طراح شخصاً چه کرد» را بدهد. اگر نه، بخش نقش بیش از حد مبهم است.
آزمون تصمیم. آیا مطالعه موردی حداقل سه تصمیم غیربدیهی را با بده‌بستان‌های نامبرده نشان میدهد. اگر نه، طراح مجری به نظر می‌رسد، نه متفکر.
آزمون تحویل. آیا شواهدی هست که کار واقعاً تحویل شده. یک URL، اسکرین‌شات روی دستگاه واقعی، لینک App Store، اسکرین‌شات کد پروداکشن. اگر نه، مطالعه موردی قطعه‌ای حدسی است، نه حرفه‌ای.
پنج بررسی. پنج دقیقه. هر مطالعه موردی، هر بار.
سوالات متداول
یک مطالعه موردی طراحی چقدر باید طولانی باشد؟
بین ۸۰۰ و ۲۵۰۰ کلمه، بسته به ارشدیت. مطالعههای موردی جونیور ۸۰۰ تا ۱۲۰۰ و میدلول ۱۲۰۰ تا ۱۸۰۰ کلمهاند.
ارشد ۱۵۰۰ تا ۲۲۰۰. مطالعههای موردی استف و پرینسیپال اگر تصمیمها و اعداد توجیه کنند میتوانند تا ۲۵۰۰ کش بیایند. بیشتر از آن خواننده را از دست میدهد.
هر مطالعه موردی طراحی باید چه چیزی داشته باشد؟
هشت بخش به ترتیب: نتیجه یکخطی، پاراگراف مسئله، محدودیتها، بخش فرایند فشرده، لاگ تصمیم، نتایج قابل اندازهگیری، بیان ساده نقش شخصی شما و یک بازتاب کوتاه. هر مطالعه موردی به هر هشت بخش نیاز دارد، حتی اگر بعضی فقط دو جمله باشند.
چگونه بدون نقض NDA مطالعه موردی بنویسیم؟
اعداد مشخص را با بازههای قابل راستیآزمایی جایگزین کنید («افزایش دورقمی پایین در تبدیل») و برندهای نامبرده را با صنعت («یک فینتک با بیش از ۱۰۰ مشتری سازمانی»). NDA را در ابتدای مطالعه موردی واضح بگویید. اعداد یا برندها را جعل نکنید. مدیران استخدام بررسی میکنند و مطالعههای موردی جعلی کارنامهها را تمام میکنند.
چگونه فرایند را بدون خسته کردن خواننده نشان بدهیم؟
به سه مصنوع محدود کنید (یکی برای چارچوببندی، یکی برای اعتبارسنجی، یکی برای تحویل). هر مصنوع را با این که به چه جواب داد حاشیهنویسی کنید. ویدیوهای طولانی پروتوتایپ را با برشهای ۳۰ ثانیهای از تعامل کلیدی جایگزین کنید. همیشه مقایسه قبل و بعد بگذارید. در هر بازبینی پورتفولیو، تراکم از حجم برنده است.
بزرگ‌ترین اشتباه طراحان در مطالعههای موردی چیست؟
شروع با مقدمه به جای نتیجه. خط اول مطالعه موردی باید نتیجه پروژه باشد، نه هیجان شروع آن. مدیران استخدام از بالا به پایین اسکن میکنند. اگر نتیجه در صفحه دوم دفن شده باشد، مطالعه موردی همان‌جا باخته است.
اگر هنوز پروژه را تحویل ندادهام چگونه مطالعه موردی بنویسم؟
اول چیزی را تحویل بدهید. مطالعههای موردی تحویلنشده حدسی خوانده میشوند و مدیران استخدام آنها را کمارزش میدانند. اگر پروژه باید پیش از تحویل ظاهر شود، آن را واضح «در حال توسعه» برچسب بزنید و روی لاگ تصمیم و بخشهای پژوهش تمرکز کنید. هرگز کامپهای تحویلنشده را طوری نشان ندهید که انگار واقعیاند.
پورتفولیو یک صفحه فروش است
هر مطالعه موردی صفحه فروش طراحی است که آن را نوشته. محصول، خود طراح است. خریدار، مدیر استخدام. قیمت، یک مصاحبه چهل‌دقیقه‌ای.
صفحه‌های فروش برنده مستقیم، مشخص و صادق‌اند. با نتیجه شروع میکنند، با محدودیتها و تصمیمها ثابتش میکنند، با اعداد پشتیبانی‌اش میکنند و با بیان روشنی از این که فروشنده کیست می‌بندند. صفحه‌های فروش بازنده نتیجه را پشت فرایند پنهان میکنند، داستان را با زمینه پر میکنند و خواننده را درگیر این سؤال می‌گذارند که واقعاً چه خریده.
هشت بخش را بنویسید. حجم اضافی را حذف کنید. مطالعه موردی را منتشر کنید. بعد برای پروژه بعدی و بعدی‌اش دوباره، تا پورتفولیو مجموعه‌ای از شرط‌های تحویل‌شده و سودآور به نظر برسد، نه مجموعه‌ای از سفرهایی که از آنها لذت بردید.
اگر تیمی می‌خواهید که پورتفولیوهایی را ممیزی، بازنویسی و منتشر کند که به مصاحبه تبدیل میشوند، Brainy را استخدام کنید. ما این قالب را روی پورتفولیوهای محصول، برند و UX اجرا کرده‌ایم و ساختار هر بار جواب میدهد.
مطالعه بیشتر
Need a portfolio that lands interviews instead of silence? Brainy runs portfolio audits and rewrites with hiring managers in the loop.
Get Started
