A site is approved several times: first the structure is approved, then the prototype, then the design, the functionality and at the end the finished site. At each stage its own decisions are made, and the next stage rests on them. That is why the timeline depends not only on the speed of development, but also on how approval is arranged: how long each one lasts, how many rounds of revisions it contains, and whether the project returns to decisions already made.
If this order is clear from the very beginning, approval stops being a bottleneck. Below, what to approve at each stage, how to collect comments and how to tell the fixing of a mistake from a change of decision.
What is approved at each stage
Structure
At this stage it is decided which pages and sections will be on the site, how they are connected and what is in the menu. This is the cheapest moment for changes: the pages do not exist yet, and their set can be changed in one conversation.
It is worth checking the main things: whether all the services or categories are in place, whether it is clear where a person goes from the home page, and whether there are extra sections. The approved structure becomes the basis for everything else.
Prototype
The prototype shows which blocks will be on the pages and in what order, without the final design. Here the logic is agreed: what a person sees first, where the price is, where the request form is, which questions each block closes.
On the prototype it is convenient to argue about order and content, because colors and pictures do not pull attention away. The order of the blocks is easiest to correct right here.
Design
The design layout adds a visual style to the prototype: fonts, colors, photos, graphics, details. Usually one key page is agreed first, most often the home page, and then the rest are designed after that model.
Here it is important to look not only at the computer version. How the layout looks on a phone is better discussed at this same stage, and not after the build.
Functionality
Forms, quizzes, calculators, a catalog, payment, integrations — everything that works, and not only how it looks. Here the behavior is agreed: where a request goes, what a person sees after sending, how the price is calculated, what happens when there is an error.
These decisions are more convenient to check on a working version, and not on a picture. That is why functionality is often agreed already on the assembled pages.
The finished site
At the last stage the site is checked as a whole: texts, links, forms, display on different screens. This is the time for fixing mistakes and small adjustments, and not for revisiting the structure or the style.
Why one list of comments is needed
Comments sent one by one at different times and in different channels are hard to bring into one picture. One message came in a messenger, the second by email, the third by voice, and two of them contradict each other. So that nothing is lost, they still have to be brought into one list, only later.
It is more convenient to collect the comments at once in one document or table and pass them in one batch after the stage has been reviewed. Then the whole is visible, contradictions are noticeable in advance, and the work on the revisions goes in one pass, and not in ten small ones.
The way of passing them can be any: text, a voice message, a screen recording with comments. I myself break a long recording down into a list of tasks, clarify the disputed points separately and only then make the changes. The main thing is that the comments on one stage arrive together.
For each comment it is useful to give the place (page and block), what is wrong and, if there is an idea, how to fix it. If a revision is important, and not a matter of taste, that is worth noting too.
Why one responsible person on the client’s side
When several people look at a layout, each has an opinion of their own. This is normal and even useful, but if the developer receives comments from everyone directly, he has to choose between them himself. And the choice between the director and the marketer — is not his decision.
So on the client’s side it is better to name one person who collects the colleagues’ comments, removes the contradictions and passes the final list. That same person approves the stage. This does not mean that the opinions of the others are not taken into account: it is simply easier to agree inside the company than through the developer.
It is good when this person can make decisions or get them quickly. If every approval waits for agreement from a manager who looks at the layout once a week, the project will move at his pace.
A mistake or a change of decision
This difference affects the timeline and the estimate, so it is useful to understand it from both sides.
A mistake — is when what was done is not what was agreed. A wrong price, the wrong phone number, a block that was in the layout and disappeared on the site, a form that does not send. Fixing mistakes is part of the work.
A change of decision — is when what was agreed has been done, but now something else is wanted. A new block in an approved layout, a different order of sections after the pages have been assembled, a replacement of photographs that were approved, a new feature. This is a normal part of the life of a project, but it is a new volume of work: it needs to be estimated and agreed before it is done.
The boundary is sometimes not obvious. If you are not sure what a revision belongs to, just ask. It is easier for me to say at once that this is a change and how long it will take, than to sort it out later. All additional work, as stated on the services and prices page, is agreed before it is done.
How many rounds of revisions are normal
There is no exact number, and to promise that one approval is always enough would be dishonest. Usually the revisions at each stage come together over a few iterations, if the comments arrive as a list and the decisions are not revisited.
What drags approval out the most are revisions that change a direction already chosen. Ten small comments in one list are handled faster than one comment that changes the direction of the design. So the large questions are better raised earlier, on the structure and the prototype, and the details left for the design and the finished site.
What a list of comments can look like
An illustrative example for the design stage. The format is convenient to keep in a table that both sides see.
| Page and block | What is wrong | Suggestion | Type |
|---|---|---|---|
| Home, first screen | The heading gets lost on the photo | Darken the photo or move the text | Design revision |
| Services, cards | Wrong price on the second service | Correct according to the current price list | Error in the data |
| Contacts | No directions map | Add a map | New element |
The last column helps to see at once what belongs to fixes and what to new tasks. If the revisions continue after launch, it is convenient to pass them in the same list: that is how an update of a site on Tilda — which page, what to change and which materials to use.
If you are planning a site and want to understand in advance how approval will be arranged in your particular project, describe the task in the quiz on the site. I will reply in person and tell you which stages and approval points you will have.