سایت Portfolio باید به مخاطب نشان دهد چه نوع مسئله‌ای را حل می‌کنید، در پروژه چه نقشی داشتید و چگونه می‌توان با شما همکاری کرد. تعداد ثابت شش تا ده پروژه یا انیمیشن زیاد، معیار عمومی کیفیت نیست. یک پروژه مرتبط با توضیح روشن می‌تواند از چند تصویر بی‌زمینه مفیدتر باشد. متن قبلی بیشتر یک قالب ثابت و شعار کیفیت در برابر کمیت می‌داد. در این راهنما، انتخاب پروژه، نوشتن Case Study، نمایش کار و مسیر تماس را بر اساس مخاطب و شواهد واقعی بررسی می‌کنیم.
مخاطب اصلی را بشناسید
کارفرمای استخدامی، مشتری خدمت و همکار طراحی پرسش‌های یکسانی ندارند. کارفرما ممکن است نقش شما در تیم و توان همکاری را بخواهد. مشتری به تناسب تجربه با نیاز و روش شروع پروژه توجه می‌کند. همکار شاید به تصمیم‌های فنی و فایل‌های قابل استفاده علاقه داشته باشد. یک سایت می‌تواند چند مخاطب داشته باشد، اما مسیر اصلی باید معلوم باشد. معرفی کوتاه باید نوع کار و محدوده تخصص را بگوید و خواننده را به پروژه مرتبط هدایت کند، نه اینکه فقط عنوان کلی «طراح خلاق» بدهد.
اگر در چند حوزه کار می‌کنید، آن‌ها را با نمونه واقعی توضیح دهید. فهرست بلند مهارت‌ها بدون خروجی، ارزیابی را دشوار می‌کند. می‌توانید پروژه‌ها را بر پایه نوع مسئله گروه کنید و مهارت مرتبط را داخل توضیح بیاورید. نام ابزار لازم است، اما جای نقش را نمی‌گیرد. استفاده از Figma نشان نمی‌دهد تحقیق، طراحی تعامل یا تحویل را انجام داده‌اید. مسئولیت خود را دقیق نام ببرید و سهم دیگران را هم حفظ کنید تا مخاطب از نتیجه تیمی برداشت نادرست نکند.
پروژه را بر اساس تناسب انتخاب کنید
پروژه‌ای را جلو بگذارید که به هدف فعلی شما مربوط است. اگر می‌خواهید روی رابط SaaS کار کنید، مطالعه مسیر یک dashboard می‌تواند مرتبط‌تر از یک پوستر خوب باشد. لازم نیست همه کارهای گذشته حاضر باشند. با این حال، کم‌بودن تعداد به تنهایی امتیاز نیست؛ مخاطب باید شواهد کافی برای ارزیابی داشته باشد. تعداد را از تنوع مسئله و عمق توضیح انتخاب کنید. هر پروژه تازه باید نکته‌ای درباره توان شما اضافه کند، نه اینکه فقط صفحه را پر کند.
پروژه تمرینی و مشتری واقعی را جدا معرفی کنید. اگر بازطراحی فرضی یک محصول شناخته‌شده انجام داده‌اید، آن را همکاری رسمی جلوه ندهید. داده ساختگی پژوهش یا نتیجه conversion به نمونه‌کار اعتبار نمی‌دهد. می‌توانید محدودیت تمرین را بنویسید و فرض‌ها را آشکار کنید. این صداقت به مخاطب امکان می‌دهد کیفیت تصمیم را در همان زمینه بسنجد. نتیجه اندازه‌گیری‌شده فقط وقتی قابل گزارش است که روش، بازه و نقش تغییر روشن باشد؛ در غیر این صورت، از توصیف تصمیم و خروجی استفاده کنید.
Case Study با مسئله و نقش شروع شود
ابتدا زمینه، هدف و مسئولیت خود را کوتاه بگویید. خواننده نباید پس از چند تصویر بفهمد پروژه درباره چیست. محدودیت‌های مهم را ثبت کنید: زمان، داده، سیستم موجود یا نیاز پلتفرم. سپس دو یا چند تصمیم مرتبط را توضیح دهید. نمایش تمام صفحه‌های فرایند همیشه لازم نیست. هدف این است که مخاطب بتواند رابطه مشکل، شواهد و انتخاب را ببیند. شرح ابزارهای استفاده‌شده را در جای مناسب بیاورید و اجازه ندهید داستان پروژه به فهرست نرم‌افزار تبدیل شود.
برای تصمیم، گزینه و دلیل را نشان دهید. مثلاً فرم طولانی به گروه‌های منطقی تقسیم شده چون کاربران اطلاعات هر گروه را در زمان متفاوت آماده می‌کردند. اگر این مشاهده واقعی نیست، آن را فرضیه بنامید. تصویر قبل و بعد بدون توضیح می‌تواند جذاب باشد، اما درباره منطق انتخاب اطلاعات کمی می‌دهد. مقاله User Research برای طراحان درباره جمع‌آوری شواهد ادامه مفیدی دارد. تحقیق در نمونه‌کار باید به تصمیم مرتبط وصل شود، نه صرفاً به عنوان مرحله رسمی نمایش داده شود.
نتیجه و محدودیت را با هم بنویسید
اگر پروژه منتشر شده، بگویید کدام بخش اجرا شده و کدام پیشنهاد باقی مانده است. تصویر طرح را با محصول زنده برابر نگیرید. اگر نتیجه کمی ندارید، معیارهای پذیرش و تغییرهای مشخص را توضیح دهید. ممکن است مسیر خطا روشن‌تر شده یا componentهای مشترک ثبت شده باشند؛ این‌ها خروجی قابل توصیف‌اند. از ساختن درصد بهبود برای پایان جذاب Case Study پرهیز کنید. محدودیت صریح کمک می‌کند خواننده بداند نتیجه در چه دامنه‌ای قابل ارزیابی است.
درباره یادگیری، یک نکته مشخص بنویسید. «اهمیت همکاری را فهمیدم» زیادی کلی است. توضیح دهید کدام تصمیم پس از بازخورد تغییر کرد و چرا. لازم نیست همه خطاهای پروژه را روایت کنید، اما یک trade-off مرتبط می‌تواند قضاوت حرفه‌ای را نشان دهد. اگر راه‌حل نهایی به محدودیت سازمان وابسته بود، آن را توضیح دهید. مخاطب می‌خواهد بداند در شرایط واقعی چگونه تصمیم می‌گیرید و صرفاً شکل نهایی را تحسین نکند. روایت باید قابل دنبال‌کردن و متناسب با پیچیدگی کار باشد.
تصویر کار را با توضیح همراه کنید
تصویر باید بخش مورد بحث را نشان دهد. نمایش یک صفحه کوچک داخل موکاپ دور، اگر متن و کنترل‌ها خوانا نیستند، برای ارزیابی رابط فایده کمی دارد. می‌توانید نمای کلی و جزئیات مرتبط را جدا ارائه کنید. فایل حجیم و گالری طولانی بارگذاری را سنگین می‌کنند. مقاله طراحی Mockup درباره ارائه پروژه ادامه دارد. موکاپ باید زمینه بدهد و نباید ضعف دسترسی به خود طراحی را پنهان کند.
برای alt، نقش تصویر در همان متن را در نظر بگیرید. راهنمای تصاویر W3C میان تصویر اطلاعاتی و تزئینی فرق می‌گذارد. اگر screenshot جزئیات تصمیم را حمل می‌کند، توضیح متنی نزدیکش لازم است. متن ریز در تصویر تنها راه دریافت اطلاعات نباشد. برای پروژه‌ای با داده مشتری، اطلاعات شناسایی را حذف یا با اجازه مناسب نمایش دهید. پوشاندن یک نام کوچک کافی نیست اگر شماره، پیام یا مشخصات دیگر هنوز فرد را قابل تشخیص می‌کنند.
مجوز و محرمانگی را حفظ کنید
پیش از نمایش پروژه، شرایط قرارداد و اجازه انتشار را بررسی کنید. اگر بخشی محرمانه است، می‌توانید درباره نوع مسئله و نقش خود در دامنه مجاز توضیح دهید. از بازسازی اطلاعات واقعی مشتری برای دورزدن محدودیت پرهیز کنید. نام برند و لوگو ممکن است همکاری را القا کنند و باید با رابطه واقعی هماهنگ باشند. این مقاله درباره تنظیم قرارداد حقوقی حکم نمی‌دهد؛ اطلاعات نمونه‌کار باید از مجوز و سیاست تأییدشده بیایند. شفافیت دامنه از نمایش ناقص اما گمراه‌کننده بهتر است.
در کار تیمی، اعتبار همکاران را نگه دارید. اگر تحقیق یا پیاده‌سازی را فرد دیگری انجام داده، نقش او را نام ببرید یا در محدوده مجاز توضیح دهید. مسئولیت مشترک را به دستاورد شخصی کامل تبدیل نکنید. این تصمیم به اعتماد حرفه‌ای مربوط است. مخاطب از همکاری موفق هم شواهد ارزشمند می‌گیرد، به شرطی که بداند کدام تصمیم را شما گرفته‌اید. Portfolio قرار نیست شما را به نویسنده همه اجزای پروژه تبدیل کند؛ باید سهم واقعی و قابل تکرار شما را نشان دهد.
خود سایت مسیر ساده داشته باشد
معرفی، پروژه‌های منتخب و راه تماس باید قابل یافتن باشند. ناوبری عجیب یا cursor سفارشی نباید مسیر خواندن را سخت کند. راهنمای ساختار صفحه W3C درباره heading و جهت‌یابی کمک می‌کند. حرکت اگر معنی یا هویت اضافه می‌کند می‌تواند کاربرد داشته باشد، اما کاربر باید در حالت Reduced Motion هم اطلاعات را دریافت کند. پروژه‌ها نباید فقط پس از یک تعامل دشوار ظاهر شوند. سایت نمونه‌کار خودش بخشی از شاهد کیفیت استفاده است.
نسخه تلفن را با محتوای واقعی طراحی کنید. screenshot عریض ممکن است در تلفن خوانا نباشد و به جزئیات جدا نیاز داشته باشد. عنوان‌ها نباید بی‌دلیل قطع شوند. فرم تماس هم باید label، خطا و نتیجه روشن داشته باشد؛ مقاله طراحی فرم وب ادامه این بخش است. ایمیل یا راه ارتباط تأییدشده را به شکل قابل کپی و قابل فهم بدهید. مخاطب نباید برای رسیدن به شما چند صفحه نامرتبط را طی کند.
مسیر همکاری را دقیق معرفی کنید
اگر مشتری خدمت مخاطب شماست، نوع پروژه‌ای که می‌پذیرید و اطلاعات لازم برای شروع را بنویسید. وعده زمان یا قیمت فقط وقتی بیاید که بتوانید به آن عمل کنید. اگر دنبال استخدام هستید، وضعیت و راه تماس را متناسب توضیح دهید. اطلاعات زندگی شخصی فقط در حدی لازم است که به شناخت حرفه‌ای یا صدای شما کمک کند. مقاله Personal Branding برای طراحان درباره این هماهنگی ادامه دارد. معرفی نباید به متن عمومی قابل استفاده برای هر طراح تبدیل شود.
برای به‌روزرسانی، یک پروژه مرتبط را انتخاب و Case Study آن را کامل کنید. مسئله، نقش، دو تصمیم و نتیجه با محدودیت را بنویسید؛ سپس تصویرها و لینک‌ها را با همان روایت تطبیق دهید. پروژه‌های قدیمی را بر اساس تناسب فعلی بازبینی کنید و اطلاعات تماس را نگه دارید. این روال از افزودن دائمی کارت‌های تازه بدون توضیح مفیدتر است. Portfolio قابل استفاده شواهد واقعی را در مسیر روشن می‌گذارد تا مخاطب بتواند درباره همکاری تصمیم بگیرد و بداند قدم بعدی چیست.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!