We started IDESIGN (then Inspired Design) in 2011 with no clients, no portfolio, and an idea that strategy and design should work together from the start. Four years and fifty-something projects later, we have clients, a portfolio, and the same idea. But we've learned a few things along the way that we didn't expect.
What You Need to Know
- Most project failures aren't technical, they're failures of understanding, scope, or communication
- The patterns that make projects succeed are boringly consistent across industries and sizes
- Design and strategy aren't phases. They're disciplines that need to be present throughout
The Patterns
Fifty projects is a decent sample size. Not huge, but enough to see what repeats. These aren't theories. They're patterns we've watched play out, sometimes painfully, across public sector organisations, enterprises, and community groups in New Zealand.
1. Understand the Problem Before You Build Anything
This sounds so obvious it shouldn't need saying. But it's the single biggest factor in whether a project succeeds or fails.
52%
of projects experience scope creep
Source: PMI Pulse of the Profession, 2015
Scope creep doesn't happen because clients are unreasonable. It happens because the problem wasn't understood well enough at the start. When you rush through discovery to get to the "real work," you build the wrong thing. Then you rebuild it. Then you argue about whose fault it is. We've seen this happen to other teams. We've had it happen to us, early on, before we learned to slow down at the beginning.
Now we won't start building until we can explain the problem back to the client in plain language and they say "yes, that's it." That conversation takes time. It saves more.
The most expensive line of code is the one that solves the wrong problem. We've learned to spend more time making sure we understand the problem than most teams spend on the entire discovery phase.
Isaac Rolfe
Managing Director
2. Put People at the Centre (And Mean It)
Every project proposal says "user-centred design." Most of them mean "we'll do some wireframes and show them to the project sponsor."
Putting people at the centre means talking to the people who'll actually use the system. Not their managers. Not the procurement team. The operators. The case workers. The people who'll open this thing at 8am and close it at 5pm.
We've built systems that looked perfect in stakeholder reviews and fell apart in user testing. And we've built systems that stakeholders questioned but users loved. The difference was always whether we'd spent time with the right people.
Rainui is relentless about this. He'll push back on a timeline if it means skipping user research. He's right to.
You can't design for someone you've never met. User testing tells you whether the thing actually works.
Rainui Teihotua
Chief Creative Officer
3. Deliver on the Day
This one's simple. When you say it'll be done on a date, it needs to be done on that date. Not "mostly done." Not "done except for a few things." Done.
We've lost count of the number of clients who've told us their previous vendor missed deadlines. It's so common in this industry that clients build buffer into their timelines assuming we'll be late. We try very hard not to be. That means scoping honestly, even when it means a longer timeline or a smaller scope than the client hoped for. It means saying "we can't do all of this by that date, but we can do this subset" instead of saying yes and hoping for the best.
Reliability isn't glamorous. But it's the thing clients remember.
4. Function and Form Together
This is the founding principle of IDESIGN and it's held up across every project. When strategy and design work together from the start, the output is better. Not marginally better. Fundamentally better.
When Isaac scopes a project without Rainui's input, the architecture is sound but the experience can be an afterthought. When Rainui designs without Isaac's constraints, the experience is beautiful but might not be buildable within budget. Together, the architecture serves the experience and the experience respects the architecture.
We've structured our entire team around this. Developers and designers work together, not in sequence. The designer isn't handed a spec to make pretty. The developer isn't handed a mockup to implement. They're both in the room solving the same problem.
5. Honest Scoping Is a Competitive Advantage
Early on, we lost a few pitches because our estimates were higher than competitors'. That stung. But then we watched those competitors deliver late, over budget, or with a fraction of the promised features.
We scope to what it actually takes. If a project needs six months, we say six months. If the budget only covers three months of work, we say what three months gets you and let the client decide. No padding, no sandbagging, but no fantasy timelines either.
Clients have started coming to us specifically because they trust our estimates. That trust took years to build and it's worth more than any individual project.
What We Got Wrong
We're not writing this as if we figured it all out. We didn't. Early projects, we underscoped. We said yes to timelines we shouldn't have. We skipped user research when budgets were tight. We learned these lessons by getting them wrong first.
The difference between year one and year four isn't that we stopped making mistakes. It's that we stopped making the same ones. And we built processes that catch the patterns before they become problems.
Looking Forward
Fifty projects. It's a milestone worth marking, even if we're not the type to throw a party about it. The work is getting bigger, the problems more interesting, the clients more ambitious. Enterprise web applications, not just websites. Systems that genuinely change how organisations operate.
The foundation stays the same. Understand the problem. Put people at the centre. Deliver on the day. Function and form, together, from the start. Four years in, we're more convinced of these principles than when we started. Not because they're clever, but because they keep working.