Starting a digital project often creates pressure to answer technical questions immediately.
Which platform should we use?
What should the website look like?
Which features should the product have?
Do we need custom software?
Those questions matter, but they are rarely the best place to begin.
Before deciding how something should be built, it helps to understand why it needs to exist, who it needs to serve and what it needs to accomplish.
That does not mean arriving with a perfect specification. In many cases, part of the work is turning an early idea into a clearer direction.
It does mean establishing enough context to make the decisions that follow more deliberate.
1. Define the problem before defining the solution
One of the easiest ways for a digital project to become unnecessarily complicated is to begin with a predetermined solution.
“We need an app.”
“We need to automate this.”
“We need a new website.”
Sometimes those conclusions are correct. Sometimes they are only one possible response to a deeper problem.
A business asking for a new website, for example, may actually be dealing with unclear messaging, difficult content management, poor information structure or a digital presence that no longer reflects the organisation.
A team considering custom software may actually need a better connection between existing systems rather than an entirely new platform.
Starting with the problem gives you room to evaluate the appropriate response.
Ask:
- What is not working well enough today?
- What opportunity are we trying to create?
- What is causing friction?
- Who experiences that friction?
- What would meaningfully improve if the project succeeds?
The clearer the problem becomes, the easier it is to evaluate potential solutions without becoming attached to unnecessary complexity.
2. Understand who the project needs to serve
A digital experience is ultimately used by people.
That sounds obvious, but audience needs can easily become secondary once conversations move towards features, technology and visual design.
Before those decisions begin, establish who needs to use the experience and what they need from it.
For a website, that could mean understanding why different visitors arrive, which information they need and what they should be able to do next.
For an internal system, it could mean understanding the workflows of the people who use it every day.
For a digital product, it may mean identifying the first group of users whose problem the product needs to solve particularly well.
You do not necessarily need extensive audience research before the first conversation.
You do need enough understanding to avoid designing solely around internal assumptions.
3. Define the outcome, not only the deliverable
A deliverable describes what will be created.
An outcome describes what it should help achieve.
The distinction matters.
“Build a new website” describes an output.
“Help prospective clients understand our services more easily and create a clearer route towards enquiry” provides direction.
“Create an internal platform” is an output.
“Reduce the manual work involved in coordinating this process and give the team one reliable place to manage information” begins to explain the purpose.
Clear outcomes become useful decision filters later in the project.
When a new feature, page or technical requirement is proposed, the team can ask:
Does this help us achieve the outcome we defined?
If the answer is unclear, the requirement may need further thought.
4. Separate essential requirements from possibilities
Early project conversations tend to generate ideas quickly.
That can be valuable, but ideas and requirements are not the same thing.
If everything is treated as essential, scope can expand before the core experience has even been defined.
A useful starting point is to separate requirements into broad groups:
Essential
The project cannot serve its intended purpose without these.
Valuable
These meaningfully improve the experience or operation but may not be required for the first version.
Future
These are worth considering, but they do not need to shape the initial release.
The objective is not to remove ambition.
It is to sequence it.
A smaller first version with a clear purpose can provide a stronger foundation than a large first release attempting to solve every possible future requirement at once.
5. Identify the constraints early
Every project operates within constraints.
Budget is one, but it is not the only one.
Others may include:
- Timing
- Existing systems
- Internal capacity
- Content availability
- Technical dependencies
- Stakeholder requirements
- Maintenance responsibilities
- Integration requirements
- Existing brand or platform decisions
Constraints are not necessarily obstacles.
They are part of the design problem.
Knowing about them early allows the project to be shaped around reality rather than discovering important limitations after major decisions have already been made.
6. Understand what already exists
Not every digital project starts from zero.
There may already be:
- A website
- A content library
- Existing software
- Internal workflows
- Third-party platforms
- Brand assets
- Customer data
- Integrations
- Established processes
Before replacing something, understand what is useful about the existing environment.
Some elements may need rebuilding.
Others may need improving.
Some may already solve the problem effectively and simply need to connect more intelligently with whatever comes next.
A thoughtful project does not assume that new automatically means better.
7. Identify what you do not know
Good planning is not about pretending every question has already been answered.
Sometimes the most valuable preparation is identifying the uncertainty.
You may know the business problem but not the right technical approach.
You may understand the audience but remain uncertain about which features belong in the first version.
You may know the existing website is limiting the organisation without knowing whether it needs restructuring, redesigning or rebuilding.
Those are useful things to know.
They tell you where discovery needs to focus.
You do not need a perfect brief
There is an important distinction between being prepared and having everything figured out.
A digital partner should not require you to arrive with every technical decision already made.
If you already knew the exact architecture, interface, technology, feature set and implementation approach, much of the strategic work would already be complete.
A useful starting point is simpler:
Know what you are trying to improve.
Know who it matters to.
Know what a successful outcome roughly looks like.
Know which constraints already exist.
Know which questions remain unanswered.
From there, the direction can be shaped collaboratively.
Discovery turns uncertainty into direction
For projects where significant questions remain, a discovery process can create the bridge between an initial idea and an actionable project.
That may involve examining the problem, audience needs, requirements, priorities, constraints and possible approaches before major implementation decisions are made.
The purpose is not to make the project appear more complicated.
It is to reduce unnecessary uncertainty before complexity becomes expensive.
Start with clarity, then choose the tools
The strongest starting point for a digital project is rarely a technology.
It is an understanding.
What are we trying to change?
Who are we creating this for?
What needs to happen?
What matters most?
What limitations should we design around?
What remains uncertain?
Once those questions become clearer, conversations about design, platforms, software and implementation become much more useful.
The goal is not to eliminate every unknown before beginning.
It is to make sure the project starts by solving the right problem.
If you have a digital idea but are still working out what should actually be built, Astraurae’s Digital Strategy and Discovery work is designed to help shape that uncertainty into a clearer direction.