A store-design handover should leave the merchant able to operate the result. A folder of polished screenshots is not enough if nobody knows where the editable files are, which assets are licensed or how to correct a product description.
Review the handover against the agreed scope before the project ends. Separate delivered design work from hosting, content and ongoing maintenance responsibilities.
Match files to the agreed deliverables
Start with the project brief. List the pages, components, responsive layouts and states that were promised.
Check that the handover contains the final versions rather than a mixture of experiments with similar names. Ask for a short index explaining which file is current.
If a deliverable changed during the project, record the agreed replacement. Do not assume an omitted page was intentionally removed.
Confirm ownership and access
Identify which accounts belong to the business and who can administer them. Use the platform's appropriate access roles instead of exchanging passwords in a document.
Check that the merchant can reach the files and editing tools independently. A link that only works for the designer is not a completed transfer.
Access changes should be planned carefully so ongoing services are not accidentally interrupted.
Check editable sources
Confirm whether the agreement includes editable design files, component definitions and original asset files.
Open a representative file and make a harmless copy for an editing exercise. Check whether text, colours and images can be changed as expected.
A flattened image may be appropriate for a reference export, but it does not replace an editable source when that was part of the scope.
Keep asset permissions with the assets
Request a clear record of fonts, photographs, icons and other third-party materials used in the final design. Identify applicable licences and any continuing subscription requirements.
Do not assume that a designer's personal account transfers rights to the merchant. Resolve uncertainty with the relevant provider or agreement.
Keep this information alongside the handover so a future redesign does not accidentally reuse an asset outside its permitted use.
Review normal and difficult states
Look beyond the homepage. Include product options, unavailable stock, an empty bag, missing photographs and long content.
Confirm which states were designed and which depend on implementation. A static design file does not prove that checkout behaviour works.
Record remaining functional checks separately rather than signing them off because the screen looks correct.
Practise a routine content change
Use a safe draft or staging environment to update one product title, replace a photograph and edit a delivery sentence.
The person responsible for maintenance should be able to complete the task using the supplied instructions. Note where they become stuck.
This exercise is more informative than receiving a long manual that has never been followed by its intended reader.
Document the design rules
Ask for concise guidance on type roles, colours, spacing, image ratios and common components. Include examples of what not to change casually.
Explain how a new product or category should fit the existing system.
The aim is consistency during ordinary maintenance, not a document so elaborate that nobody consults it.
Separate design from service operation
Identify responsibility for hosting, renewals, backups, security updates and payment settings. Some may sit outside the design contract entirely.
Record the responsible person and where the process is documented. Do not leave the merchant assuming a one-time design fee includes indefinite technical support.
Avoid placing credentials in the handover pack; provide secure access through the appropriate mechanism.
Agree how remaining defects are handled
Create a finite list of unresolved issues with examples and owners. Distinguish an agreed correction from a new feature request.
State the support period and contact method according to the actual agreement, not an assumed industry standard.
Keep evidence of the final delivered state so future changes can be distinguished from original defects.
Close with an independent opening test
From the merchant's account, open the final files, locate an asset, find the maintenance instructions and identify the person responsible for a technical problem.
Then verify that a future editor can understand the same structure without the original designer explaining it live.
A useful handover is not merely a transfer of files. It is a transfer of enough knowledge and access for the business to maintain the design responsibly.
Archive without losing the current version
Keep older experiments separate from the final package. Preserve a dated copy of the accepted files before routine editing begins. This makes recovery and comparison easier without encouraging the team to publish an outdated mock-up by mistake.
Examples are illustrative. Confirm current features, charges and suitability before making a business decision.
Explore this topic → · Find an oBizee setup guide · Ask about your store