Walk into most enterprise software projects and you'll find two teams working in sequence. The designers make it look good. The engineers make it work. The handoff between them is where good ideas go to die. We've spent five years doing it differently, and the results speak for themselves.
What You Need to Know
- Separating design and engineering into sequential phases produces worse outcomes for both
- Integrating form and function from day one isn't a philosophy, it's a practical methodology that changes how projects run
- The IDESIGN model pairs a Creative Director and a Managing Director on every project, from scoping through delivery
The Handoff Problem
Here's how most projects work. A business analyst gathers requirements. A designer creates mockups. The mockups get signed off. Then they're handed to engineers who discover that half the interactions are technically impractical, the data model doesn't support the layout, and the timeline just doubled.
Sound familiar?
The handoff model treats design and engineering as separate concerns that can be solved in sequence. Requirements, then design, then build. It's neat on a Gantt chart. In practice, it creates two problems that compound.
First, designers make decisions without understanding technical constraints. Not because they're careless, but because nobody told them. The database can't support that query in real time. The third-party API doesn't return that data. The browser can't render that animation at 60fps on the hardware the client uses.
Second, engineers make decisions without understanding user intent. They see a spec and build to it. But the spec doesn't capture why that layout was chosen, what the user is trying to accomplish, or what the fallback should be when data is missing. So they guess. And guessing produces the grey, functional, joyless interfaces that define most enterprise software.
What IDEO Got Right
5x
increase in project success when design thinking is applied from the start
Source: Design Management Institute, 2015
Design thinking isn't new. IDEO published their framework years ago, and it's been adopted (with varying degrees of sincerity) across the industry. But the core insight is sound: the best solutions come from understanding the problem deeply before committing to a solution. That means research, prototyping, testing, and iteration. Not just at the design phase. Throughout.
What most organisations miss is that design thinking isn't a phase. It's a mode of working. And it only works when the people building the thing are in the room while the problem is being understood.
How We Work
IDESIGN exists because Isaac and Rainui couldn't build good things apart.
I can scope a project, architect a system, and manage delivery. The strategy is incomplete without the design perspective.
Isaac Rolfe
Managing Director
I can design interfaces that people love using. But without Isaac's understanding of the business problem and the technical constraints, I'll design something beautiful that can't be built, or that solves the wrong problem elegantly.
Rainui Teihotua
Chief Creative Officer
This isn't a cute origin story. It's the operating model.
On every IDESIGN project, design and engineering are in the same room from the first scoping session. When we run discovery workshops, Rainui is thinking about how the user will interact with the system while Isaac is thinking about how the system will handle the data. Both perspectives shape the questions we ask, the prototypes we build, and the decisions we make.
The result is that technical constraints are surfaced during design, not after. User experience considerations are built into the architecture, not painted on top. And the client gets a single, coherent vision instead of a designed concept and a built compromise.
What This Looks Like in Practice
Scoping. We don't hand off requirements to a designer. The scoping conversation includes both perspectives. Isaac asks about data, integrations, and business rules. Rainui asks about users, context, and emotion. The scope is complete because both lenses are applied.
Prototyping. Early prototypes are designed and built simultaneously. Not pixel-perfect mockups handed to developers, but working prototypes where the design and the behaviour evolve together. Changes in one inform changes in the other.
Review. When we present to clients, we show something that works. Not a flat mockup with a note saying "this will be interactive." An actual prototype that a user can click through, test, and react to. The feedback is richer because the experience is real.
Delivery. Design and engineering stay integrated through delivery. When a developer encounters an edge case the design didn't anticipate, the design response is immediate, not queued for the next sprint. When a design change has technical implications, those implications are understood before the change is committed.
Why This Matters for Enterprise
Enterprise projects are where this integration matters most. Consumer apps can iterate fast, ship, learn, and fix. Enterprise systems serve hundreds or thousands of internal users who depend on the tool to do their job. Getting it wrong means months of resistance, workarounds, and a slow return to spreadsheets.
When form and function work together from the start, enterprise software doesn't just work. People use it willingly. They trust it. They stop building shadow systems around it. That's a different kind of outcome, and it starts with refusing to separate the two things that need each other most.
Five years of projects have taught us that. And it's the reason IDESIGN is built the way it is.