When discussing Full-Site Editing, focusing on big projects is tempting. Indeed, most websites presented in my Full-Site Editing in The Real World article have larger budgets. And yes, large websites built using block themes, such as Nasa’s, are impressive.
However, most WordPress projects aren’t such large builds. And indeed, over the last few months, my focus has been on smaller projects.
While Full-Site Editing is not a magic bullet that solves all your problems, I’ve seen it significantly speed up smaller projects.
You can save up to a third of delivery time compared to building projects with Classic themes.
But it’s not just the technology. It’s the technology combined with the right project management and delivery approaches that makes all the difference.
To start the series of emails, let’s focus on the big changes that Full-Site Editing brings to the process of building websites.
Speed of building
Even with all the boilerplates, plugins, AI-assistance, and elite 10-finger typing skills you’ll never be as fast building a classic theme compared to a block theme.
That’s just the advantage of using a visual builder that handles many of the low-level details for you.
Because of the nature of block themes, you’ll be able to reuse parts more easily than before. While patterns aren’t fully portable, with some adjustments, they can be brought over from previous projects.
This is not to mention that many high-quality block themes are available for you to either child theme or fork. If you are unsure which way to go, I wrote a guide on whether forking or child theming is the best way, depending on your specific projects.
We are still in the early days of refining processes here, but the speed gains from block-based building will only increase.
Continuous delivery
Traditionally a website project was divided into phases like design, coding, content entry,…
In project management terms, this is known as a waterfall approach. A linear progression where each task must be completed before moving on to the next.
In web design, the client first sees mockups but then not much until the final website is delivered. And that’s when the feedback rolls in–on an already finished project.
To be clear, I’m not against doing mockups. They can be useful to lock down a design direction before building. But they cannot be the only thing that the client sees before they get the final website.
With Full-Site Editing, you can have a rough theme within a day. And hereby share your work earlier. We shouldn’t be afraid to show things that aren’t final.
After all, if you build a house, you’ll see it in every stage of the project as well, and don’t think less of the builders because of that.
This way, you can get the client’s input early and adjust before having to build everything out. While that is challenging and requires higher levels of client training and education, it is worth it.
Because this way you can have an iterative approach. Where you deliver a first go at a page or feature, and then refine until the client accepts the result.
You repeat this process a couple of times, and you’ll end up with the finished project.
Involving the client in the project build
We want our clients to not only feel but also be involved in the process.
And clients can assist with the delivery of the website. While you are building it.
This is a point that some experienced web designers and developers push back on hard. Because traditionally clients are not involved at all in a website build, they just get the final product.
Some also confuse this with meaning that clients should build their own websites. Questioning why they then would even hire a professional, and not just build the whole thing themselves.
The reality is that the overwhelming majority of clients that want a website with a content management system want to manage their content.
And there are many tasks that developers routinely pick up when it comes to content entry that do not require any development knowledge whatsoever.
So why not let the client do the content entry themselves? This:
- Saves time, and therefore money.
- Trains clients early in the use of their website, which they are going to maintain in the future.
- Makes the client feel much more involved in the result–because they are part of making it a reality.
Because a major concern is client disengagement. They are ecstatic about the site when they see mockups. Then there’s a lull while you code the website.
Then everything is ready for the content, which then never comes. The client’s enthousiasm has worn off, other tasks have taken their attention. And they also loathe writing stuff into a Word document, and collecting pictures.
What I’ve seen is that if you curate a great editing experience, and provide a minimum amount of training, clients to very well with content entry.
This leaves you to focus on the critical pages and features. The one that require more than just basic editing skills.
Next week: real-world estimates and clear deliverables
If you’re saying “this sounds too good to be true”, you are half-way right.
This approach of building has an enormous potential for delivering high quality websites faster and at attractive prices.
But it also requires you as the professional to be way more involved in managing the client and the project.
So the exact opposite of disappearing into your ivory tower and coming out with the finished website.
And to make this work, you need two things at the start of every project:
- Estimates that make sense for you and the client.
- Deliverables that are clear for you and the client.
Why this is crucial
Early in my career, I was a project manager at a medium-sized web agency in Luxembourg. And the approach to selling in this agency was to promise The Dream.
In other words, we told that client that all they had to do was sign the contract and send us the money. And a fantastic website would be delivered to them without any other effort.
This meant that the client was very engaged in the beginning, the project’s high point. To start projects, we asked for payment of a third of the total project budget. Needless to say, this motivated them a lot.
Plus, we followed up on that first invoice’s pain with dazzling mockups. This agency had great designers—not really great web designers, but they could produce fantastic mockups.
After getting the design accepted, we switched to coding. Various factors made it so that several weeks passed between the design acceptance and the delivery of the coded website.
This creates two problems:
- You lose the initial momentum of the project. In the meantime, the client has other things to deal with. And often, the website project gets put on the back burner.
- The coded website is not anything new compared to the mockups. Plus this website had no actual content, so it looked poor.
The delivery of the coded website was another milestone, so we invoiced the second third of the total budget.
To make things worse, this is when we asked the client for content. And that’s not only additional work for the client. It’s also work they are not used to, so there is a huge barrier to getting started.
As a project manager, it was my job to follow up with the clients to get content. Because once we had that, we could finish the project, and send the last invoice. And that’s what we as the agency wanted to do.
But what the client wanted to do was not be bothered by us. Often I had to harass clients for weeks to send us content. More often than not, the clients send in some half-baked texts and poor pictures to get me off their backs.
We know how crucial great copywriting and photography are for a website. The visual design is only there to present this information optimally.
Since we designed before having any content and later put in ill-fitting texts and images provided by the client, we ended up with a poor-looking, poor-performing website.
A website that was a far shot from the fancy mockups and big promises made during the sales conversation. And an outcome that was a big disappointment for the client.
And also for the agency. Because this approach this was not conducive to follow-up work or even referrals.
Replacing mockups and requirements with a vision
A website is not a physical object that you can show in its entirety.
If you sell a car, the client can look at it, sit in it, test-drive it, etc. A website has the frontend, but it also has the backend. It has interactive features like forms. It has integrations with other software tools, etc.
That’s why we, as an industry, rely so heavily on mockups. It is one possible way to show the client what the finished product might look like.
However, while being a required piece of the puzzle, design is missing the crucial pieces needed for the success of a website: The desired outcome that the website should produce.
If you build a house, you want to live in it. If you create a donut shop, you want to make donuts and sell them to customers.
We need to look at a website in the same way and define what the purpose of having the website is.
I call this a vision.
What is this vision?
The vision describes what a website should do from the website visitors’ perspective.
It’s not about what you want or what your client wants. It’s what the customers of your client want. And why they want it.
This vision statement is not focused on excessive detail. That comes later. It’s focused on the customers’ intent and how you can match the products or services of your clients with that intent.
Let’s take the example of a yoga studio. As a potential client, I want to:
- Find out that this yoga studio exists.
- Discover the classes that the studio offers.
- Be informed of the different pricing options.
- Get to know the yoga teachers.
- Be able to book a class.
- Get an idea of the studio space.
You can see that this vision can be a list of bullet points or a few paragraphs. Of course, the more detailed you can be in terms of intent, the better.
But you need to resist the urge to:
- Dive into technical details, like which plugin is used for the class schedule.
- Delve into delivery details, for example we’ll need 2 hours of design, and 2 hours of coding.
Because the first is not useful for the client, and the second is not useful for us as professionals.
Instead, jot down everything that comes to mind in the first step. Next, group things together to reduce the total number of items on the list. Then, sort them by order of importance.
Any legal requirements (like an Impressum), of course, are first. Then come the direct money-generating features. Followed up by indirect money-generating features. Move on until you get to the nice to-haves.
The vision is the first document to be created together with the client. This will be the guiding light throughout the entire website creation process. Hopefully, it will also be for future follow-up work.
So what about the deliverables?
With this vision document, the deliverables can be anything that makes sense in achieving the desired outcomes.
If we look at typical deliverables like mockups, structure diagrams, and requirements documents,… these are all things that have to do with the process of building websites. But not the actual product, meaning the website itself.
As we talked about last week, modern WordPress allows you to:
- Build an initial version in a few days or even hours instead of weeks.
- Deliver features continuously rather than all in one go.
- Involve the client during the build process, doing tasks like content entry and design and development in parallel.
So in the case of our yoga studio, you would first focus on the money-making aspects of the website: showing the classes and the booking functionality.
If we keep the big picture in mind, we can come up with better descriptions of our work for our clients. Like seeing the class schedule rather than installing a calendar plugin.
And the desired outcome is the deliverable. Your client should be able to go to the in-progress website, see the class schedule, and book a class.
How you get about achieving this doesn’t matter. What matters is that you can clearly define what your work will achieve to your client. And that your client then can double check that the website indeed does that.
This approach will also help you deliver a better estimation. To provide these features, you’ll do design, do plugin configuration, set up pages on the website, etc.
And assuming you have experience, if you focus on the whole feature, you’ll have a good idea of how long this will take.
However if you split up a features into its different pieces like design, and coding, and content entry, etc. it’s easy to get lost. And that makes the estimates difficult, because all you see is abstract “work”, and not really what that work is designed to achieve.
Deliverables and budget
Every client has a website budget, meaning the maximum amount of money they can spend.
Usually, you come up with a set of deliverables (this many pages, this and that plugin integration, etc.), the number of hours that this will take, and a price.
Then, you start cutting hours here and there until the number on your quote fits with what the client has budget for.
With a vision, the process is different. You know that certain types of websites must have certain pages and functionalities.
So rather than cutting the number of mockups, or pages, or whatever other abstract metric is used to define the work delivered by you, cut down on the complexity of the implementation.
The list of classes with the booking feature can be as simple as a default Page template that lists the classes and a phone number or email to book a class.
Now, this solution has obvious downsides for the client. But it is quick to deliver and therefore cheap.
By focusing on reducing the complexity (and, hereby, production time) of a website, rather than an arbitrary number of deliverables, you can achieve a much better outcome for the client.
And since you will inevitably have to simplify features to account for budgetary constraints, this creates a natural roadmap for future work to improve the website.
But even with a clear vision and deliverables, projects can still get stuck. The most common reason is unclear roles and responsibilities.
In traditional website projects, developers handle everything. But with modern WordPress development and Full-Site Editing, things have changed. Clients can now be more involved in the process, making projects smoother and faster—but only if expectations are correctly set.
The key question is: Who does what, and when?
Without clear roles, projects drag on indefinitely. Clients disappear, content never arrives, and endless revisions creep in.
This week, we’ll look at how to set clear roles and responsibilities in your website projects to avoid delays, scope creep, and confusion.
Why clear roles are so important
With the traditional web development process, the roles seem clear: you do all the work, and the client pays for it.
However, what looks like an obvious division of work is not that obvious.
Because even the web professional takes care of all the tasks to build the website, the client still has to review the work and sign off on it. If there are things to change, the client needs to let the web designer know. In addition, the client also needs to log into the CMS and get familiar with how to update content.
However, clients usually take on an even more involved role than that. Which is something I talked about in the previous emails.
This is a positive change, but it also requires us to change how we handle work division, communicate this to clients, and hold clients accountable.
I’ve found that it is “clear” to me that clients are supposed to do certain things at certain times. However, it’s not as clear to the client.
And that’s a failure on my end, as I never explicitly stated the client’s roles in the project, and what work this entails.
The challenge when it comes to project responsibilities
Establishing clear responsibilities seems simple: Clearly define what you (the professional) will do vs. what the client will do.
But that comes with challenges.
You might consider that “content creation” means providing high-quality copy and images adapted to the design. However, the client might think of that as sending you texts from past brochures and blurry photos, expecting you to make it work.
Then there’s the elephant in the room: nobody likes to get told what to do. Especially not by somebody you are paying, and therefore, in the worst case, perceived as being order takers and not order gives.
So we need to change the relationship from “here’s what you need to do” to “here’s what we will do”. Both parties work together toward that common goal.
In the previous email, I talked about the necessity of having a vision for a project. Once this vision is established, we can move on to its implementation.
And for that, we need a new shared document: a roadmap.
Creating a client-facing roadmap
If you have a formal background in project management, then you are familiar with Gantt charts:
It’s a way to visually represent a project schedule, with the dependencies all mapped out and the current progress marked.
Gantt charts are a fine project management tool but aren’t adapted for client communications.
We need something that can show the milestones, major tasks, and progress without being as complex as a Gantt chart.
The Miro app is one of the tools that you can use to create a roadmap, such as the one above.
It’s pretty simple:
- The columns represent your unit of time. Usually a week, but some companies also use two-week sprints (using the Agile language).
- The arrows above the columns represent key milestones.
- The post-it notes are tasks.
- The color of the post-it notes represents the party responsible for the task.
- Optional: you can use different-sized post-it notes to represent the size of tasks.
This roadmap lists all the tasks that must be taken to transform the vision into reality. It tells you how to do something and when they have to do it.
An important detail is that the weeks represent the timeframe of the entire website project, not just your working time. This is a key differentiator from a Gantt chart, where every day represents a unit of work.
But we know that a website project isn’t something you work on 40 hours a week for weeks on end, from start to finish. Instead, you build something, then there’s some waiting time, then you move on to the next thing, etc.
So, when you plan the project, establish this roadmap together with the client. If they need two weeks for sign-off, then put that in there. The roadmap must be realistic, so it’s best to implement some buffer time, and hit the milestones. Rather than planning tightly, and then end up missing dates.
Again, the importance lies in the timeframe it takes to build a website, not how much time you quoted. Because even if you quoted two weeks of work, it would take at least three to go from kick-off to finished website.
Maintaining the roadmap
The great thing about Miro is that you can invite the client to a board, and they will see your changes. You can also share the board during a video call.
This roadmap isn’t a one-off. Much like the vision, it’s something that you’ll revisit regularly.
Indeed, one of the issues with building something abstract is that clients cannot see the consequences of their decisions. If they request an additional feature in week 2, that will not only mean that more budget is needed, but it will also mean that any tasks scheduled in week 3 will now move to later weeks.
And you can do these changes live while talking to your client on a video call. Because the roadmap has this big-picture focus, all you need to do is add new post-its, move the existing post-its back, etc.
The same applies when the client misses a deadline. Update the roadmap, set a new deadline, and push all dependencies back accordingly.
This roadmap allows you to be very factual. This happened, and now that happened. As simple as that. Which is so different from you calling the client and telling them or writing them about the delay.
It also gives the client a better idea of what will happen. Again, the process of building a website is abstract, so the roadmap gives the client a visual representation of the road ahead and tells them what to expect.
Limitations of a roadmap
The strength of the roadmap, meaning that it is the big picture, is also its weakness.
If you have a project that has very precise deadlines to hit, then the representations of weeks as a column with post-its is not fine-grained enough.
The other downside is that task descriptions must be short. So, the post is just a placeholder; it’s not a precise description of what needs to happen for this task to be considered complete.
So, the roadmap must be backed by a detailed description for each task:
- What are we trying to achieve?
- How do we go about it?
- What are the criteria for considering the task done?
Therefore, it does not replace a task tracking system, such as a Kanban board, or GitHub issues, a Jira, or whatever other tool you use to manage the nitty gritty.
Mapping responsibilities to roles
Depending on the size of your team and the size of your client’s team, you have different people responsible for different tasks. Or it’s just you and the client.
Whatever the situation is, there’s one rule: One person on either side takes the decisions and handles communications.
These two people are responsible for the success of the project. And everything goes through them. They are the success managers of this project, and are there to ensure everybody knows what to do, when, and that stuff gets done.
This is a rigid boundary that you need to enforce.
Too often, I’ve seen company CEOs very involved in the early stages of website builds. They feel that they are paying, so they need to ensure they get their money’s worth. And this is the fun part!
But later, when it comes to creating content, they delegate to this and that employee. When you follow up with the CEO, you are redirected to this or that person.
You do not want this. It’s not your job to keep track of who does what in your client’s company. Or to go on a wild goose chase whenever you need something from the client.
At the same time, when clients contact you, don’t forward them to your developer, designer, or copywriter. If you need information, tell the client that you’ll follow up with them once you’ve gathered it from your internal team.
Now, this doesn’t mean that your team members can’t talk to the client. For example, at enterprise agencies, engineers are in direct contact with clients. But you need to be aware of everything going on to know how the project is progressing.
Getting things done and getting paid
Let’s finish with the important part: you getting paid.
It’s common to have a payment schedule tied to project milestones. As such, these milestones should be noted on the roadmap as well. Getting paid is a normal part of the process; there’s no reason to be shy about it.
Usually, the outstanding balance of the project is paid upon completion. So, what should we do about clients who drag their feet?
There are different ways to go about it.
I’ve seen people recommend that you somehow “punish” the client. Usually, it’s in the form of a delayed project.
That’s the wrong way to go about it, though. The delay in the project when the client misses deadlines is just a natural consequence. It isn’t something “extra” you do to punish them.
This can also backfire, as clients may think that they have more time to meet the new deadline if the project is delayed. Thus, they procrastinate again and risk missing the new date as well.
What I prefer is that you establish a roadmap with the client, you both agree on it, and you invoice according to the planned timeline and not the actual one.
I know this seems weird, and when I first heard about this, I wasn’t convinced as well.
But this is the only way to protect your cash flow. If you are supposed to by paid 5K during the next 6 weeks, then you are planning according to this. If the project is delayed because the client doesn’t deliver, you shouldn’t be the one to suffer the consequences.
If clients want to delay the completion of the project, that’s fine. You get paid, are ready to restart when they come back to you.
This also avoids the old “I finished the website, and it’s live, but the client doesn’t pay” situation. I’ve seen people on X posting how they shut down the hosting of websites for clients who don’t pay. Or do other things sure to anger the client.
Another essential detail is the costs you incur but pass on to the client. Not every hosting provider offers free staging sites. If you buy licenses for software like plugins, you do so during the build, not after launch.
So clarify this to the client, and invoice these costs as close to when they occur, or ideally even before.
Because I’ve heard too many stories from people in the web design space and other industries that work hard and still struggle. All because their clients and customers don’t pay the invoices within an acceptable time frame.
Remember: a business is money in, as in cash in the bank. You can’t pay your bills with the money you will receive, only with the money you have.
Thanks for reading!
These three emails were a change from the more hands-on technical details that I usually send.
Technology alone doesn’t guarantee success. So, it’s essential to reflect on our approaches to project delivery and how these have evolved because of the tools we use.
