طراح محصول باتجربه کار را از وایرفریم شروع نمیکند.
برای یک طراح، باز کردن فیگما حس شروع کار میدهد. صفحهٔ سفید روبهروست، ابزارها آمادهاند و خیلی زود میتوان چند فریم ساخت. من هم بارها این وسوسه را تجربه کردهام: مسئله هنوز کاملاً روشن نیست، اما چون ساختن چیزی دیدنی احساس پیشرفت میدهد، وارد وایرفریم میشوم.
مشکل اینجاست که حرکت کردن همیشه به معنی جلو رفتن نیست. ممکن است چند ساعت بعد جریان مرتب و صفحههای قابلقبولی داشته باشم، ولی تازه در جلسه بفهمیم مسئلهای که حل کردهام سؤال اصلی تیم نبوده است.
بهنظر من طراح محصول باتجربه لزوماً کسی نیست که سریعتر وایرفریم میکشد؛ کسی است که میداند چه وقت هنوز نباید شروع به کشیدن کند.
چرا زود رفتن سراغ راهحل اینقدر جذاب است؟
راهحل قابلدیدن است. میتوان آن را نشان داد، دربارهاش نظر گرفت و حس کرد پروژه حرکت کرده. در مقابل، تعریف مسئله اغلب شامل سؤال، گفتوگو، خواندن داده و پذیرفتن ابهام است. خروجی این مرحله شاید فقط یک صفحه یادداشت باشد و از بیرون کمتر چشمگیر بهنظر برسد.
فشار زمان هم ما را به ساختن هل میدهد. وقتی جلسهٔ بعد نزدیک است، داشتن چند فریم آرامش بیشتری از گفتن «هنوز باید مسئله را بررسی کنیم» میدهد. ابزارهای AI این سرعت را چند برابر کردهاند؛ حالا حتی لازم نیست خودمان همهٔ فریمها را بسازیم.
اما هرچه تولید راهحل ارزانتر شود، خطر تولید راهحل اشتباه بیشتر میشود. یک نمونهٔ زیبا میتواند تیم را زود به خودش وابسته کند. از آن لحظه بحث بهجای اینکه دربارهٔ نیاز کاربر باشد، دربارهٔ جای دکمه و رنگ کارت میشود.
قبل از وایرفریم، لحظهٔ ارزش را پیدا میکنم
اولین سؤال من این است: کاربر چه لحظهای احساس میکند این محصول برایش مفید بوده؟
در یک ابزار مدیریت کار، شاید ساختن پروژه ارزش اصلی نباشد؛ شاید لحظهای باشد که کاربر میفهمد چه کاری عقب افتاده. در یک فروشگاه، دیدن محصول ارزش نیست؛ اطمینان از مناسب بودن آن برای خرید اهمیت دارد. در یک اپ تمرکز، شروع تایمر ممکن است فقط ابزار باشد و ارزش واقعی، پایان یک جلسهٔ بدون حواسپرتی باشد.
اگر لحظهٔ ارزش را پیدا نکنیم، ممکن است جریان را حول ساختار داخلی محصول بچینیم، نه نتیجهای که کاربر میخواهد.
من سعی میکنم این جمله را کامل کنم:
«کاربر وقتی ارزش را حس میکند که بتواند … بدون اینکه …»
مثلاً: «کاربر وقتی ارزش را حس میکند که بتواند وضعیت پروژه را در چند ثانیه بفهمد، بدون اینکه گزارش پیچیدهای بسازد.» این جمله جهت طراحی را بسیار روشنتر از «یک داشبورد طراحی کنیم» میکند.
مسئله را از درخواست جدا میکنم
خیلی وقتها پروژه با یک درخواست شروع میشود: «یک فیلتر اضافه کنیم»، «onboarding را کوتاه کنیم» یا «صفحه را مدرنتر کنیم». درخواست میتواند مفید باشد، اما لزوماً مسئله نیست.
پشت درخواست فیلتر شاید این مشکل باشد که اطلاعات بهخوبی دستهبندی نشدهاند. پشت onboarding کوتاهتر شاید نبودن ارزش زودهنگام باشد. پشت ظاهر مدرنتر شاید بیاعتمادی کاربر به محتوا یا برند قرار داشته باشد.
برای جدا کردن مسئله از راهحل، چند بار میپرسم:
- چرا این تغییر لازم شده است؟
- چه نشانهای داریم که کاربران با این بخش مشکل دارند؟
- اگر هیچ صفحهٔ جدیدی نسازیم، چه راه دیگری وجود دارد؟
- نتیجهٔ مطلوب چیست، مستقل از شکل راهحل؟
- کدام گروه کاربر بیشتر تحتتأثیر است؟
هدف این سؤالها رد کردن درخواست تیم نیست. میخواهم مطمئن شوم چیزی که میسازیم به دلیل واقعی آن درخواست وصل است.
یک نقشهٔ کوچک قبل از صفحههای بزرگ
بعد از روشن شدن مسئله، مستقیم وارد جزئیات نمیشوم. ابتدا مسیر را در سادهترین شکل مینویسم:
- کاربر از کجا وارد میشود؟
- چه اطلاعاتی در اختیار دارد؟
- چه تصمیمی باید بگیرد؟
- محصول چه بازخوردی میدهد؟
- کاربر از کجا میفهمد کار تمام شده؟
این نقشه میتواند چند جمله یا چند کادر روی کاغذ باشد. مهم این است که منطق قبل از ظاهر دیده شود. اگر مسیر در این سطح کار نکند، اضافه کردن کامپوننت و تصویر آن را نجات نمیدهد.
گاهی همین نقشه نشان میدهد یک صفحه اصلاً لازم نیست. شاید بتوان اطلاعات را در همان زمینهٔ فعلی نمایش داد، بخشی را خودکار کرد یا یک پیام واضح جای چند مرحله را بگیرد.
سؤالهایی که پیش از فیگما جواب میدهم
برای خودم یک چکلیست کوتاه دارم:
- کاربر اصلی این جریان کیست؟
- چه کاری را امروز و با چه روشی انجام میدهد؟
- سختترین یا پرریسکترین لحظه کجاست؟
- محصول از کاربر چه اطلاعاتی میخواهد و چرا؟
- چه چیزی باید خیلی زود دیده یا تجربه شود؟
- محدودیت فنی، زمانی یا محتوایی چیست؟
- موفقیت را با چه رفتار یا نتیجهای میسنجیم؟
- چه فرضی هنوز بدون شواهد است؟
لازم نیست همهٔ پاسخها کامل باشند. مهم این است که ندانستهها واضح باشند. وقتی وارد طراحی میشوم، میدانم کدام بخش تصمیم و کدام بخش فرضیه است.
وایرفریم ابزار فکر کردن است، نه مدرک پیشرفت
وقتی زمان مناسب رسید، وایرفریم همچنان یکی از بهترین ابزارهای من است. میتوانم ترتیب، سلسلهمراتب و مسیر را سریع ببینم. مسئله از جایی شروع میشود که وایرفریم را فقط برای نشان دادن پیشرفت بسازیم یا خیلی زود آن را به راهحل نهایی تبدیل کنیم.
من ترجیح میدهم اولین وایرفریمها عمداً ساده باشند. جزئیات بصری کم کمک میکند تیم دربارهٔ منطق حرف بزند. اگر نمونه بیشازحد تمیز باشد، بازخوردها هم به ظاهر محدود میشوند.
کنار هر نسخه مینویسم این طرح کدام فرض را آزمایش میکند. مثلاً «اگر نمونهٔ آماده را قبل از ساخت حساب نشان دهیم، کاربر ارزش را زودتر میفهمد.» آنوقت تست و بازخورد هدف مشخصی دارند.
قبل از ساختن، گاهی باید چیزی را حذف کنیم
تعریف مسئله فقط به پیدا کردن ویژگی جدید منجر نمیشود. بارها نتیجهٔ خوب این بوده که چیزی حذف یا ساده شود. شاید کاربر به گزینههای کمتر، متن واضحتر یا ترتیب متفاوت نیاز داشته باشد، نه صفحهٔ تازه.
حذف کردن تصمیم سختی است، چون خروجی کمتر دیده میشود. اما محصول خوب با تعداد فریمها سنجیده نمیشود. اگر یک جریان را از پنج مرحله به سه مرحله برسانیم و فهم آن بهتر شود، کار طراحی ارزشمندتری انجام دادهایم.
اگر بخواهم خلاصه کنم
من مخالف وایرفریم نیستم؛ مخالف شروع کردن از جایی هستم که هنوز نمیدانیم چه چیزی را باید حل کنیم. چند ساعت مکث، پرسش و ترسیم مسیر میتواند جلوی چند روز طراحی و اصلاح روی مسئلهٔ اشتباه را بگیرد.
طراح محصول باتجربه قبل از کشیدن صفحه، لحظهٔ ارزش، مسئلهٔ واقعی، محدودیتها و نادانستهها را پیدا میکند. بعد از آن وایرفریم نه یک حدس زیبا، بلکه ابزاری برای آزمودن تصمیم میشود.
اگر بخواهم در یک جمله بگویم: فیگما جایی است که راهحل را شکل میدهیم؛ مسئله باید کمی قبلتر و در گفتوگو با کاربر، تیم و شواهد شکل گرفته باشد.
برای مطالعه بیشتر
- Great Product Designers Don’t Start With Wireframes
- چرا بسیاری از طراحان محصول مسئلهٔ اشتباه را حل میکنند
- گزارش ۲۰۲۶ فیگما دربارهٔ نقش استراتژیکتر طراحی
نوشتهٔ محمد عبدی، طراح محصول و تجربهٔ کاربری.