At the start of this year, our largest project was a six-month enterprise build for a NZ government agency. By the end of the year, we're delivering a multi-country grant management system for an international sports organisation and a digital transformation project for one of New Zealand's most recognised retail brands. The projects got bigger. So did we.
What You Need to Know
- IDESIGN's work shifted decisively from web development to enterprise platform delivery in 2017
- International project delivery introduced new challenges around multi-country requirements, time zones, and distributed stakeholders
- The team grew with an engineering lead to handle increasing technical complexity
- A delivery philosophy is crystallising around three principles: understand the business problem deeply, put users at the centre, and build systems that can evolve
What Changed This Year
The shift didn't happen overnight. If we're honest, it's been building since we wrote about the five-page website dying for enterprise back in 2015. Every year since, the projects have been larger, more complex, and more interesting.
But 2017 was the year the shift became definitive.
Enterprise platform delivery. The systems we're building now aren't websites with some dynamic functionality. They're platforms that hundreds of people depend on daily. Grant management across the Pacific. E-commerce transformation for a major retailer. Internal tools that replace entire business processes. The stakes are different when someone's job depends on the thing you build.
International clients. Working with an international sports organisation meant managing requirements across multiple countries, coordinating with stakeholders in different time zones, and designing for users with vastly different digital contexts. It stretched our process in ways that NZ-only work didn't.
Team growth. We brought John Li on as engineering lead this year, and the impact has been immediate. Technical architecture has its own champion. Code quality is more consistent. Our estimates are more accurate because they're informed by someone whose full-time job is understanding the technical landscape.
What We Learned
Bigger projects need more discovery
On a six-week website build, you can hold the entire scope in your head. On a six-month platform build, you can't. The assumptions you make in week one become constraints in month four. Wrong assumptions become expensive rework.
We've invested more in discovery this year than any previous year. Longer workshops. More user research. More time mapping existing processes before proposing new ones. The upfront investment is larger, but the downstream certainty is worth it.
We used to do discovery in two days. Every additional day of discovery has paid for itself ten times over in delivery.
Isaac Rolfe
Managing Director
Process matters more than talent
Small teams can run on talent and communication. When the whole team is in one room and everyone knows the plan, you don't need much process. As projects grow and teams grow, the communication overhead increases faster than you'd expect.
We've formalised things this year that used to be informal. Architecture documentation. Sprint planning. Code review standards. Technical decision logs. None of it is bureaucratic, all of it is practical. The documentation exists because someone needed the information and it wasn't in their head.
Users are the same everywhere
The international project taught us something we should have known: a frustrated user in Fiji looks exactly like a frustrated user in Auckland. They click the same confused places. They abandon the same broken forms. They build the same spreadsheet workarounds.
Good design principles don't have a geography. What changes is context: connectivity, digital literacy, cultural expectations around formality and communication. The design principles stay the same. The application of those principles adapts.
We designed the same interface for users in five countries. The research told us the same thing in every location: don't make me think, don't make me wait, and don't make me guess what happens next.
Rainui Teihotua
Chief Creative Officer
The Delivery Philosophy
After six years of building things together, our delivery philosophy is becoming clearer. Not because we wrote it on a wall, but because we've seen what works and what doesn't across dozens of projects.
Understand the business problem before proposing a solution. The brief is rarely the real problem. Discovery is where we find the actual need, and it's usually bigger, more interesting, and more valuable than what was initially described.
Put users at the centre, not features. A feature list is a means to an end. The end is people being able to do something they couldn't do before, or do something they could do but faster, better, and with less frustration. Design for the person, build for the requirement.
Build systems that can evolve. The project doesn't end at launch. The system will need to change, grow, and adapt. Architecture, code quality, and documentation all serve the same goal: making the next change possible without breaking what exists.
These aren't original ideas. They're not a manifesto. They're just what we've found actually works when the projects are complex enough to punish the alternative.
What's Next
We're heading into 2018 with a stronger team, bigger projects, and a clearer sense of what IDESIGN is becoming. The delivery capability has outgrown the brand, if we're being honest. What started as a design studio is now an enterprise delivery team with a design sensibility.
The question we're sitting with is whether IDESIGN, the name and the positioning, still captures what we actually do. It made sense when we were building websites. It's less obvious now that we're building platforms for international organisations.
Something needs to evolve. We're not sure what yet. But the work has changed, and the way we talk about the work should probably change too.
More on that in the new year.