Effective date: May 20, 2025
Last updated: May 20, 2025
1. Deliverables are defined before work
Each engagement should have a written scope describing its deliverables. Depending on the service, these may be an audit report, a research synthesis, user flows, a sitemap, wireframes, interface screens, an interactive prototype, a UI kit, a design system, testing findings, or developer documentation. A service title alone does not define every screen or state. The proposal identifies the included inventory, fidelity, formats, and review stages.
2. Electronic delivery
Services are delivered electronically through the agreed design workspace, prototype link, document format, or secure file-sharing method. No physical shipment is required. The agreement should distinguish editable source files from exports and review-only links. Access permissions, account ownership, and any time-limited tool access should be discussed before final handoff. Third-party software subscriptions or licenses are not transferred merely because a file is delivered.
3. Schedule and dependencies
We agree a delivery schedule after understanding scope and availability. A schedule may rely on client content, stakeholder decisions, participant recruitment, technical input, or approved access. A delay in one of these dependencies can move later milestones. If the scope or dependencies change materially, the parties should confirm the revised plan. Published starting prices do not create an automatic turnaround guarantee, rush commitment, or delivery date.
4. Feedback and approval
The client should nominate a person who can consolidate stakeholder feedback and confirm decisions. Useful feedback refers to the agreed objective, screen, state, or requirement and explains the issue to resolve. The proposal should specify review periods and approval checkpoints. We do not treat silence under this general policy as automatic acceptance. If feedback is late, work may need to be rescheduled rather than assumed approved.
5. Included revisions
Included revision rounds are stated in the written scope. A round normally means one consolidated set of comments on a particular review delivery, followed by agreed refinements within the current direction and requirements. The agreement should explain whether rounds apply per stage, per deliverable, or to the project as a whole. There is no implied promise of unlimited revisions, unlimited design alternatives, or continuous availability.
6. Changes outside the scope
Additional screens, user roles, journeys, responsive variants, languages, content production, new features, and a material change in an approved direction may fall outside the original work. We will describe the proposed change and its effect on fees or timing before billable additional work proceeds. A request for an estimate is not itself permission to charge for a change. The client can decide whether to approve, defer, or remove the additional item.
7. Corrections and acceptance
At each delivery, compare the material with the agreed requirements and identify any specific discrepancy. Corrections needed to meet the agreed scope are assessed separately from a new preference or requirement. Any acceptance process in the project agreement should give a reasonable opportunity to review the work. A later project phase may rely on an earlier approval, so a reversal can affect subsequent work and should be discussed promptly.
8. Prototypes and research outputs
Interactive prototypes simulate selected behaviors and are not production systems. Placeholder content, synthetic data, non-functional fields, and unconnected states should be identified where relevant to review. Research findings reflect the agreed sample and method, not a guarantee about every future user. Research recordings and personal participant records are shared only within the agreed consent, privacy, and confidentiality arrangements; they are not automatically included in a public design handoff.
9. Developer handoff and implementation
A handoff can include annotated screens, component states, spacing, typography, assets, and responsive guidance when listed in scope. It does not automatically include production code, integration work, deployment, implementation QA, or an unlimited period of developer questions. The implementation team remains responsible for the behavior and security of the built system. Any follow-up design QA or additional support can be agreed as a separate stage.
10. Final access, archives, and post-project requests
The parties should confirm receipt of final files and any access or ownership changes before closing the project. Long-term hosting, archival retention, restoration, and continuing editing are not included unless agreed. Clients should maintain their own authorized copies of final deliverables. Later requests to adapt, restore, or extend a completed design are assessed against the original agreement and any new scope. Questions about a delivery can be sent using the contact details below.
Contact Justice Design Group
EMAIL: projects@justicedesignux.com
ADDRESS: 405 E. Euclid Ave, Compton, CA 90222, United States
PHONE: 1 (213) 437-0102