12 questions to ask before starting a website redesign

website projects that go wrong almost always fail because of unclear expectations at the start — not because the developer was bad or the design was wrong. asking the right questions before you begin saves you time, money, and frustration.

here are the twelve questions worth spending real time on.

about your goals

1. what specific business problem is this redesign solving? "our site looks old" is not a specific problem. "we're getting traffic but the conversion rate on our contact form is below 0.5%" is a problem. "we can't update our own pricing without calling a developer" is a problem. clear problems lead to clear solutions.

2. how will you measure whether the redesign succeeded? define success before you start. more leads per month? higher average order value? reduced time for content editors to publish updates? if you can't measure it, you can't know if the money was well spent.

3. who is the primary user you're designing for? your website serves multiple audiences — potential customers, existing customers, journalists, potential employees, investors. which one is the highest priority? the answer should drive design decisions throughout the project.

about the project scope

4. which pages are in scope and which aren't? get specific. if you have 60 pages and you're only redesigning 15, both you and your developer need to agree on which 15 before any work starts.

5. who is responsible for the written content on each page? this is the most common source of project delays. most developers don't include copywriting in their quotes unless asked. if you're providing content, when? in what format? what happens if it's late?

6. does the site need any special functionality? bookings, payments, member portals, custom configurators, api integrations, multilingual support — these all add scope and cost. list every feature explicitly. surprises mid-project are expensive.

about the technical setup

7. who will own the domain and hosting accounts? you should. always. if you're not currently the registrant on your own domain, this needs to be corrected before the project starts.

8. what platform will the site be built on, and who can maintain it? if the project is built on a framework your developer uses but nobody else in your area knows, you're dependent on that developer forever. ask how easy it would be for another developer to take over maintenance.

9. how will you update content after launch? will you need a developer for every change? is there a cms? does it work on mobile? walk through a hypothetical update (add a new team member, change pricing, publish a blog post) and make sure there's a clear answer.

about the process

10. what does the revision process look like, and how many rounds are included? "unlimited revisions" is a warning sign — it usually means either the price is very high to compensate, or the developer doesn't have a clear process. most professional projects include 1–2 rounds of design revisions and 1–2 rounds of development revisions. know what you're getting.

11. what is the realistic timeline, and what are the major milestones? a site launch date of "6–8 weeks" means different things depending on when design starts, when content is due, and when approvals happen. get a written timeline with milestone dates.

12. what support is available after launch? what happens when something breaks? is there a maintenance plan? what's the rate for ongoing changes? a site that launches well can deteriorate quickly without a plan for ongoing care.

the underlying principle

none of these questions are adversarial. a good developer or agency will welcome them because clear expectations make their job easier too. if someone resists answering these directly, that's valuable information.

nanushi puts these questions at the start of every project. if you'd like to talk through what a redesign would look like for your business, reach out.