A new website project can turn into a long discussion about appearance. Someone shares a competitor’s homepage, another person wants animations, and the marketing team has a few ideas for the mobile layout.<\/p>\n\n\n\n
They can wait a little.<\/p>\n\n\n\n
Start by working out what isn’t working for the business today. The new website should address that problem.<\/p>\n\n\n\n
A new design won’t automatically fix any of those problems. These are the things worth sorting out before development begins.<\/p>\n\n\n\n
1. Work Out What’s Actually Wrong With the Existing Site<\/strong><\/p>\n\n\n\n Start with the complaints people have been making.<\/p>\n\n\n\n A consulting firm might receive plenty of website traffic but very few inquiries. Its service descriptions may be unclear, or incoming leads could be landing in the wrong inbox. A redesigned homepage won’t fix those issues on its own.<\/p>\n\n\n\n Online stores could have different problems. Staff are changing stock levels manually, product pages leave out details buyers need, and comparing items on a phone is a frustrating experience.<\/p>\n\n\n\n Write down the issues before putting features into the project brief. Use that list to shape the project brief and evaluate each proposed feature against an actual business need.<\/p>\n\n\n\n 2. Don’t Approve a Vague Project Brief<\/strong><\/p>\n\n\n\n A brief that says \u201c10-page responsive business website\u201d leaves plenty of room for disagreement.<\/p>\n\n\n\n Does the site need a content management system? Who will update the pages? Are customer accounts involved? What happens to the old URLs? Will the website connect to a CRM or another internal system?<\/p>\n\n\n\n These details can change the amount of work involved.<\/p>\n\n\n\n Content migration is a good example. Copying text across 15 ordinary pages is one thing. Moving thousands of product listings with images, prices, variants, and existing URLs is another.<\/p>\n\n\n\n Get the scope clear before comparing proposals with a web development company<\/a>. Otherwise, a feature you assumed was included may arrive as an additional cost later.<\/p>\n\n\n\n 3. Choose What Makes It Into the First Release<\/strong><\/p>\n\n\n\n It is easy for a first website release to become much bigger than the original project.<\/p>\n\n\n\n An online store may eventually need subscriptions and a mobile app, depending on the requirements of its e-commerce website development<\/a> project. A service company might later want customer logins or an appointment dashboard.<\/p>\n\n\n\n This doesn’t mean every feature belongs in version one. <\/p>\n\n\n\n Make sure visitors can find information and complete main tasks the site was built for. Businesses can then decide what deserves attention in the next release.<\/p>\n\n\n\n Only spend money on the ones the business has a reason to build now.<\/p>\n\n\n\n 4. Check Which Systems the Website Must Connect To<\/strong><\/p>\n\n\n\n The customer sees the finished page. Businesses still have to manage everything that happens behind the scenes.<\/p>\n\n\n\n Take a business that sells the same products online and from a physical store. Both needs accurate stock information. If the systems update at different times, a customer could order an item that’s already been sold.<\/p>\n\n\n\n Systems behind the sales channels should work together.<\/p>\n\n\n\n Identify the systems that send and receive data. <\/p>\n\n\n\n Booking software and CRM connections need same attention. Decide what the website should do if a reservation fails, a payment remains pending, or a customer update doesn’t go through. <\/p>\n\n\n\n 5. Work Out What the Website Will Cost Over Time<\/strong><\/p>\n\n\n\n A cheaper quote isn’t necessarily the better deal. <\/p>\n\n\n\n One may include content migration and post-launch support. Another may cover only the initial build. The initial quote may leave out recurring expenses such as hosting software licenses.<\/p>\n\n\n\n Go through the proposal with the developer and clarify which tasks are covered.<\/p>\n\n\n\n That doesn’t mean the most expensive proposal is necessarily the better choice. A small business with straightforward needs could manage perfectly well with an established platform instead of funding a custom system.<\/p>\n\n\n\n The sensible comparison is between the work each proposal delivers and the costs the business will continue to carry after launch.<\/p>\n\n\n\n 6. Keep the Mobile Experience in the Project Scope<\/strong><\/p>\n\n\n\n Mobile design shouldn’t be a final adjustment once the desktop version has been approved; it should be considered from the beginning of the website design process<\/a>.<\/p>\n\n\n\n A popup could cover the contact form on a phone. Checkout page might make it difficult to enter delivery details. <\/p>\n\n\n\n