When a project goes live, the finished result is the part everybody sees.
A new website. An ecommerce store. A campaign. A new customer journey. Something that looks polished, works properly and hopefully appears as though it was always meant to be that way.
What is less visible is everything that happened before it.
The conversations. The questions. The research. The ideas that were explored and discarded. The details somebody spotted at the last minute. The decisions that moved backwards before they moved forwards.
So we thought it would be useful to go behind the scenes at Dancing Badger and explain what actually happens when we take a digital project from an initial brief through to launch.
Not every project follows exactly the same path.
A website project is different from an ecommerce build, and both are different from a marketing campaign.
But the thinking behind them has a lot in common.
The project starts before anybody starts designing
One of the easiest mistakes in digital work is to begin with the output.
“We need a new website.”
“We need to improve our SEO.”
“We should run Google Ads.”
“We need an ecommerce store.”
Those may eventually be the right answers.
But first we need to understand the question.
What is the business trying to achieve?
Who are the customers?
What is working already?
What is getting in the way?
Is there a technical problem, a visibility problem, a conversion problem, a commercial problem — or several of those things happening together?
That initial understanding shapes almost everything that follows.
Because if we misunderstand the problem at the beginning, there is a very real risk of delivering the wrong solution extremely well.
There is a process. But it isn’t a production line.
Clarify the business objective, audience, existing challenges and what a successful outcome should look like.
Review the current position, available data, competitors, customer journeys and wider digital environment.
Agree priorities, scope the work and decide how the different parts of the project need to fit together.
Develop structure, user journeys, content direction and the ideas that will form the experience.
Turn the thinking into something visual, usable and appropriate for the people who will actually use it.
Develop, configure and integrate the technical parts while continuing to test assumptions from earlier stages.
Check content, functionality, devices, journeys, tracking and the details that determine whether the finished project works properly.
Put the work in front of real users, measure what happens and use that information to decide what comes next.
A brief tells us where to start — not necessarily where to finish
Clients normally come to us with an idea of what they need.
Sometimes that idea is already very well developed.
Sometimes the brief is effectively a problem that still needs turning into a project.
Both are perfectly normal.
Our job at the beginning is not simply to write down everything we have been asked to do and begin producing it.
We need to understand why it is being requested.
A client might ask for a redesign when the underlying issue is actually poor navigation.
They might want more website traffic when the bigger opportunity is improving the proportion of existing visitors who enquire.
They might want to advertise a particular service when search behaviour suggests customers describe that service in a completely different way.
Challenging the brief does not mean ignoring what the client wants.
It means making sure the project being built is connected to the outcome they actually care about.
Research is how we reduce expensive guesswork
Before making important decisions, we want to know as much as we reasonably can about the environment the project is entering.
That may involve existing website data.
Search behaviour.
Competitors.
Existing customer journeys.
Advertising performance.
Ecommerce data.
Previous content.
Or simply conversations with people inside the business who understand the customers better than any dashboard ever could.
The purpose is not to delay the creative work with endless research.
It is to make the creative and technical work better informed when it begins.
The earlier we understand the real problem, the less time everybody spends solving the wrong one.
The right specialists need to be involved before their ‘stage’ begins
Digital projects can look very tidy on a project plan.
Strategy first.
Then design.
Then development.
Then content.
Then SEO.
Then analytics.
Real projects are rarely that neat.
A developer may spot a technical implication while something is still being designed.
An SEO specialist may identify an important search opportunity before the site structure is agreed.
A designer may notice that the planned content hierarchy does not make sense visually.
Analytics may show that users behave very differently from the way everybody assumed.
Account management may bring context from the client that changes how a decision should be approached.
That is why collaboration matters.
The objective is not to have everybody involved in every decision.
It is to make sure the right expertise can influence the project while there is still time for that expertise to make a difference.
Good digital work is rarely the product of one discipline.
Business context
Keeping the project connected to objectives, priorities, decisions and what is actually happening inside the client’s organisation.
Evidence
Looking at performance, opportunities, audience behaviour and the information that should influence the direction of the project.
Experience
Turning objectives and information into journeys, layouts and interfaces that make sense to the people using them.
Language
Making sure the project communicates clearly while considering what customers search for and what they need to understand.
Delivery
Turning the planned experience into something robust, manageable and technically capable of doing what the project requires.
What happens next
Tracking what users actually do once the project is live and using that information to challenge assumptions and identify improvements.
The point of bringing different disciplines together is to improve the decision, not make the process unnecessarily complicated. Clear ownership still matters. So does knowing when specialist input is useful — and when somebody simply needs to make the call and move the project forward.
Design is where strategy starts becoming visible
By the time a project reaches design, a significant amount of thinking may already have happened.
The audience.
The objectives.
The structure.
The journeys.
The actions we want people to take.
Design turns those decisions into something people can actually experience.
That is why we do not see design as decoration added after the strategy has been completed.
A design decision can change how easy it is to understand a page.
It can alter what somebody notices first.
It can make an important action obvious — or practically invisible.
And sometimes seeing the strategy represented visually exposes a problem nobody had noticed while it existed only as words on a document.
That feedback is useful.
Projects should be allowed to improve as they become more tangible.
Development is not where the thinking stops
Once a design has been approved, it can be tempting to think the difficult decisions have been made and development is simply the process of assembling them.
It rarely works like that.
Development introduces another set of questions.
How should the content be managed?
How does something behave on a smaller screen?
What happens if the client adds significantly more content later?
How should different systems communicate?
What happens when information is missing?
How do we make the feature maintainable rather than merely making it work today?
This is where the experience of people working across website development and ecommerce becomes important.
Good development is partly about writing the code.
It is also about anticipating what the project will need after launch.
Content, SEO and tracking are not jobs we want to discover at the end
Some of the most expensive project problems begin with the phrase: “We’ll sort that out later.”
Content is one example.
A layout that looks perfect with three lines of placeholder copy may behave very differently when the real information arrives.
Search is another.
If SEO only enters the conversation after the structure and URLs have been finalised, opportunities may already have been missed.
The same is true of analytics.
Knowing what should be measured before launch is considerably better than launching first and trying to reconstruct the missing data afterwards.
This is one of the reasons DB Analytics and wider performance measurement are increasingly connected to the work we do.
If success matters, we need a way to recognise it.
Launch day should not be the first time we ask how we are going to know whether the project worked.
Testing is where we deliberately look for problems
By the time a project is close to launch, everybody involved has normally spent a lot of time looking at it.
That familiarity can be dangerous.
You know where the button is, so you stop noticing whether it is obvious.
You know what a field means, so you forget somebody else may not.
You have seen the same page dozens of times, so your brain quietly corrects a typo every time you read it.
Testing means deliberately changing perspective.
Does it work technically?
Does it work across devices?
Does the content make sense?
Do forms and ecommerce journeys behave properly?
Are the important actions measurable?
And can somebody who has not spent weeks inside the project understand what they are supposed to do?
Ready to launch means more than “the page loads”.
Review navigation, user journeys, calls to action, readability and how the experience behaves across different screen sizes.
Check real copy, imagery, links, page titles, product information and the details users will actually encounter.
Test forms, ecommerce journeys, integrations, interactions and the technical behaviours the project depends upon.
Confirm that the important actions can be tracked so the team has useful information once real users arrive.
Then comes the part everybody sees: launch
Launch is an important moment.
It is the point where weeks or months of decisions finally become something customers can use.
But internally, we do not really think of it as the finish line.
It is the moment the project starts receiving a kind of feedback no workshop, prototype or staging site can fully reproduce: real behaviour from real users.
People may behave exactly as expected.
Or they may reveal something none of us anticipated.
A page we expected to be important may receive very little attention.
A secondary route may become one of the strongest conversion journeys.
Search behaviour may shift.
An advertising campaign may expose a weakness on a landing page.
Customers may repeatedly ask a question the new website still does not answer clearly enough.
That information is not evidence that the project failed.
It is evidence that we now know more than we did before launch.
Launch gives us something planning never can: real behaviour.
The project moves from a controlled development environment into the real world.
Watch how people arrive, what they engage with and where journeys perform differently from expectations.
Combine analytics, commercial results, customer behaviour and client feedback to understand what the signals mean.
Decide what deserves changing, testing or developing next — then continue the cycle.
Good project management is partly about keeping all of that connected
With several disciplines contributing to a project, somebody also needs to keep sight of the whole thing.
Decisions need recording.
Dependencies need spotting.
Questions need getting to the right person.
Client feedback needs translating into clear actions.
Scope, priorities and deadlines need managing without allowing the project to become purely about administration.
That coordination is less visible than a design or a piece of development, but it has a significant effect on the quality of the finished work.
A project can contain plenty of talented individual work and still struggle if those pieces are not connected.
The process matters, but so does knowing when to adapt it
There is comfort in a perfectly defined process.
Step one.
Step two.
Step three.
Never go backwards.
Digital projects do not always behave like that.
Sometimes research changes the brief.
Sometimes design raises a strategic question.
Sometimes development reveals a better approach.
Sometimes testing exposes something that needs taking back a stage.
The process exists to give the project structure, not to prevent people from responding intelligently when new information appears.
Knowing when to follow the process — and when the project has given you a good reason to revisit something — is part of the experience an agency is there to provide.
What clients see is the outcome. Our job is everything behind it.
Most clients do not need to be involved in every internal conversation.
They should not need to know every technical decision or watch every iteration taking place behind the scenes.
But they should understand the important decisions, know why recommendations are being made and have confidence that the different parts of their project are connected.
That is ultimately what the process is there to achieve.
Not complexity for the sake of complexity.
Not endless meetings.
Not a rigid sequence of agency terminology.
A way of taking an objective, bringing the right expertise around it and gradually turning it into something useful.
The finished project might look simple. Getting to the right kind of simple usually takes a lot of thinking.
Research, strategy, design, development, content, data and client knowledge all influence the result. The value is not simply completing each stage — it is making sure those stages inform one another.
The exact process will continue to change.
The technology we use will change.
The platforms will change.
And, as we discussed in our article on how AI is changing the way we work at Dancing Badger , some of the tasks involved in delivering digital projects are already becoming faster and more automated.
What matters is that the purpose of the process stays the same.
Understand the problem properly.
Bring the right people to it.
Make informed decisions.
Build carefully.
Measure what happens.
And keep improving.