Design

The decisions that make AI Security Planner easier to understand, trust, and use.

A clear place for every planning task

What we designed: Home explains the product. New Program creates a plan. My Work manages saved programs. Portfolio compares active programs. Overview, Roadmap, and Report support one selected program.
Why it matters: Starting, managing, comparing, and updating work are different jobs. Giving each job a clear destination removes duplicate controls and uncertain next steps.
User value: A program owner can start, resume, compare, update, inspect, report, and share through one stable navigation model.
Tradeoff: The product uses several focused pages instead of one crowded screen.
Evidence: Usability review of the complete start, portfolio, planning, and reporting flows.
Release standard: Every page must support a distinct user job. Duplicate creation, sharing, settings, or documentation paths fail review.

What we designed: Source-backed program packages provide outcomes, finish conditions, effort, ownership, priority, and dependencies before scheduling begins.
Why it matters: A blank project asks the user to research and structure the entire security program before the tool becomes useful.
User value: The first roadmap starts from reviewable security-program judgment while keeping every assumption and limitation visible.
Tradeoff: A fixed starting point cannot represent every organization and remains a planning baseline rather than professional advice.
Evidence: Source review, the program-package contract, and repeatable reference plans.
Release standard: Program-package changes require stable identifiers, source review, validation, reference outputs, and owner approval.

What we designed: List, Kanban, Gantt, PERT, Burndown, Burnup, inspectors, and reports show the same milestones, tasks, dates, and dependencies.
Why it matters: Different questions need different views, but separate copies of the work would drift and contradict one another.
User value: A saved date, progress update, task, or subtask remains consistent wherever the program is reviewed.
Tradeoff: Every view must preserve the same object identity and actions while adapting to its available space.
Evidence: Cross-view acceptance tests against one saved program projection.
Release standard: A view may change presentation, never the meaning of saved state. Actionable milestones always retain Inspect, Edit, and Delete.

What we designed: Editable programs are saved to the signed-in account or selected organization; interface preferences and share revocation keys stay in the current browser. Import, export, PowerPoint, and a read-only Share snapshot occur only when the user chooses them.
Why it matters: Organization ownership keeps work available to authorized sessions without turning a browser profile into the system of record.
User value: The tenant boundary remains explicit while a revocable 30-day link supports deliberate external review.
Tradeoff: Saving program changes requires a connection, and clearing browser data removes interface preferences and the local revocation key. JSON export remains a user-controlled backup path.
Evidence: Organization persistence, authorization, file portability, and read-only sharing acceptance tests.
Release standard: Every saved write is authorized against one organization and protected by revision checks; browser preferences never become program storage.

What we designed: Overview and the executive report lead with forecast impact, priority work, consequences, ownership, dates, and a real decision or next action.
Why it matters: Raw status lists make leaders reconstruct the implication and urgency themselves.
User value: The report explains what changed and what requires attention while retaining the basis and product limits.
Tradeoff: The report deliberately omits low-value activity and does not claim security assurance.
Evidence: Executive-report review and reconciled output tests against the same saved state.
Release standard: Recommendations are not labeled decisions. A decision field must name an actual choice between viable options.

What we designed: The product targets WCAG 2.2 Level AA, equivalent mobile and desktop tasks, eight complete languages, and Arabic right-to-left behavior.
Why it matters: Access needs, translation, direction, and narrow layouts change structure and interaction—not only words.
User value: The same planning and reporting work remains understandable across supported devices, languages, and assistive technologies.
Tradeoff: Automated tests cannot prove the full target; manual browser, device, language, and assistive-technology evidence is still required.
Evidence: The supported-device, language, and accessibility release matrix.
Release standard: No readiness claim is made until every required viewport, theme, language, direction, keyboard, and assistive-technology check passes.