آنچه لازم است درباره‌ی فرایند طراحی اپلیکیشن بدانید

آیا طراحی بصری نقطه‌ی آغاز تولید یک اپلیکیشن است؟

نویسنده: مایکل فلارپ

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

مترجم: محمدرضا گیوه

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

ایده

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

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

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

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

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

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

– آیا می‌توان این کار را به شکلی ساده‌تر یا متفاوت انجام داد؟ آیا راه‌های دیگری برای رسیدن به هدف موردنظر وجود دارد؟ یا می‌توان راه‌های دیگری را متصور شد که پیمودن آن‌ها زمان کمتری بطلبد و بهینه‌تر باشد؟

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

طرح جزئی

طرح جزئی یا جزئیات شامل یک یا چند برگ توضیحات راجع به ویژگی‌ها و روش‌های ساختن اپلیکیشن موردنظر است. طرح جزئی به‌عبارتی یک برنامه‌ی راه است. روش‌های متنوعی برای تدوین یک طرح جزئی وجود دارد؛ از طرح سبک (یا مختصر) گرفته تا طرحی که تمامی جزئیات را پوشش دهد. مهم نیست کدام روش را انتخاب می‌کنید؛ اما حتماً یک طرح جزئی تهیه کنید.

توسعه، تغییر و بهبودِ یک ایده‌ی اولیه در فرایند مکتوب‌شدن، شما را متعجب خواهد کرد. در این فرایند ابهامات آشکار شده و سؤالات جدیدی رخ می‌نمایند. تدوین طرح جزئی را می‌توان به‎عبارتی اولین قدم آگاهانه و حساب‌شده در مسیر «طراحی» دانست. بسیاری از ایده‌های اولیه در چنین سندی توضیح داده شده و بازنموده می‌شوند که همین امر موجب می‌شود همه‌ی افراد گروه از چیستی کار باخبر شده و با یکدیگر هماهنگ شوند. این طرح همچنین برای انجام بازنگری‌های مقطعی در مراحل مختلف پیش‌ روی کار مفید واقع خواهد شد. برنامه‌هایی مانند Pages و Word یا هر برنامه‌ی مشابه دیگری برای این مرحله مناسب خواهند بود. مسئله‌ی اصلی این است که به‌درستی تصمیم بگیرید چه چیز را در طرح جزئی بیاورید و چه چیزی را کنار بگذارید. بهترین روش آن است که این طرح را تا جای ممکن مختصر و مفید تدوین کنید؛ زیرا هرچه بیشتر بنویسید، امکان سوء‌برداشت نیز بیشتر می‌شود. نیازمندهای کارکردی و غیرکارکردی را فهرست کنید. توضیح دهید که اپلیکیشن شما چیست و چطور ساخته می‌شود. از زبان ساده و روان استفاده کنید. و در نهایت بهترین طرح جزئی آن طرحی است که موردقبول همه‌ی طرفین قرار گیرد.

نمونه

نمونه‌ها یا ماکت‌های کلی می‌توانند خود بخشی از طرح جزئی یا چیزی برآمده از آن باشند. معماران اطلاعات (iA’s) یا طراحان تجربه‌ی کاربری (UX designers) معمولاً پیشبرد این مرحله را بر عهده می‌گیرند؛ اما مسئله‌ی مهم این است که همه‌ی افراد گروه از مراحل مختلف انجام کار، شیوه‌ی ساخته‌شدن محصول نهایی و طرح کلی اپلیکیشن آگاهی داشته باشند. اگر به‌تنهایی مشغول طراحی محصول هستید، احتمالاً این مرحله را هم باید خودتان به‌تنهایی پیش ببرید.

نسخه‌ی اولیه

قدم بعدی می‌تواند به شکل‌های مختلفی صورت بگیرد. در واقع می‌توان گفت هر سه مرحله‌ی بعدی درهم‌آمیخته هستند و درکنار یکدیگر معنی می‌گیرند. ما در این مرحله با در دست داشتن طرح جزئی و نمونه، به جایی رسیده‌ایم که بتوانیم یک نسخه‌ی اولیه از محصول نهایی را آماده کنیم. عبارت نسخه‌ی اولیه در این زمینه می‌تواند معانی مختلفی را شامل شود؛ اما نهایتاً به‌معنای ساختن اسکلت و نسخه‌ی آزمایشی اپلیکیشن برای سنجش فرضیات و گرفتن بازخورد از محصول ساخته‌شده است. برخی از نرم افزارهای Invision یا Marvel استفاده می‌کنند تا ماکت‌های کلی خود را به اپلیکیشن‌های تعاملی تبدیل کنند. این امر می‌تواند نقش مؤثری در پیشرفت طرح داشته باشد؛ اما اغلب طراحان به‌سراغ نسخه‌های اولیه‌ای می‌روند که به‌صورت آماده در Swift موجودند. هر رویکرد مزایا و معایب خاص خودش را دارد. تیم‌های بزرگ‌تری که روی اپلیکیشن‌های پیچیده‌تر کار می‌کنند، می‌توانند از این مرحله به‌مثابه‌ی یک میانجی برای اصلاحات رفت‌وبرگشتی و به اشتراک گذاشتن تجربیات حاصل از آن استفاده کنند. اما گروه‌های کوچک‌تری که طرح جزئی خوبی هم دارند، می‌توانند مستقیماً به‌سراغ برنامه‌نویسی برای محصول نهایی بروند تا در زمان کوتاه‌تری به نتیجه برسند. این گروه‌ها معمولاً با مشکلات اجرایی مهمی هم مواجه می‌شوند؛ زیرا از ابتدا و بدون میانجی وارد فرایند برنامه‌نویسی محصول نهایی شده‌اند. چگونگی ساختن نسخه‌ی اولیه بستگی به عوامل متعددی دارد. مهم‌ترین چیز در این مرحله این است که ایده‌ی شما بار دیگر ارزیابی می‌شود. دچار اختلال شدن نسخه‌ی اولیه می‌تواند به اصلاحاتی در نمونه، طرح جزئی یا حتی خود ایده بیانجامد. بنابراین می‌توانید پیش از صرف زمان و هزینه برای پیش‌بردن مراحل بعدی، اطمینان حاصل کنید که بعداً مجبور به ایجاد تغییرات اساسی در موارد مذکور و نتیجتاً صرف زمان و هزینه‌ی اضافه نشوید.

طراحی بصری

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

توسعه

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

بازاندیشی کنید

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

1- ایده

2- مکتوب‌کردن آن

3- ساختن نسخه‌ی اولیه

4- رفت‌وبرگشت میان طراحی و توسعه تا آنجا که محصول از این میان متولد شود

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

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