Principles (how to work)

Every other reference in Sleak is craft and hierarchy, what good UI looks like. This one is the decision layer, how you arrive at it: research, framing, low-fidelity iteration, and feedback. Process, not pixels.

Use it upstream (discovery, problem framing, exploration); switch to the craft references once you're shaping the actual interface.

Purpose

Catch the process failures that no amount of visual polish fixes: designing from assumptions, polishing the wrong thing, or hiding work until it's "done."

Guess less, decide from evidence

Assumptions are the expensive mistake. Talk to users and look at data. Two kinds of research, used at different moments:

• Generative (before you design): what do people need? Uncovers the real problem.
• Evaluative (after you have something): does this work for them? Validates or kills it.

The goal is to guess less, replace one assumption per round with a fact.

Reframe the problem before solving it

The sharpest lever is the problem statement, not the solution. First empathize, collect real user stories and insights, then write a point of view (POV) that reframes the problem. A good reframe opens solutions a literal reading hides (the classic: reframing "patients fear the MRI machine" as "make the scan an adventure" changed the whole design).

Story first, set the North Star

Before pixels, agree the narrative: what future are we creating, and for whom. A shared North Star aligns the team and gives every later decision something to measure against.

Diverge before you converge

Generate many options before committing to one. Frame exploration as "How might we…?" to open the space. Pencils before pixels: sketch low-fidelity and widely first, polished pixels too early shut down exploration and pull critique toward colour instead of the idea.

Prototype to learn

A prototype is a question, not a deliverable. Build at the lowest fidelity that answers the question, a prototype settles disagreements and tests a hypothesis faster than any debate. Match fidelity to the question: pen-and-paper for flow, clickable for interaction.

Show early, build a feedback culture

Share work early and often. Low-fidelity work invites honest critique; finished-looking work suppresses it, because people assume it's done. Frame feedback by the project goals, not personal taste. Giving and receiving critique is a skill, make it routine, specific, and safe (hard on the work, easy on the people).

Test early and often

Put it in front of real users sooner than is comfortable. Each round removes a guess. Early-and-often beats one big test at the end, when it's too late (and too expensive) to change.

Work laterally, break the black box

Design is a team sport. Involve engineering and stakeholders early, a design-engineering bridge closes the gap between what's designed and what's built. Keep the process visible: an opaque "black box" breeds mistrust and rework. Product design is people.

How this relates to the craft rules

The craft references tell you what to build; these principles tell you how to decide what to build. They sit upstream of the pixels, when you're shaping the interface itself, follow the craft rules.

Do / Don't

Notes

• This is the one process/methodology layer in Sleak; it is deliberately distinct from the visual-craft rules.
• Not every project needs every step, treat these as the moves available when a decision is bigger than "what should this look like?"