طراحی خبره: 3 برابر سریعتر زمان ورود به بازار.

راه اندازی یک محصول جدید می تواند سخت تر از ساختن آن باشد. من ممکن است یک ایده تجاری واضح داشته باشم، اما تبدیل آن ایده به یک وب سایت، برنامه یا رابط محصول مفید بیش از تصاویر جذاب نیاز دارد. کاربران باید پیشنهاد را درک کنند، اطلاعات مناسب را بیابند و بدانند که در مرحله بعد چه کاری انجام دهند. وقتی طراحی نامشخص باشد، توسعه کند می شود و مدیریت بازخورد دشوار می شود. طراحی خبره به ایجاد یک مسیر عملی از مفهوم تا راه اندازی کمک می کند. ### با یک جهت محصول واضح شروع کنید. من با نگاه کردن به هدف محصول، کاربران هدف و نیازهای اصلی کسب و کار شروع می کنم. یک فرآیند طراحی مفید به سوالاتی از قبیل: - چه کسی از محصول استفاده خواهد کرد؟ - چه مشکلی را حل می کند؟ - کاربران باید چه اقدامی انجام دهند؟ - کاربران قبل از تصمیم گیری به چه اطلاعاتی نیاز دارند؟ - چه ویژگی هایی برای نسخه اول مورد نیاز است؟ این مرحله پروژه را متمرکز نگه می دارد. همچنین خطر صرف زمان برای ویژگی هایی که از سفر اصلی کاربر پشتیبانی نمی کنند را کاهش می دهد. ### ایده‌ها را به جریان‌های کاربر ساده تبدیل کنید یک جریان کاربر نشان می‌دهد که مردم چگونه در محصول حرکت می‌کنند. برای یک پلتفرم رزرو، مسیر ممکن است شامل موارد زیر باشد: 1. یافتن یک سرویس 2. بررسی زمان های موجود 3. بررسی قیمت 4. وارد کردن جزئیات تماس 5. تأیید رزرو. این باعث می شود شکاف ها راحت تر شناسایی شوند. اگر پیام خطای گم شده، دکمه نامشخص یا فرم طولانی در نظر گرفته نشود، می‌تواند بعداً مشکلاتی ایجاد کند. ### یک سیستم طراحی ایجاد کنید که از توسعه پشتیبانی کند یک سیستم طراحی یک ساختار بصری و عملکردی سازگار به محصول می دهد. ممکن است شامل موارد زیر باشد: - انتخاب رنگ و نوع - سبک دکمه‌ها - فیلدهای فرم - الگوهای پیمایش - قوانین فاصله‌گذاری - طرح‌بندی موبایل - حالت‌های خالی، بارگیری و خطا وقتی این عناصر زودتر تعریف شوند، طراحان و توسعه‌دهندگان می‌توانند از همان مرجع کار کنند. همچنین ایجاد صفحه نمایش های جدید بدون تغییر ظاهر محصول در هر بار آسان تر می شود. ### طراحی برای اندازه های مختلف صفحه نمایش محصولی که در یک نمایشگر بزرگ خوب به نظر می رسد ممکن است برای استفاده در تلفن سخت باشد. من بررسی می‌کنم که چیدمان‌ها چگونه در اندازه‌های معمول صفحه نمایش پاسخ می‌دهند. ناوبری، متن، فرم ها و اهداف لمسی برای استفاده راحت نیاز به فضای کافی دارند. یک کاربر تلفن همراه ممکن است وضعیت تحویل را با یک دست بررسی کند، در حالی که یک کاربر دسکتاپ ممکن است چندین جزئیات را همزمان با هم مقایسه کند. طراحی باید از هر دو موقعیت پشتیبانی کند. ### استفاده از نمونه های اولیه قبل از توسعه یک نمونه اولیه قابل کلیک راهی را به تیم می دهد تا تجربه اصلی را قبل از نوشتن کد آزمایش کند. این کمک می کند تا به سوالات عملی پاسخ دهید: - آیا کاربران می توانند مرحله بعدی را پیدا کنند؟ - آیا آنها هدف صفحه را درک می کنند؟ - آیا تکمیل فرم آسان است؟ - آیا محتوا به سوالات رایج پاسخ می دهد؟ - کاربران کجا تردید دارند؟ به عنوان مثال، یک تیم کوچک SaaS ممکن است در طول آزمایش نمونه اولیه متوجه شود که کاربران تفاوت بین دو گزینه اشتراک را درک نمی کنند. یک جدول مقایسه کوتاه می تواند مشکل را قبل از اینکه محصول به توسعه برسد حل کند. ### بازخورد را متمرکز نگه دارید بازخورد طراحی زمانی که به هدف کاربر متصل باشد بهتر عمل می کند. به جای اینکه بپرسم آیا صفحه نمایش "خوب به نظر می رسد"، می پرسم: - آیا این صفحه پیشنهاد را توضیح می دهد؟ - آیا کاربران می توانند کار را بدون کمک انجام دهند؟ - آیا اکشن اصلی به راحتی پیدا می شود؟ - آیا چیدمان با اولویت محصول مطابقت دارد؟ سوالات روشن منجر به تصمیمات واضح تر می شود. آنها همچنین به جلوگیری از ترجیحات شخصی پروژه کمک می کنند. ### یک انتقال روان آماده کنید یک انتقال قوی به توسعه دهندگان جزئیاتی را می دهد که باید با سوالات کمتری بسازند. فایل‌های طراحی سازمان‌یافته، حالت‌های صفحه، یادداشت‌های پاسخگو، جزئیات اجزا و راهنمایی محتوا را ارائه می‌دهم. همچنین در طول توسعه در دسترس می‌مانم تا صفحه‌های کلیدی را بررسی کنم و هنگامی که محدودیت‌های فنی بر چیدمان اصلی تأثیر می‌گذارد، جزئیات را تنظیم کنم. راه اندازی سریعتر به معنای نادیده گرفتن برنامه ریزی نیست. این بدان معناست که تصمیمات مفیدی را زود بگیرید، تجربه اصلی را آزمایش کنید و به هر یک از اعضای تیم اطلاعات واضحی بدهید. وقتی طراحی از هدف محصول پشتیبانی می‌کند، توسعه جهت قوی‌تری دارد، کاربران تجربه واضح‌تری کسب می‌کنند و مسیر ایده تا راه‌اندازی آسان‌تر می‌شود.

بسیاری از تیم‌ها ماه‌ها وقت صرف می‌کنند تا یک محصول را از ایده به راه‌اندازی عرضه کنند. تاخیر اغلب خیلی قبل از شروع توسعه شروع می شود. خلاصه مبهم سؤالات مکرر ایجاد می کند. لایه‌های تأیید بیش از حد، تصمیم‌گیری را کند می‌کند. لیست ویژگی های بزرگ تیم را در چندین اولویت پخش می کند. تا زمانی که محصول به دست کاربران برسد، ممکن است بازار تغییر کرده باشد. من از یک مدل تحویل ساده استفاده می‌کنم تا به تیم‌ها کمک کنم تا زمان کوتاه‌تری را برای رسیدن به بازار هدف‌گذاری کنند – گاهی اوقات تا سه برابر سریع‌تر، بسته به محدوده محصول، اندازه تیم و سرعت تصمیم‌گیری. هدف عجله در توسعه نیست. هدف حذف کارهای قابل اجتناب است. ### با یک مشکل واضح مشتری شروع کنید من با مشکلی که محصول باید حل کند شروع می کنم. یک خلاصه مفید باید پاسخ دهد: - چه کسی مشکل دارد؟ - چه چیزی مشکل امروز را دشوار می کند؟ - محصول باید در تکمیل چه اقدامی به کاربر کمک کند؟ - چگونه تیم متوجه می شود که نسخه اول مفید است؟ برای مثال، یک شرکت کوچک SaaS ممکن است بخواهد داشبوردی با گزارش‌ها، هشدارها، نقش‌های تیمی، صادرات و چندین ادغام بسازد. تکمیل این لیست ممکن است ماه ها طول بکشد. ممکن است مشتری در ابتدا فقط به یک چیز نیاز داشته باشد: یک راه ساده برای تشخیص فرصت های فروش از دست رفته. این اولین هدف انتشار می شود. ویژگی های اضافی می توانند منتظر بمانند تا بازخورد کاربر نشان دهد که به آنها نیاز است. ### ایده را به یک نسخه اول متمرکز تبدیل کنید من الزامات محصول را به سه گروه تقسیم می‌کنم: برای اولین سفر کاربر لازم است عملکردهایی که کاربران برای تکمیل کار اصلی نیاز دارند. ** پس از بازخورد اولیه مفید است ** ویژگی هایی که ممکن است تجربه را بهبود بخشد اما برای آزمایش ایده لازم نیست. به هدف فعلی متصل نیست درخواست هایی که می توانند بدون کمک به یادگیری تیم زمان را صرف کنند. این ساختار به طراحان، توسعه دهندگان و مدیران نقطه مرجع یکسانی می دهد. همچنین تغییرات دامنه در طول تولید را کاهش می دهد. اولین نسخه کوتاه به طور پیش فرض یک محصول ناتمام نیست. این یک روش کنترل شده برای آزمایش اینکه آیا محصول یک مشکل معنی دار را حل می کند یا خیر است. ### حذف انتظار از گردش کار زمان توسعه تنها بخشی از چرخه تحویل است. انتظار اغلب بیشتر طول می کشد. یک کار ممکن است در زمانی که تیم منتظر است منتظر بماند: - تصمیمات محصول - تایید طراحی - شفاف سازی فنی - محتوا - داده های آزمایشی - دسترسی به یک سرویس شخص ثالث من این تاخیر را با اختصاص یک مالک تصمیم برای هر منطقه کاهش می دهم. مالک لازم نیست هر تصمیمی را به تنهایی بگیرد، اما تیم باید بداند چه کسی می تواند پاسخ روشنی بدهد. هیئت مدیره پروژه مشترک نیز کمک می کند. هر کار به یک مالک، یک نتیجه روشن و یک اقدام بعدی نیاز دارد. «کار روی داشبورد» خیلی گسترده است. «نمایش فروش ماهانه با حساب و اجازه صادرات CSV» به تیم چیزی می‌دهد که می‌توانند بسازند و آزمایش کنند. ### ایجاد در چرخه های تحویل کوتاه چرخه های توسعه طولانی خطر را پنهان می کند. من چرخه های کوتاهی را ترجیح می دهم که نتیجه قابل استفاده تولید می کند. این تیم می تواند قبل از حرکت به قسمت بعدی، یک قسمت از محصول را طراحی، بسازد، آزمایش و بررسی کند. یک چرخه عملی ممکن است به این صورت باشد: 1. یک وظیفه مشتری را تعریف کنید. 2. معیارهای پذیرش را تایید کنید. 3. کوچکترین جریان قابل اجرا را طراحی کنید. 4. تابع را بسازید. 5. آن را با کاربران نمونه یا داوران داخلی تست کنید. 6. مسائل را ثبت کنید و تصمیم بگیرید که چه تغییراتی در چرخه بعدی تعلق دارند. چرخه‌های کوتاه مشکلات را قابل مشاهده می‌کنند در حالی که رفع آنها آسان‌تر است. ### از اتوماسیون در جایی استفاده کنید که کارهای مکرر را حذف می کند. تیم‌ها ممکن است از بررسی‌های خودکار برای موارد زیر استفاده کنند: - کیفیت کد - اعتبارسنجی فرم - پاسخ‌های API - سازگاری مرورگر - مراحل استقرار - تست رگرسیون اتوماسیون جایگزین قضاوت محصول یا آزمایش کاربر نمی‌شود. این به تیم زمان بیشتری برای تمرکز بر تصمیماتی می دهد که به تجربه و زمینه نیاز دارند. ### پیشرفت را با یادگیری بررسی کنید، نه با فعالیت یک تیم پرمشغله همچنان می تواند به آرامی حرکت کند. من پیشرفت را از طریق نتایج مفید اندازه گیری می کنم: - آیا کاربر هدف می تواند کار اصلی را انجام دهد؟ - کدام قسمت از جریان باعث سردرگمی می شود؟ - کدام فرض تایید شده است؟ - کدام ویژگی را می توان حذف یا به تعویق انداخت؟ - چه تصمیمی مانع کار بعدی می شود؟ تعداد ویژگی ها ممکن است چشمگیر به نظر برسد، اما یک گردش کار آزمایش شده مشتری شواهد قوی تری نشان می دهد که محصول آماده حرکت به جلو است. ### یک مثال عملی یک تیم نرم افزاری B2B یک راه اندازی شش ماهه با لیست ویژگی های بزرگ را برنامه ریزی می کند. پس از بررسی سفر مشتری، تیم راه‌اندازی حساب، واردات داده، یک گزارش اصلی و یک کانال بازخورد ساده را حفظ می‌کند. تیم یک مالک محصول را تعیین می کند، داده های آزمایشی را قبل از شروع توسعه آماده می کند و هر هفته پیشرفت را بررسی می کند. گزارش‌ها، مجوزهای پیشرفته و ادغام‌های اضافی به چرخه بعدی منتقل می‌شوند. طرح راه اندازی کوچکتر می شود و مدیریت آن آسان تر می شود. تیم بررسی های کیفیت را حذف نمی کند. کارهایی را که از اولین نتیجه مشتری پشتیبانی نمی کنند حذف می کند. این مسیر اصلی برای رسیدن به زمان کوتاه‌تر است: کمتر تعریف کنید، سریع‌تر تصمیم بگیرید، زودتر آزمایش کنید و اجازه دهید شواهد نسخه بعدی را راهنمایی کنند. هدف سه برابر سریعتر باید به عنوان یک هدف برنامه ریزی تلقی شود، نه یک وعده. نتایج به محصول، تیم، ابزار و فرآیند تایید بستگی دارد. زمانی که این عوامل از همان ابتدا مورد توجه قرار گیرند، تیم ها می توانند مسیر روشن تری را از ایده تا استفاده مشتری ایجاد کنند.

بسیاری از تیم ها قبل از شروع کار واقعی زمان خود را از دست می دهند. درخواست از طریق ایمیل، چت، پوشه‌های مشترک و بررسی تماس‌ها منتقل می‌شود. فایل ها قدیمی می شوند تغییرات کوچک دورهای جدیدی از تایید را ایجاد می کند. زمانی که تیم آماده تحویل است، ضرب الاجل نزدیکتر شده و بودجه فضای کمتری دارد. من این الگو را اغلب در طراحی و کار محصول می بینم. مشکل به ندرت کمبود استعداد است. جریان کار دارای اصطکاک بیش از حد است. یک فرآیند هوشمندتر می‌تواند به تیم‌ها کمک کند تا با حفظ کیفیت، سریع‌تر حرکت کنند. یک هدف تحویل 3 برابر سریعتر ممکن است برای برخی از پروژه ها امکان پذیر باشد، اما این بستگی به محدوده، اندازه تیم، سرعت بازخورد و ابزارهایی دارد که از قبل استفاده می شود. باید به عنوان یک هدف پروژه تلقی شود، نه یک نتیجه تضمین شده. ## با یک خلاصه واضح شروع کنید من هر پروژه را با یک خلاصه کوتاه شروع می کنم که به پنج سوال پاسخ می دهد: - ما چه چیزی را ایجاد می کنیم؟ - چه کسی از آن استفاده خواهد کرد؟ - چه مشکلی را باید حل کند؟ - چه چیزی باید تحویل داده شود؟ - تیم چگونه کار را بررسی خواهد کرد؟ یک خلاصه واضح از تبدیل شدن تصمیمات طراحی به اولویت شخصی جلوگیری می کند. هنگامی که ایده های جدید ظاهر می شوند، به تیم یک نقطه مرجع مشترک می دهد. برای مثال، خلاصه صفحه فرود ممکن است مشتری هدف، اقدام اصلی، بخش‌های مورد نیاز، قوانین برند و تاریخ راه‌اندازی را تعریف کند. این مفیدتر از پیامی است که می گوید: "لطفاً صفحه را تازه کنید." ## درخواست های مبهم را به وظایف قابل مشاهده تبدیل کنید درخواست های بزرگ اغلب بسیاری از وظایف کوچکتر را پنهان می کنند. من آنها را به یک نقشه تحویل ساده تقسیم می کنم: 1. مواد اولیه را جمع آوری کنید 2. صفحه یا ساختار محصول را تأیید کنید 3. اولین جهت طراحی را ایجاد کنید 4. مسیر را مرور کنید 5. نسخه تایید شده را بسازید. نتیجه را آزمایش کنید. وقتی مالکیت نامشخص است، کار در فضای بین تیم ها منتظر می ماند. هیئت مدیره پروژه می تواند نشان دهد که چه چیزی آماده است، چه چیزی نیاز به بررسی دارد و چه چیزی مسدود شده است. ابزار لازم نیست پیچیده باشد. یک جدول مشترک می تواند کار کند اگر همه آن را به طور مداوم به روز کنند. ## قبل از صیقل دادن جزئیات، جهت را مرور کنید یک تاخیر معمول زمانی شروع می‌شود که یک تیم ساعت‌ها را صرف تنظیم رنگ‌ها، نمادها و فاصله قبل از توافق بر روی طرح‌بندی اصلی می‌کند. من ترجیح می دهم یک بررسی زودهنگام جهت را انتخاب کنم. در این مرحله روی مسیر کاربر، ترتیب محتوا، ساختار صفحه و پیام کلید تمرکز می کنم. طراحی می تواند خشن باقی بماند. هدف یافتن مشکلات بزرگ در حالی است که تغییرات هنوز آسان است. یک تیم کوچک تجارت الکترونیک ممکن است قبل از ساختن صفحه کامل، دو طرح بندی صفحه محصول را با پنج کاربر آزمایش کند. اگر کاربران نتوانند جزئیات حمل و نقل را بیابند یا انتخاب محصول را درک کنند، تیم می‌تواند ساختار را بدون تغییر مجدد کل رابط تعمیر کند. این رویکرد باعث صرفه جویی در تلاش می شود زیرا تصمیمات اصلی را به شروع پروژه نزدیکتر می کند. ## یک قانون بازخورد تنظیم کنید وقتی افراد نظرات پراکنده را از طریق کانال‌های مختلف ارسال می‌کنند، بازخورد کند می‌شود. من از یک فضای بررسی و یک مهلت برای هر دور بررسی استفاده می کنم. نظرات باید به قسمت خاصی از کار اشاره کنند و دلیل تغییر را توضیح دهند. "آن را بهتر کن" به یک طراح کمک نمی کند تا عمل کند. «قیمت را به نام محصول نزدیک‌تر کنید زیرا کاربران آن را در تلفن همراه از دست می‌دهند» به تیم وظیفه روشنی می‌دهد. یک قانون بازبینی می‌تواند شامل موارد زیر باشد: - یک نفر بازخورد را جمع‌آوری می‌کند - نظرات در یک مکان باقی می‌مانند - هر دور یک هدف ثابت دارد - بخش‌های تایید شده بدون دلیل واضح بازگشایی نمی‌شوند - درخواست‌های جدید به‌عنوان یک کار جداگانه ثبت می‌شوند. این امر تمرکز تیم را بدون مسدود کردن ورودی مفید حفظ می‌کند. ## ساخت قطعات قابل استفاده مجدد من هر پروژه را از یک صفحه خالی شروع نمی کنم. دکمه‌های قابل استفاده مجدد، فیلدهای فرم، کارت‌ها، قوانین فاصله‌گذاری و الگوهای محتوا کار تکراری را کاهش می‌دهند. یک کتابخانه کامپوننت مشترک نیز به ثابت نگه داشتن محصول کمک می کند. وقتی یک دکمه تغییر می کند، تیم می تواند به جای جستجو در هر صفحه، مؤلفه تأیید شده را به روز کند. کتابخانه باید با پروژه مطابقت داشته باشد. بسیاری از اجزای استفاده نشده کار تعمیر و نگهداری خود را ایجاد می کنند. من مجموعه را کوچک نگه می‌دارم، نام هر قسمت را به وضوح ذکر می‌کنم و مثال‌هایی اضافه می‌کنم که نشان می‌دهد چه زمانی باید از آن استفاده کرد. ## سرعت تحویل را با دقت اندازه گیری کنید فرآیند سریعتر به چیزی بیش از یک ادعای جسورانه نیاز دارد. من چند عدد عملی را دنبال می‌کنم: - زمان از تأیید کوتاه تا اولین جهت - تعداد دورهای بازبینی - زمان صرف شده برای بازخورد - تعداد تغییرات پس از تأیید - زمان از تأیید نهایی تا تحویل این اعداد نشان می‌دهند که در کجا کار کند می‌شود. یک تیم ممکن است متوجه شود که طراحی خود سه روز طول می کشد، در حالی که انتظار برای محتوا هشت روز طول می کشد. اضافه کردن طراحان بیشتر این مشکل را حل نمی کند. مهلت محتوا و صاحب محتوای اختصاص داده شده تأثیر بیشتری خواهد داشت. به همین دلیل است که یک پیام «3 برابر سریعتر» باید در برابر یک خط پایه واضح آزمایش شود. پروژه های مشابه را با محدوده مشابه مقایسه کنید. آنچه تغییر کرده را ثبت کنید. ادعا را محدود به شرایطی نگه دارید که آن را پشتیبانی می کند. ## محافظت از کیفیت در هنگام تحویل سریعتر، اگر خطاها، فایل‌های نامشخص یا تجربه کاربری ضعیفی ایجاد کند، سرعت ارزش کمی دارد. من یک بررسی کوتاه کیفیت قبل از انتقال انجام می دهم: - آیا طراحی روی اندازه های صفحه نمایش مورد نیاز کار می کند؟ - آیا یافتن اقدامات کلیدی آسان است؟ - آیا سبک های متن و فاصله با هم سازگار هستند؟ - آیا پیوندها، فرم ها و وضعیت ها تحت پوشش قرار می گیرند؟ - آیا نام فایل ها و نسخه ها مشخص است؟ - آیا از محتوای تایید شده استفاده شده است؟ یک بررسی ده دقیقه ای می تواند از چرخه اصلاح طولانی پس از زایمان جلوگیری کند. بهترین گردش کار آن چیزی نیست که باعث عجله افراد شود. این چیزی است که انتظار قابل اجتناب، تصمیمات مکرر و مالکیت نامشخص را حذف می کند. هنگامی که من یک بررسی مختصر و اولیه واضح، بازخورد متمرکز، اجزای قابل استفاده مجدد و ردیابی ساده را به هم وصل می کنم، تیم کنترل بیشتری بر تحویل به دست می آورد. برخی از پروژه ها ممکن است به 3 برابر بهبود سرعت برسند. ممکن است دیگران سود کمتری ببینند. هر دو نتیجه زمانی مفید هستند که درک و بهبود فرآیند آسان‌تر شود. با ما در گریس تماس بگیرید: jialilong_grace@jialilong.com/WhatsApp +8613506667735.

1. Don Norman 2013 The Design of Everyday Things Revised and Expanded Edition 2. Eric Ries 2011 The Lean Startup 3. Marty Cagan 2017 Inspired How to Create Tech Products Tech Customers Love 4. Steve Krug 2014 Don't Me Think Web SenabilityskeApp. Zeratsky and Braden Kowitz 2016 Sprint چگونه مشکلات بزرگ را حل کنیم و ایده های جدید را فقط در پنج روز آزمایش کنیم.