Plan a corporate website and an online store around two connected customer journeys: understanding the business and buying the right product. Define where those journeys meet, what information they share and who will maintain them. The visual design should follow those decisions, alongside the product catalogue, checkout, content and measurement plan. Adding commerce after approving a homepage often reopens decisions the team thought were settled.
This guide is for businesses combining brand communication with direct sales, including established companies adding a shop to an existing website. It provides a way to evaluate an agency proposal, prepare internal responsibilities and decide whether a release is ready. It does not assume that every business needs the same platform or a custom build.
Describe the jobs visitors need to complete
Someone evaluating a supplier may need to understand its capabilities, service boundaries and approach before making an enquiry. Someone shopping for a specific item needs compatibility, availability, delivery and price information. The same person can take both journeys at different times. Treat them as connected tasks, without making every page serve every purpose.
Write a starting point and a completion point for each priority journey. A service page leading to a useful project enquiry is one route. A category leading to the correct variant and a completed order is another. “Visitors should explore the website” is too vague to decide which features deserve attention when time is limited.
Use questions from sales and support to make the routes concrete. A question about wholesale availability belongs somewhere different from a question about a product's dimensions. Link the answers when the relationship helps the reader. Navigation should make sense to customers, rather than reproducing the business's internal department structure.
Also identify visitors who cannot buy immediately. They may need a quotation, a sample, delivery clarification or confirmation that a product is suitable. A useful alternative route explains what happens next. A generic contact button beside every product does not replace a considered process for those requests.
Choose an operating model before choosing the interface
One platform can work well when the corporate content is relatively straightforward and the store follows standard retail processes. The attraction is shared administration: people can maintain products and brand pages without moving between unrelated systems. Test that assumption with real tasks, including updating a variant, changing a campaign message and correcting a service description.
Separate systems may be appropriate when an existing corporate website has substantial editorial workflows or specialist applications. The additional work then needs to be visible. Navigation, search, measurement, account journeys and maintenance must remain coherent across the boundary. Separate systems are a design and operational choice, with responsibilities to match.
A more bespoke architecture, including a headless approach, should respond to a requirement that a simpler setup cannot meet adequately. Flexibility has little value if every routine content change requires scarce development time. Consider editor independence, integrations, support capacity and ongoing ownership alongside the freedom to design a distinctive interface.
Make domain and URL decisions within that discussion. A subdomain or folder is not a universal shortcut to better search performance. Review the current addresses, platform constraints, language structure and maintenance responsibilities. If Shopify is a candidate, the store launch planning guide connects platform decisions with the operational preparation behind them.
Ask for defined deliverables, not just a page count
A proposal for a ten-page website and a shop says little about the work involved. One product template might display hundreds of items, while collecting, cleaning and checking their information remains a substantial separate task. A short enquiry form can also require routing, attachments and follow-up processes that are not apparent in a mockup.
A useful proposal distinguishes these work areas:
- Information architecture: page roles, navigation, category structure and priority journeys.
- Interface design: templates, mobile behaviour and empty, error or pending states.
- Content preparation: copy, imagery, product information, language versions and entry work.
- Commerce: cart, payment, delivery options and order communications.
- Integrations: information exchanged with stock, accounting, fulfilment or customer systems.
- Release and handover: testing, URL changes, measurement checks, training and initial support.
For each area, record the quantity, owner and acceptance condition. Product entry should specify the number of product families and variants, the fields supplied and who checks them. Photography, translation and copywriting should have explicit boundaries. Otherwise, a missing business input can appear late in the project as an unexplained design delay.
Agree how changes will be handled after approval. Adding a category may affect filters, content, integrations and testing, even when it looks like a small navigation edit. Record the schedule and cost implications before proceeding. This keeps a series of reasonable requests from silently turning the agreed project into a different one.
Use real catalogue data during design
Create a shared definition for product names, identifiers, options, measurements, prices, stock and images. Inconsistent terminology becomes more than a copy issue when the same fields power filters, comparison tools or transfers to another system. Resolve those differences before the catalogue is used as the foundation for the interface.
Choose representative products for design reviews. Include a long name, multiple options, an unavailable item and a product with unusual delivery requirements. A template that looks good with three ideal examples may behave poorly with the real range. The review should reveal whether a long heading hides the purchase action or a variant selection leaves an incorrect image on screen.
Assign responsibility for uncertain information. A designer should not guess a technical specification, and an editor should not invent a delivery promise. Someone from the business needs to confirm product accuracy and commercial conditions. One person may cover both roles in a small team, but the responsibility still needs to be explicit.
Corporate pages need real inputs too: approved photographs, accurate service descriptions, current contact information and evidence the business is entitled to use. Placeholder testimonials or imagined team biographies must not become launch content. A page containing polished placeholder copy is still an unfinished page.
For multilingual work, prepare a terminology list and nominate an owner for each language. Translating a page does not automatically make the offer suitable for another market. Confirm the products available, delivery conditions, contact routes and currency presentation that apply to that audience. Keep shared brand claims consistent while allowing the explanation to read naturally.
Share a visual language while respecting different page roles
The brand section and shop should feel related through typography, colour, interaction patterns and tone. They do not need identical layouts. A service page may lead with suitability and scope; a product page may need selection, availability and delivery information close to the purchase action. Consistency should help recognition without forcing incompatible tasks into one template.
The homepage should explain the offer and guide people towards an appropriate starting point. It does not have to display the full catalogue. A business serving consumers and trade buyers might offer clear routes to shopping and trade enquiries. Giving every action equal visual weight makes it harder to understand which route to take.
Review mobile behaviour with real content. Check whether the on-screen keyboard hides an important form control, whether long options remain understandable and whether an error explains what needs correcting. Error states should not rely on colour alone. Approval of attractive screenshots is only one part of design acceptance.
The guide to categories, products and filters helps assign distinct roles to commerce pages. Use it when deciding where buying advice belongs and which page should answer a particular product question. This reduces unnecessary duplication between editorial explanations and the shopping interface.
Define what an integration must do when something goes wrong
First establish which system is authoritative for stock and order information. When a purchase is placed, what is sent, where does it go and when should the receiving system acknowledge it? What should happen after a cancellation or return? Connecting two applications does not settle those operating decisions by itself.
Write a failure scenario alongside the normal scenario. If a delivery service does not respond, what should the customer see and who should receive an alert? If an order is sent twice, how will a duplicate be identified? Developers will determine the technical implementation, but the expected business behaviour can be described in ordinary language.
Use suitable test data and agree how test records will be distinguished from production records. Keep business ownership of essential accounts clear, assign access according to responsibilities and include an access review in handover. An attractive storefront is not an adequate substitute for an operating process that the team can maintain.
Test checkout and enquiries as separate workflows
A successful payment is one scenario. Rejected payment, invalid address, unavailable stock, an expired promotion and a repeated attempt are also useful tests. The customer should understand the outcome, and the support team should have enough information to respond. For each test, record the expected behaviour and what actually happened.
Shopify recommends test orders to check checkout and associated settings such as inventory, shipping and notifications. Live orders cannot be accepted while payment providers are in test mode, and real payment tests may incur fees. Select an appropriate method using the Shopify test order documentation.
For enquiries, verify more than the thank-you message. Confirm delivery to the responsible person, sufficient information for a useful response and understandable handling of attachment errors where relevant. A functioning form and an effective sales follow-up are separate responsibilities. The business should specify who responds and how the request is tracked.
Design measurement around actual business actions
Keep enquiries and purchases distinguishable. Product views, cart additions, checkout starts and completed purchases describe different stages. Google's GA4 ecommerce documentation defines events and item data for those stages, including the use of currency with monetary values.
The project plan should identify where each action will be measured, who will test it and which report will be used. A button click is not automatically a completed enquiry. A page view is not a sale. Ask the implementation team to check repeated purchase signals and the handling of currencies, as well as applicable consent choices and collection settings.
Record a baseline before evaluating the release. With few visits, large percentage movements can reflect very small counts. Note changes in prices, campaigns and product availability during the same period. If an event has not been verified, the correct conclusion may be incomplete measurement rather than no customer demand.
Choose a small set of questions the team can act on. Are suitable visitors reaching products? Are they encountering difficulties when choosing options? Are qualified enquiries reaching the sales team? A dashboard should help answer those questions, not simply accumulate numbers because they are available.
Preserve useful addresses when an existing site changes
A corporate website can lose attention during a store launch even though its existing service pages and articles remain useful. Inventory addresses receiving traffic or links. Distinguish pages that will stay, pages that will change and material without a suitable replacement. A new design is not, on its own, a reason to change every URL.
Where addresses must change, map each old page to a relevant destination rather than sending everything to the homepage. Google's site migration guidance covers mapping, redirects and monitoring after the move. These are implementation checks, not a guarantee that rankings will remain unchanged.
If product data is also moving, use the Shopify migration guide to review data, address and order continuity. The corporate section and store do not always have to move simultaneously. Consider whether a staged release can work without confusing customers or creating conflicting information between systems.
A hypothetical project, divided into useful stages
Imagine a home accessories manufacturer selling selected items directly while taking quotations for larger business orders. The first release should allow a customer to buy those items and allow a trade buyer to submit a useful request. This is an illustrative planning example, not a client case study or a promised delivery schedule.
Start with product information and delivery conditions supplied by the business, while the agency develops the journeys and page templates. Review a mobile prototype using real products. Retail customers see relevant stock and purchase information; custom-order customers get a route explaining what information the business needs before quoting.
During development, test standard checkout separately from the trade enquiry route. Advanced account-specific pricing can wait only if the initial trade workflow is useful without it. Record what has been deferred and the condition that would justify revisiting it. “We may need it someday” should not automatically become a launch requirement.
Assign sign-off by area. The product owner checks accuracy, the commercial owner checks pricing and fulfilment rules, and the project lead confirms that the agreed journeys work together. People can hold multiple roles, but an unresolved decision should never have an anonymous owner.
Make the release decision evidence-based
Before launch, the team should be able to demonstrate that:
- Visitors can complete the priority corporate and shopping journeys on mobile.
- Published product information has been checked by its responsible owner.
- Successful and failed payments, plus enquiry delivery, have been tested.
- Normal and failure behaviour for integrations has an assigned owner.
- Existing URLs, internal links, language switching and necessary redirects have been checked.
- Measurement corresponds to business actions, with unresolved gaps documented.
- Editors have received training and understand the scope of initial support.
After release, check operational flows first, then review search visibility and customer behaviour over suitable periods. Prioritise issues by impact: a payment failure and a minor visual inconsistency should not share the same urgency. Give each issue an owner and a date for checking the resolution.
When discussing web design and development alongside ecommerce consulting with WeAreMedia, bring the current site, representative products and your two most important customer journeys. Those inputs make it easier to define a useful scope and an accountable handover, rather than stopping at an attractive design concept.