Think before you design: a framework for project success

Here's a scene you'll recognise.

A new brief lands. There's excitement, a bit of pressure, and a clear desire to show momentum. Within days, wireframes are circulating, copy is being drafted, and the design team is deep into concepts. Everyone looks busy. Everyone looks productive.

Then, six weeks later, someone asks why the campaign isn't performing. Or why the new section of the website doesn't quite make sense or why the feature that took three months to build isn't really being used.

The work wasn't bad. The problem was set up much earlier, before a single file was opened.

According to the Project Management Institute, poor requirements management is a primary cause of project failure in nearly 40% of cases. That's not a technology problem or a creative problem. It's a clarity problem, and it happens right at the start. 

The pull towards getting going is completely understandable. Tangible output feels like progress. Blank documents and open questions feels like a delay. Teams that skip the diagnostics end up treating symptoms rather than causes, and by the time that becomes obvious, the budget is half spent.

• Why does this work need to exist?
• Who, exactly, are we building it for?

They sound simple, however, they rarely get proper answers.

Good discovery means looking at a project from four distinct dimensions, and checking that they all hold together.

These aren't separate workstreams. They push and pull on each other constantly. A technical constraint will change how content is displayed. A user insight will reframe the business case. Ignore any one of them and the gap tends to show up at exactly the wrong moment, usually a week before launch, when changing course is painful and expensive.

The teams that navigate this well tend to hold two modes of thinking at once.

Design thinking focuses on empathy, human needs, and creative problem-solving. It helps teams understand the person they're designing for, define their problem accurately, and develop solutions that actually fit. It's where the good ideas come from.

Systems thinking focuses on the broader environment. Where design thinking zooms in on the user, systems thinking zooms out on the organisation. It asks: if we change this, what else changes? If we collect this data, who else needs to know?

Research supports the value of this approach across complex environments. A systematic review published in BMJ Open found that applying systems thinking to service delivery consistently produces better outcomes than addressing problems in isolation. Research from the RISE programme at the Blavatnik School of Government draws a similar conclusion for large organisational systems: change one part without understanding the whole, and the change rarely sticks.

Neither mode on its own is sufficient. Design thinking without systems thinking produces work that doesn't survive contact with the organisation. Systems thinking without design thinking produces operationally sound work that nobody wants to use. The point at which they meet is where good digital projects live.

Systems thinking doesn't need to be a workshop or a methodology. In practice, it's a handful of habits.

It's a developer asking, before a new data field is added to a form: where does this information go afterwards, and does the CRM team know it's coming?

It's a strategist questioning the brief rather than inheriting it: is this assumption still true, or are we carrying something forward from two years ago?

It's anyone on the team asking: this solves the problem in front of us. Does it create a problem somewhere behind us?

Small questions save large amounts of time.

Committing to proper problem-framing before execution isn't slow. It makes the execution faster. Here's what it tends to produce:

• Unified scope. Everyone, from developers to executives, is working from the same understanding of what success looks like.
• Fewer surprises mid-build. Clear requirements mean fewer structural or technical issues that appear at the worst possible moment.
• Decisions you can defend. When a stakeholder wants to change direction based on personal preference, you have a rationale that holds.
• Less rework. Time spent reversing poorly planned decisions is time that was already paid for twice.

Shipping on time is useful. Solving the right problem is the point. The teams that protect the discovery phase, and push back when pressure mounts to skip it, tend to deliver work that holds up long after the launch day announcement is forgotten.

References: 

• PMI, Pulse of the Profession, 2023.
• Carey, G. et al. (2015). Systems science and systems thinking for public health. BMJ Open, 5(12), e009002.https://doi.org/10.1136/bmjopen-2015-009002
• Spivack, M. (2021). Applying systems thinking to education: The RISE systems framework. Research on Improving Systems of Education (RISE).