diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index b008c708..51fddb60 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -16,23 +16,18 @@ Hub instead: https://insider.windows.com/en-us/fb/?contextid=130 --> **Problem Statement** - + **Evidence or User Insights** - + **Proposal** - - -**Risks** - + **Goals** **Non-Goals** \ No newline at end of file +why. --> + +**Low-Fidelity Concept** + \ No newline at end of file diff --git a/docs/NewFeatureProcess.md b/docs/NewFeatureProcess.md index 0b32922a..497d3350 100644 --- a/docs/NewFeatureProcess.md +++ b/docs/NewFeatureProcess.md @@ -22,24 +22,24 @@ especially to new features and major visual changes. The feature pitch concisely describes a point of view on the problem the new feature should solve. It will typically include these sections: -* **Problem Statement**: What problem are we trying to solve? Who’s the customer? Is there a +* **Problem Statement**: What problem are we trying to solve? Who’s the target audience? Is there a customer need or pain point we need to remedy? Is there a business goal or metric we are trying to improve? Do we have a hypothesis we want to prove or disprove? * **Evidence or User Insights**: Why should we do this? Potential sources of data: Feedback Hub, - GitHub, request from another team, telemetry data, anecdotes from listening to customers in - person, user research, market or competitive research -* **Proposal**: How will the solution/feature help us solve the problem? How will the - solution/feature meet the customer’s needs? How will the solution/feature improve the metrics? - Who’s the target audience? -* **Risks**: This section may not be necessary if covered by the problem statement. What is the - risk if we don’t do this work? What is the risk if we do? -* **Goals**: What you want to accomplish with this feature. Typical examples include - “User Can *perform some task*” + other GitHub issues, other anecdotes from listening to customers in person or online, request + from another team, telemetry data, user research, market or competitive research +* **Proposal**: How will the solution/feature help us solve the problem? How will it meet the + target audience’s needs? If there are business goals or metrics, how does this improve them? +* **Goals**: What you want to accomplish with this feature. Typical examples include “User Can + *perform some task*” * **Non-Goals**: Things we are explicitly not doing or supporting or that are out of scope, - including any reasoning to why. + including reasons why. +* **Low-Fidelity Concept**: Show as much of the experience as needed to explain the idea. This + can be as simple as a napkin drawing but can also be a code prototype, a PowerPoint walkthrough, + or a design comp. -The feature pitch may also include a low-fidelity concept which will be refined during the -pre-production process. +The low-fidelity concept should be kept simple at this stage and refined during the pre-production +process. Feature pitches are submitted as issues on GitHub. We encourage discussion on open issues, and as discussion progresses we will edit the issue description to refine the idea.