# How a Design Project Actually Runs: Why We Don't Save the Website for the End > Published 2026-07-30 ยท Canonical: https://goodglyph.com/en/blog/how-a-design-project-actually-runs The classic model is: the designer disappears for a few weeks and comes back with a finished website. It sounds clean and it fails predictably. Here is the alternative, what you see at each step, and just as importantly, what gets asked of you. The classic shape of a design project looks like this: a conversation at the start, the client sends the content, the designer disappears for four or five weeks, then returns with a finished website. It is tidy, it is easy to sell, and it fails predictably, because it moves the entire conversation about direction into the one moment when changing anything costs the most. We work differently, with several checkpoints along the way, and this article explains why, what you see at each of them, and what gets asked of you. That last part matters more than it sounds: a process built on checkpoints only works if there is someone on the other side actually looking. ## Why the big reveal is the worst moment for feedback When you see a finished website for the first time, you are looking at hundreds of decisions already made: the page structure, the order of sections, the tone of the copy, the visual direction, how navigation works. If one of the foundational decisions is not the right one, everything built on top of it wobbles with it. The problem is not that you have objections. Objections are useful, they are the reason you are in the project at all. The problem is when they arrive. A structural change discussed at the sketch stage costs an hour. The same change discussed on a built site costs days, because copy gets rewritten, pages get redrawn, and sometimes development gets redone. The decision is identical. The price of it is not. There is a second effect we see often. At a final reveal, the client feels pressure to react on the spot, to something that visibly took a lot of work, and either says "I like it" to avoid giving offense or latches onto one small detail because it is the only thing they feel entitled to comment on. Both versions hide the feedback that would have mattered. ## What you see at each checkpoint The stages below are the ones we use on website projects and, with small differences, on visual identity work. **Strategy and direction.** Before any pixel, we settle who the project is for, what it has to achieve, and how that gets measured. This is also where you see the first theme directions, not one: two or three different approaches with the reasoning behind each. It is the cheapest possible moment to say "not this one." **Structure, as a sketch.** Wireframes: what sections each page has, in what order, what each one does. No color, no nice typography, deliberately. The point is to discuss logic without aesthetics getting in the way, because those two mix very easily and should not. **The design of the key pages.** Not the whole site, but the pages carrying the weight: usually the home page and one representative inner page. This is where the palette, the typography, and the shape of the system get settled. Once those are approved, the remaining pages become applications of the same system rather than new decisions. **The build, in pieces.** We do not disappear until the end. You see intermediate versions you can open and try, which catches misunderstandings while they are still small. **Launch and the period after it.** Going live, the checks, training where it is needed, and the stretch where the things only real use reveals start showing up. What gets caught at each stage is fairly predictable, in our experience. At the direction stage, misunderstandings about the audience surface: a client says "I want something modern," then sees two directions side by side and realizes their customers actually need something reassuring rather than modern. At the structure stage, the missing things appear: an FAQ page for the question people phone in three times a week, a pricing section the client had been avoiding out of reflex. At the key-page stage, tone gets settled. And during the build, the real cases show up: long product names, copy that does not fit, situations nobody had thought about. We described these stages from the angle of what goes into them, with costs, in [what goes into a five-figure website](https://goodglyph.com/en/blog/what-goes-into-a-five-figure-website). Here we care about something else: what gets decided at each step, and by whom. ## What is asked of you, stage by stage The part most agencies leave out of the first conversation, even though it is half the reason projects run late. - **At strategy:** honest answers about the business, not the ones that sound good. Who buys from you, what they ask before buying, what you have tried that did not work. - **At structure:** a careful read of the wireframes and the question "is anything missing that my customers always ask for?" This is the moment when additions are cheap. - **At design:** a response about direction, not about details. "I don't recognize myself in this tone" is useful feedback at this stage. "Move the button two centimeters" is not, yet. - **During the build:** the real content, on time. The copy, the photos, the access credentials. It is the number one cause of delay, in our projects and, from what other suppliers tell us, in general. - **One person who decides.** Consult whoever you like, but someone has to give the final answer. Projects with three decision-makers who have not spoken to each other are the ones that stall. None of this requires design skill. It requires knowing your business, which is exactly the thing we do not have and the reason you are in the process. ## Why fewer revisions is the symptom, not the goal People often say a good process means few revisions. True, but the causality runs the other way. Heavy revision cycles are not an execution problem, they are the signal that alignment happened too late. When a client sees the direction at the right moment, corrections take a few sentences, at the stage where they cost nothing. When they see it at the end, those same corrections become revision rounds, because the only material left to work with is the built thing. This changes the nature of the feedback too. In a checkpoint process, the question we ask you is not "do you like it?" but something specific to the stage: does this direction match how you talk to your customers? is a section missing that you need? Specific questions get specific answers. "Do you like it?" gets politeness. ## The counter-argument, said honestly A process with checkpoints asks more of your time than one with a single reveal. It means a few more conversations, a few things to read, and decisions to make along the way. There are clients who do not want that, who would rather delegate entirely and see the result at the end, and that is a legitimate preference. We tell them the same thing every time: we can work that way, but the risk moves. Without checks along the route, the chance that the result does not resemble what you had in mind goes up, and end-stage corrections are the expensive kind. The choice is yours, as long as it is made knowingly rather than discovered in the final week. The second counter-argument, equally honest: checkpoints can become a problem themselves if they turn into meetings without decisions. A checkpoint that ends in "let us think about it" three times running is not collaboration, it is postponement, and we will name it as such. ## What changes when the client is in the process The effect we notice most often is not speed, it is confidence in the result. A client who watched the direction take shape knows why it looks the way it does, can explain to someone else in the company why it looks that way, and does not wake up a month later wondering whether they made the right call. It is also why [the questions you ask before choosing an agency](https://goodglyph.com/en/blog/how-to-choose-a-web-design-agency) should include one about process: how many checkpoints are there, what do I see at each, what is expected from me. A supplier who cannot answer that concretely is telling you, without meaning to, how the project will go. ## The GoodGlyph take If you take one thing from this article: ask to see the direction early, from any supplier, including us. Not because designers need supervision, but because good decisions get made while they are still cheap, and you are the only person who knows things about the business that we cannot guess. [That is how we work](https://goodglyph.com/en/services/presentation-website): strategy and directions at the start, structure before aesthetics, key pages before the whole site, versions along the way. If you want to see what that looks like on your project, write to us and we will walk you through the stages on your actual case, before any quote. ## Closing A design project rarely breaks on execution. It breaks when the first real conversation about direction happens in the final week. Checkpoints do nothing more than move that conversation to where it can still be answered cheaply. ## FAQ ### How many times will I be involved in a project? Usually at five moments: strategy and directions, structure as a sketch, the design of the key pages, a few checks during the build, and launch. Each needs a short conversation and a decision, not days of work. ### What happens if I don't like the proposed direction? That is exactly why we show it early. At the direction stage a change is discussed in a few sentences and costs nothing, unlike the same change requested on a built site. ### How many revision rounds are included? It depends on the project and it is written into the quote. In practice, though, a checkpoint process reduces revisions by itself, because the uncertainties from along the way no longer pile up at the end. ### Can I delegate completely and only see the final result? You can, but the risk moves: without checks along the way, the chance that the result does not resemble what you had in mind goes up, and end-stage corrections are the expensive kind. We tell you that beforehand, not afterwards. ### Who should give feedback from the company's side? Consult whoever you like, but one person needs to give the final answer. Projects with several unaligned decision-makers are the ones that stall most often. ### Is the process the same for visual identity? Broadly yes: directions at the start, the core system approved before applications, then the extension. The deliverables differ, the logic does not. ## Related - Related service: [A serious site, built end to end, that you own](https://goodglyph.com/en/services/website-prezentare) - [Branding or just a logo?](https://goodglyph.com/en/blog/branding-or-just-a-logo) - [Client Portal or Simple CRM: Which One You Actually Need](https://goodglyph.com/en/blog/client-portal-or-simple-crm) - [Do You Need an App, or a Better Process?](https://goodglyph.com/en/blog/do-you-need-an-app-or-a-better-process)