How We Work

Short reference docs for how work moves through OZEAON. Read these before raising a change, opening a ticket, or asking why something is not in dev yet.

The one-line version

Spec writing, design ideation, and signoff happen in columns 1 to 6, spec first. It then enters the dev track at column 7, broken into granular dev tickets if it covers an area of the product, or as it stands if it is already a single piece of work. Anything that changes after a ticket reaches Design Done needs a change request. Internal feedback goes to BA/PM, who triage before anything reaches dev or design. External bugs come in via the bug report form.

Contents

• Kanban. The 11-column board on Monday. What each column means, who owns it, and how design work reaches the dev track.
• New Feature Process. How a brand new feature goes through discovery before it reaches the board.
• Documentation Conventions. Where visual detail lives (Figma) versus where behaviour lives (specs), and how the two stay in sync without duplicating each other.
• Change Requests. How to change something that has already been signed off, specced, or shipped. Includes the design change flow and the bug reporting rule.
• Design Omissions. What a dev does when a design leaves a small gap, and how it gets written back into Figma and the spec.
• PR and Ticket Rules. What the Monday automation asks of you when you open a pull request. How to link one ticket or several, and why one approval is enough to send it to QA.
• Preview Environments. QA happens on the pull request’s own preview environment rather than on staging. Where the link comes from, the test accounts, and what it changes for QA.
• Team Resources. The Figma design file, the two Monday boards (tasks and bugs) and the shared drive, in one place.