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

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

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

1. سازمان‌یافته باشید

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

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

در اینجا روش‌هایی برای تمیز و ساده نگه داشتن امور برای تیم توسعه وجود دارد.

از ابزاری مانند Zeplin برای رد کردن طراحی تا توسعه استفاده کنید

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

یک راهنمای استایل دقیق بسازید

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

همه استایل‌های متنی (h1, h2, h3, p, input placeholder, input و غیره).

رنگ‌ها با نام‌ها.

دکمه‌ها در همه حالات (وقتی موس روی آن کلیک نشده، موس روی آن قرار گرفته، زده شده است، غیرفعال است و غیره).

کامپوننت‌ها در همه حالات. این بدان معناست که هر کامپوننت در صورت خطا، خالی بودن و غیره چگونه به نظر برسد.

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

فایل‌های خود را در یک مکان قرار دهید، مانند Google Drive یا Dropbox

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

آن‌ها باید در یک درایو مشترک، به روشی منطقی سازمان‌ یافته باشند، و اسناد را در نام‌های منطقی قرار دهید.

2. اغلب جفت شوید

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

این امر در مورد یک جفت طراح/توسعه‌دهنده نیز صادق است. در زیر چند موقعیت ذکر شده است که توصیه می‌کنیم با یک توسعه‌دهنده جفت شوید.

هنگام طراحی یک موقعیت یا گردش کار جدید، جفت شوید

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

وقتی تیم توسعه یک گردش کار یا انیمیشن را پیاده‌سازی می‌کند، جفت شوید

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

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

همیشه در دسترس بودن

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

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

3. انعطاف‌پذیر باشید

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

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

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

همه هدف مشترکی داریم

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