تعریف persona و problem statement
شناسایی کاربر هدف و نیاز اصلی.
قدم اول: جمعآوری insight از research
قبل از ساخت persona، به داده واقعی یا نیمهواقعی نیاز دارید. در پروژههای حرفهای، معمولاً ۵ تا ۸ مصاحبه نیمهساختاریافته با کاربران هدف انجام میشود؛ هر مصاحبه ۳۰ تا ۴۵ دقیقه و با سؤالات باز که رفتار واقعی را بیرون میکشد. اگر به مصاحبه زنده دسترسی ندارید، برای تمرین Nova Lab میتوانید از desk research، بررسی نظرات کاربران در انجمنها، و ۳ تا ۴ پروفایل فرضی اما منطقی استفاده کنید و یک proto-persona بسازید — با این شرط که بعداً آن را با research واقعی validate کنید.
سؤالات خوب مصاحبه روی «آخرین بار» متمرکز میشوند، نه روی نظر کلی. مثلاً: «آخرین باری که deadline پروژه را از دست دادید، دقیقاً چه اتفاقی افتاد؟»، «آن روز از چه ابزارهایی استفاده کردید؟»، «چه چیزی بیشتر از همه اذیتتان کرد؟» تکنیک «پنج چرا» (Five Whys) کمک میکند از symptom به root cause برسید: deadline از دست رفت → یادآوری نداشت → در چت گم شد → ابزار واحد نداشت → نیاز به visibility متمرکز.
پس از هر مصاحبه، noteهای خام را جمع کنید. هر note یک insight واحد باشد: یک pain point، یک goal، یک behavior، یا یک quote. در FigJam یا روی sticky note فیزیکی، affinity mapping انجام دهید: noteهای مشابه را cluster کنید. clusterهای تکراری — مثلاً «فراموشی deadline در پیامها» که در ۴ مصاحبه از ۶ تا آمده — candidate قوی برای trait اصلی persona هستند.
outlierها را حذف نکنید. اگر یک نفر از workflow بسیار متفاوتی استفاده میکند، آن را edge case بنامید و بعداً در scope تصمیم بگیرید آیا پوشش میدهید یا نه. در پروژه آموزشی ما، persona اصلی «سارا» طراح گرافیک freelance است که پروژههای متعدد client همزمان دارد؛ edge case میتواند client با contract سنگین و تیم ۱۰ نفره باشد که فعلاً out of scope است.
خروجی این مرحله یک research summary کوتاه است: ۳ تا ۵ theme اصلی، ۲ تا ۳ quote representative، و لیست assumptions که هنوز validate نشدهاند. بدون این خلاصه، persona به جای evidence-based document به یک تصویر تخیلی تبدیل میشود که تیم بعداً به آن اعتماد نمیکند.
قدم دوم: ساخت persona
Persona یک شخصیت fictional اما مبتنی بر evidence است — نه invent از ذهن، بلکه composite از الگوهای تکراری research. برای MVP یا پروژه آموزشی، یک primary persona کافی است. secondary persona وقتی معنا دارد که segment واقعاً متفاوت باشد (مثلاً manager vs individual contributor) و هر دو به product success وابسته باشند.
Template پیشنهادی Nova Lab: نام و عکس stock (برای empathy)، سن، شغل، bio دو تا سه جملهای، ۳ goal، ۳ frustration، سطح راحتی با tech، و یک quote که صدای واقعی user را منعکس کند. bio باید context بدهد، نه فقط demographic خشک. مثال: «سارا، ۲۸ سال، طراح گرافیک freelance در تهران. هفتهای ۴ تا ۶ پروژه client موازی دارد و بیشتر ارتباطش با client از WhatsApp و email است.»
Goals باید outcome-oriented باشند: «پیگیری deadline همه پروژهها در یک نگاه» بهتر از «استفاده از app». Frustrations هم concrete: «وقتی client در چت deadline را عوض میکند، فراموش میکنم calendar را update کنم.» Quote مثلاً: «من dashboard پیچیده نمیخواهم — فقط ببینم این هفته چه چیزی due است.»
anti-persona هم مفید است: مشخص کنید چه کسی user شما نیست. مثلاً «تیم enterprise با PM اختصاصی و Jira» — این scope را محدود میکند و از feature creep جلوگیری میکند. stakeholder وقتی feature عجیب پیشنهاد میدهد، میپرسید: «این برای سارا است یا anti-persona؟»
persona را یک صفحه نگه دارید. persona ۵ صفحهای کسی را نمیخواند. خروجی: PDF یا Figma frame که در workshop و جلسات design review روی wall یا screen باشد. هدف alignment و empathy است، نه مستندسازی بیش از حد.
قدم سوم: Problem Statement و How Might We
Problem statement جوهر design challenge شماست. فرمت استاندارد Nova Lab: «[User] needs [need] because [insight].» مثال برای سارا: «سارا به visibility متمرکز روی deadlineهای هفته جاری نیاز دارد، چون deadlineها در چت و spreadsheet پراکندهاند و بدون یادآوری مرکزی از قلم میافتند.»
در problem statement از naming solution خودداری کنید. «سارا به app نیاز دارد» ضعیف است؛ «سارا به visibility و یادآوری reliable نیاز دارد» درست است. solution بعداً در ideation میآید. اگر statement شما already یک feature را imply کند، brainstorming محدود میشود.
از problem statement یک یا چند How Might We (HMW) بسازید. HMW فریم open-ended برای ایدهپردازی است. مثال: «چطور میتوانیم به سارا deadline visibility بدهیم بدون setup پیچیده؟» یا «چطور deadlineهای پراکنده در چت را به یک view هفتگی تبدیل کنیم؟» HMW نباید پاسخ بدهد — فقط direction.
اولویتبندی problemها با impact × frequency. مشکلی که هر روز برای ۸۰٪ users رخ میدهد مهمتر از مشکلی است که ماهی یک بار برای ۵٪. matrix ساده ۲×۲ urgent/important روی FigJam کافی است. برای پروژه سارا، «از دست دادن deadline» معمولاً quadrant بالا-راست است.
یک جمله core problem + ۲ تا ۳ bullet evidence کافی است. bulletها از research میآیند: «۴ از ۶ interviewee گفتند deadline در chat گم میشود.» concise بودن باعث میشود تیم statement را حفظ کند و در تصمیمگیری feature به آن برگردد.
قدم چهارم: Jobs to Be Done (JTBD)
JTBD lens تکمیلکننده persona است. فرمت: «When [situation], I want [motivation], so I can [outcome].» برای سارا: «When client brief جدید میفرستد، I want سریع task و deadline را ثبت کنم، so I can بدون overhead اداری design را شروع کنم.»
سه نوع job داریم: functional (کار انجام شود)، emotional (احساس control و آرامش)، social (حرفهای به نظر برسد). برای سارا، functional: ثبت deadline؛ emotional: استرس کمتر از فراموشی؛ social: client ببیند organized است. design وقتی قوی است که هر سه را در نظر بگیرد — مثلاً confirmation واضح بعد save هم functional است هم emotional.
Persona «who» را humanize میکند؛ JTBD «why» و outcome را focus میکند. در کنار هم در workshop استفاده کنید: «سارا (persona) وقتی brief میآید (situation) چه jobای دارد؟» این از پرش زودهنگام به wireframe جلوگیری میکند.
Competing alternatives را map کنید: Excel، Notion، Google Calendar، کاغذ، حافظه. برای هر کدام switching cost و چرا هنوز استفاده میشود را بنویسید. اگر Notion «همهکاره اما سنگین» است، opportunity شما «سبک و focused روی deadline هفته» میتواند باشد — این insight مستقیم از JTBD و alternatives میآید.
خروجی JTBD: ۲ تا ۳ job statement اولویتدار که در problem statement و بعداً user story منعکس شوند. jobهای secondary (مثل export برای accountant) را explicit low priority علامت بزنید.
قدم پنجم: Validation و stakeholder alignment
persona و problem statement بدون alignment تیم، روی shelf میماند. workshop ۶۰ دقیقهای کافی است: present persona، بخوانید problem statement، HMW بنویسید روی board، dot-vote روی accuracy (آیا سارا واقعی به نظر میرسد؟). product، design، dev، و اگر هست business در یک room — یا یک FigJam مشترک.
assumption mapping: سه ستون «میدانیم»، «فکر میکنیم»، «نمیدانیم». هر claim research را بگذارید جای درست. «نمیدانیم» = backlog research sprint بعد. مثلاً «فکر میکنیم mobile primary است» → validate با analytics یا ۲ interview کوتاه.
deliverable one-pager: persona (یک صفحه)، problem statement، ۳ HMW، و draft success metrics. metrics مثلاً: «زمان add پروژه زیر ۶۰ ثانیه»، «کاربر بدون help اولین deadline را ثبت کند». draft بودن OK است — بعد از prototype دقیقتر میشود.
persona living document است. بعد از usability test یا launch، persona را update کنید. اگر ۵ user از ۵ نفر profile متفاوتی داشتند، یا persona wrong است یا segment دوم دارید. برای Nova Lab، بعد از tutorial usability، سارا ممکن است یک frustration جدید بگیرد — آن را اضافه کنید.
در پایان workshop، owner مشخص کنید: چه کسی persona را نگه میدارد و چه triggerی update میکند (هر quarter، هر major release). بدون owner، document کهنه میشود و تیم به assumptions شخصی برمیگردد.
قدم ششم: گام بعدی — user story و wireframe
از problem statement به user story: «As Sara, I want to see this week's deadlines in one view, so I can prioritize my work.» acceptance criteria measurable: «Week view shows at least project name and due date»، «Empty state prompts add first project». هر story به یک HMW یا job link شود.
Out of scope list صریح بنویسید: team collaboration، invoicing، time tracking — هر چیز که stakeholder ممکن است بخواهد ولی برای MVP سارا لازم نیست. این list در جلسات بعدی reference است و از creep جلوگیری میکند.
Metrics success را با problem align کنید: اگر problem «فراموشی deadline» است، metric «task completion for add project» و «user finds deadline in week view under 30 seconds» relevant است. NPS بعد launch supplement است، نه جایگزین behavioral metric.
آموزش بعدی Nova Lab — wireframe و prototype — دقیقاً از همین persona سارا و flow «add project → week view» شروع میکند. اگر persona و problem statement محکم باشد، wireframe بیهدف نمیشود؛ هر screen باید job یا story را serve کند.
تمرین پایانی: one-pager سارا را کامل کنید، problem statement را یک بار با همکار بخوانید و بپرسید «آیا solution پیشنهادی من در statement leak شده؟» اگر بله، rewrite. سپس ۳ user story و out of scope ۵ موردی بنویسید.
سوالات متداول
چند persona بسازم؟
برای focus و MVP، یک primary persona کافی است. دو secondary فقط وقتی segments واقعاً متفاوت و هر دو critical برای success هستند. بیش از سه persona معمولاً scatter ایجاد میکند و تیم نمیداند برای whom design میکند.
بدون interview واقعی میتوان persona ساخت؟
برای learning در Nova Lab بله — proto-persona از desk research و assumptions با برچسب «نیاز به validate». برای product واقعی، حداقل ۵ مصاحبه یا معادل qualitative data توصیه میشود؛ وگرنه design روی stereotype بنا میشود.
تفاوت persona و user story چیست؟
Persona «who» و context empathy را میدهد — یک شخص تماممدت. User story نیاز feature-specific است: «As… I want… so that…». Persona inform میکند کدام stories اولویت دارند و acceptance criteria با چه کسی align است.
Problem statement چند خط باید باشد؟
یک جمله core (User + need + because) plus ۲ تا ۳ bullet evidence از research. از paragraph طولانی خودداری کنید — تیم باید از memory recite کند. HMWها جدا نگه دارید.