# Problem Statement Builder ## Purpose Use this skill to turn a vague product, UX, or client brief into clearer problem statement options. It helps separate what is known from what is assumed, identify missing context, and define better questions before moving into design. ## When To Use Use this when you have an unclear request such as: - "Improve onboarding." - "Redesign the dashboard." - "Increase conversion." - "Make the app easier to use." - "Users are dropping off." This skill is useful at the start of a project, before research planning, ideation, wireframing, or solution design. ## When Not To Use Do not use this skill to create final requirements, UI screens, visual concepts, or validated research findings. The output should be treated as a discovery aid, not as proof. ## Inputs Needed Provide as much of the following as you can: - Project brief or stakeholder request. - Product or service context. - Target users or user groups. - Known business goal. - Current pain points. - Existing evidence or research. - Constraints, deadlines, or technical limits. - Stakeholders involved. If some information is missing, say "unknown" rather than guessing. ## Instructions You are helping a UX designer during the discovery phase. Your task is to transform the provided brief into clearer problem framing. Do not jump to solutions, features, UI ideas, or recommendations for what to build. Follow these steps: 1. Restate the brief in plain language. 2. Identify what is known from the provided context. 3. Identify assumptions that may be hidden inside the brief. 4. Identify missing information needed for better problem framing. 5. Create 3 to 5 alternative problem statement drafts. 6. Explain the focus and risk of each problem statement. 7. Recommend discovery questions the designer should ask next. 8. Suggest the best next discovery activity. ## Output Format Return the output using this structure: ### 1. Plain-Language Brief Summarize the request in one or two sentences. ### 2. Known Context List only facts provided by the user. Do not invent evidence. ### 3. Hidden Assumptions List assumptions that may need validation. Group them by: - User assumptions. - Business assumptions. - Product or technical assumptions. - Market or context assumptions. ### 4. Missing Information List the most important gaps that make the problem hard to frame. ### 5. Problem Statement Options Create 3 to 5 problem statements using this format: > [User group] needs a way to [need or goal] because [evidence, pain point, or current barrier]. For each option, include: - Focus. - Why it might be useful. - Risk or weakness. ### 6. Recommended Discovery Questions List 8 to 12 questions the designer should ask before designing. ### 7. Best Next Step Recommend one next discovery activity, such as stakeholder interview, user interview, analytics review, support-ticket review, journey mapping, or assumption mapping. Explain why. ## Quality Criteria A strong output should: - Stay specific to the provided context. - Separate facts from assumptions. - Avoid solution ideas. - Make uncertainty visible. - Produce problem statements that can be discussed with stakeholders. - Help the designer decide what to learn next. ## Example Input We run a SaaS dashboard for small business owners. The client says users are confused and wants us to redesign the dashboard. They also want more people to upgrade from the free plan. We do not have recent user research, but support has mentioned that users often ask where to find reports. The project needs an initial direction in two weeks. ## Example Output ### 1. Plain-Language Brief The client believes the dashboard is confusing and wants a redesign. There is also a business goal to increase upgrades from the free plan. ### 2. Known Context - The product is a SaaS dashboard for small business owners. - The client wants the dashboard redesigned. - The business wants more users to upgrade from the free plan. - Support has heard users ask where to find reports. - There is no recent user research. - The team needs an initial direction in two weeks. ### 3. Hidden Assumptions User assumptions: - Users are confused because of the dashboard layout. - Reports are important to small business owners. - Finding reports is a common problem, not just a support-ticket pattern. Business assumptions: - Dashboard changes will increase upgrades. - Free users understand the value of paid features. - Upgrade friction is related to discovery or comprehension. Product or technical assumptions: - The dashboard can be changed within current constraints. - Report visibility is controlled by interface design rather than permissions, data availability, or plan limits. Market or context assumptions: - Small business owners share similar reporting needs. - Current users have enough product knowledge to evaluate paid features. ### 4. Missing Information - Which user groups are most affected. - Where users currently look for reports. - Whether confusion happens during onboarding, daily use, or upgrade evaluation. - Which dashboard areas receive the most support questions. - What currently blocks free users from upgrading. - Whether paid features are visible, understood, or valued by free users. ### 5. Problem Statement Options > Small business owners need a clearer way to find key reports because support feedback suggests they may not know where reporting tools are located. - Focus: Report discoverability. - Why it might be useful: It is tied to the only available evidence. - Risk or weakness: Support feedback may not represent the broader user base. > Free-plan users need a better way to understand the value of paid reporting features because the business wants to increase upgrades. - Focus: Upgrade comprehension. - Why it might be useful: It connects user understanding with the business goal. - Risk or weakness: It assumes reporting features influence upgrade decisions. > Small business owners need a dashboard that helps them identify the most important next action because the current experience may not make priority tasks obvious. - Focus: Task clarity. - Why it might be useful: It frames the dashboard as a decision-support surface. - Risk or weakness: The actual user goal is not yet validated. ### 6. Recommended Discovery Questions - What jobs do small business owners come to the dashboard to complete? - Which dashboard tasks are most frequent? - Which tasks create the most support requests? - What do users expect to see when they look for reports? - Where do users currently click before contacting support? - What reporting information is available on free vs. paid plans? - What do free users understand about paid features? - What reasons do users give for not upgrading? - Which user groups are most valuable to the business? - What evidence would show that dashboard confusion affects upgrades? ### 7. Best Next Step Start with a support-ticket and analytics review. This is the fastest way to check whether report discoverability is a real pattern, where users struggle, and whether the dashboard problem is connected to upgrade behavior. Follow this with short user interviews if the evidence confirms a recurring issue.