# Principle Definition
# Phase: 🎨 Problem shaping
Focus: Converge
IN BRIEF
Time commitment: 1-2 hours
Difficulty: Moderate
Materials needed: Mid-stage ideas or insights (post-brainstorming or Crazy Eights, pre-solution alignment), meeting space (physical or virtual), whiteboard and stickies (physical or virtual), participants from a variety of technical and cultural perspectives (the more of these, the more useful)
Who should participate: User experience designers, product/project owners, community specialists, developers
Best for: Creating guardrails or a "north star" for further work that help keep future iterations consistent
# About this tool
While stopping to define principles midstream may seem like a distraction — doesn't that happen on its own? — it can be an extremely helpful exercise for defining guardrails against scope creep, changes in ideology, or unintended re-focusing. And while principles may change over time, simply recognizing that a principle is on the road to change opens the doors for valuable discussion on whether that road is the best one.
Within the context of overall product or project development, principles could be ...
- Design principles, such as "everything must be beginner-friendly" or "avoid visual clutter at all costs"
- Ideology principles, such as "don't shim via centralization, even temporarily" or "anonymization uber alles"
- Technology principles, such as "speed wins out whenever practical" or "adequate testing trumps release deadlines"
The act of actually defining your principles needs to be a collaborative one, and is likely to benefit from happening in a synchronous space if at all possible; otherwise, you may run the risk of asynchronous clarifications snowballing into ideological arguments. Whether synchronous or asynchronous, be sure to include representatives from every stakeholder or maker group, even if they're not 100% involved in the day-to-day creation of the product or solution.