# MSW Brand Voice

> Authoritative, technical, and empowering, focusing on standard-driven solutions rather than proprietary tools.

## Positioning
MSW is the industry-standard API mocking library for JavaScript developers. It provides a single source of truth for network behavior across development, testing, and debugging environments by leveraging standard platform APIs.

## Voice principles
*   **Authoritative:** Uses definitive statements to establish leadership and reliability.
*   **Standard-centric:** Prioritizes "the platform" and web standards over custom configurations or plugins.
*   **Empowering:** Focuses on what the developer can achieve (control, focus, reuse) rather than just listing features.
*   **Direct:** Uses imperative verbs and concise sentences to convey efficiency and clarity.

## Tone by context
| Context | Tone |
|---|---|
| Marketing Hero | Bold and definitive. Establishes MSW as the primary choice for the industry. |
| Feature Explanations | Educational and practical. Focuses on the "how" and the benefit of omitting details. |
| Technical Examples | Precise and clean. Uses real-world testing scenarios (happy paths, error states). |
| Social Proof | Enthusiastic and transformative. Highlights productivity gains and "life-saving" utility. |

## Lexicon
- **Use:** Industry standard, Control the network, Use the platform, Single source of truth, Omit implementation details, Integrate anywhere, Reuse, Augment, Precise.
- **Avoid:** Mocking library (when used alone without "industry standard"), Proprietary, Plugin-heavy, Configuration-first, Workaround.

## Messaging do's and don'ts
*   **Do:** Emphasize that MSW works with "the platform" (Fetch API, standard requests).
*   **Do:** Use active verbs like "Intercept," "Handle," "Control," and "Reuse."
*   **Do:** Highlight the ability to use the same mocks across the entire stack (Local, Integration, E2E).
*   **Don't:** Focus on complex setup; emphasize "No configurations, adapters, or plugins."
*   **Don't:** Talk about mocking as a chore; frame it as "describing how the network should behave."
*   **Don't:** Limit the scope to just testing; include local development and debugging.

## Evidence
*   "Industry standard API mocking for JavaScript."
*   "Control the network."
*   "Use the platform: Handle requests and responses using the standard Fetch API."
*   "Omit implementation details."
*   "A single source of truth for your network across the entire stack."
*   "Works with any tool there is or ever will be."