Behind the Scenes at Dancing Badger: How We Take a Project from Brief to Launch

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.

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 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.

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.

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?

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.

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 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.