Project Delivery & Revisions Policy
1. Defining the deliverable set
A useful scope describes the pages or screens, key interaction states, device layouts and files to be delivered. For a review engagement, the deliverable may be findings and recommendations. For a design engagement, it may include high-fidelity layouts. For a prototype or documentation engagement, it should identify the connected screens or guidance included.
Terms such as complete design, responsive layout or design system should be made concrete. The agreement should identify the relevant screens, variants, breakpoints, components and documentation detail. We do not rely on a broad service title to imply unlimited pages, every possible interaction state or a production-ready software product.
2. Brief and required inputs
At the beginning, the parties should identify the intended users, main tasks, business context, relevant content and practical constraints. Existing websites, brand assets and technical information can help define what should be retained, improved or explored. The client should identify restrictions that affect the work before design decisions depend on them.
The proposal should state which materials the client will supply and which, if any, we will create. Content writing, translations, original illustration, photography, formal research recruitment and development are not assumed simply because an interface needs them. Their inclusion and ownership must be agreed where required.
3. Milestones and schedule
An engagement can be divided into stages such as structure, wireframes, visual direction, detailed screens, prototype and handoff. Milestones should identify what is ready for review and which decisions are needed before the next stage. A focused service may use fewer stages than the website demonstration.
The schedule depends on the accepted scope, starting conditions, client inputs and review availability. A proposal should distinguish estimated dates from any express firm commitment. If a dependency changes, the parties should document the effect and agree an appropriate revision rather than assume that all downstream dates remain unaffected.
4. What a review round means
A review round is a defined opportunity for the client to evaluate the work presented for that stage and provide consolidated feedback within the agreed direction. The included number of rounds and the process for providing feedback should be stated in the proposal.
One clear feedback set helps avoid conflicting instructions and repeated rework. Comments should identify the relevant screen, component or requirement and explain the intended outcome. A round is not an unlimited series of new creative directions, but it should be sufficient for the refinements actually included in the agreed scope.
5. Included refinements and scope changes
Refinements typically adjust an agreed deliverable within the accepted structure and direction. Examples can include a hierarchy adjustment, alignment change, wording correction or component refinement, depending on the service and scope. Whether a requested change is included must be considered against the project documents.
A new page, a substantially different flow, a changed business requirement, an additional device layout or a replacement creative direction may require a change order. We should explain the additional work and its price and timing effect before chargeable work proceeds. A discussion of possibilities does not authorize every option mentioned.
6. Approval and decision records
The agreement should identify the person or process authorized to approve milestones. Approval should indicate what was reviewed and what is accepted for moving forward. Written records help distinguish an approved decision from an exploratory comment or a request that remains unresolved.
This policy does not create automatic approval by silence or an undisclosed deadline after which every deliverable is deemed accepted. Any review window or acceptance procedure must be clearly agreed and lawful. Material defects against an agreed requirement should not be dismissed merely because a later stage has begun.
7. Responsive layouts and accessibility considerations
The proposal should specify which desktop, tablet or mobile layouts are included and how behavior at intermediate widths is documented. A single static desktop screen does not automatically define every responsive state. Important content ordering, navigation changes and component behavior should be described where relevant.
Accessibility-related work should be stated with the appropriate scope, such as contrast review, readable hierarchy, keyboard interaction guidance or a review against a specified standard. A general UX/UI service is not a blanket certification of legal compliance. Implementation, assistive-technology testing and content maintenance may require additional work or specialists.
8. Prototype scope and representative behavior
An interactive prototype connects selected screens or states to show intended behavior. It may demonstrate a primary path without implementing every edge case, external integration or data condition. The agreed prototype scope should identify the flows and interactions that need to be reviewed.
Prototype fields, menus and confirmations may be representative rather than operational. Unless a separate production system is developed and authorized, a prototype should not be used for actual transactions or sensitive information. The website process demonstration is labeled accordingly and does not submit the visitor's personal data.
9. File formats and delivery method
The proposal should identify the handoff tool, export formats and any access requirements. Depending on the engagement, delivery may include editable design files, image exports, prototype access, written findings, component guidance or specifications. We do not promise every format or file type unless it is agreed.
If a third-party account, license or subscription is required to access or edit the files, responsibility for it should be clarified in advance. A final transfer should identify the deliverables provided and any known limitations relevant to their intended use. Ongoing storage, account access or hosting duration is not silently promised as unlimited.
10. Design documentation and development handoff
Documentation can explain type, colors, spacing, components, interaction states and responsive behavior to the agreed level of detail. The purpose is to support understanding and implementation by a development team. Documentation is not automatically source code or a warranty that another party will implement the design exactly.
If developer questions, handoff meetings, implementation review or post-delivery support are required, their extent should be included in the proposal. Additional assistance can be scoped separately. The client should ensure that its implementation team can use the selected tools and receive the relevant materials.
11. Delivery review and identified issues
After delivery, review the files for completeness against the agreed list and identify any missing, inaccessible or materially inconsistent item. Include the relevant requirement and file or screen so that the issue can be investigated efficiently. Correcting an agreed delivery error is distinct from commissioning new work.
The applicable agreement should describe any post-delivery correction or support period. This policy does not invent a universal warranty duration or eliminate a remedy required by law. If a project needs archival copies, future updates or migration to another tool, make those expectations explicit before relying on them.
12. Dependencies, delays and contact
Client delays, changed inputs, external tool outages and implementation dependencies can affect practical delivery. The appropriate response is to communicate the issue, identify affected work and agree a reasonable next step consistent with the project agreement. Such events do not automatically justify undisclosed charges or waive all responsibilities.
For a scope question, review comment, missing deliverable or handoff issue, contact Parkhurst Interface using the details below. Include the project reference, stage and specific material involved. Clear records support a more useful resolution and help keep the next stage of work understandable.
Contact Parkhurst Interface
EMAIL: projects@parkhurstinterface.com
ADDRESS: 6601 Westown Pkwy, West Des Moines, IA 50266
PHONE: +1 (641) 500-7004