What should the system
understand?
Purpose
Approach
Approach
/ Studio
IFDSGN keeps those decisions connected from the start.
Product strategyProject managementSystem design
01Understand
Start with the work,
not the interface.
Before defining screens or features, we need to understand how the work actually happens — where information comes from, who makes decisions, what creates friction and what the product needs to change.
02Intentional design
Every decision
needs a reason.
We connect every product decision to purpose, domain logic and behaviour before it becomes interface.
What should the system
What should it
make visible?
Domain logic
What decision should
it support?
Behaviour
What changes when
someone acts?
Interface
03Process
One system.
Five working modes.
Understand, Structure, Design, Build and Operate are not handoffs. They overlap, inform each other and change as the product becomes clearer. Intelligence is designed after the domain model — not before.
Understand
Frame the real work
Problem & constraintsStructure
Model objects, states, authority, history and evidence
Domain model & provenanceDesign
Make it actionable
Behaviour & interfaceBuild
Build the product and its intelligence
Working system + domain intelligenceOperate
Learn in use
Evidence & adjustment04Product intelligence
Structure first.
Intelligence after.
We don’t start with the chat. We start with the system.
Intelligence becomes useful when it has something reliable to reason over. We design the domain model, authoritative state and provenance before we design the assistant.
The interface may be conversational, but the intelligence begins much earlier: in the objects, relationships, evidence and context the product already understands — so it can guide the user from inside the system.
Domain → System → Intelligence
Domain
We understand the work — language, constraints and decisions.
System
We model and build the product around that structure.
Intelligence
We build intelligence into the product’s structured context so questions can be answered — and guided — from what the system already knows.
05What We Are
More than design.
More than development.
Complex software rarely fits cleanly inside one discipline. IFDSGN works where product thinking, project management, system design and engineering overlap.
Complex workflows
Multi-step processes where roles, states and exceptions define the product.
Domain logic
Software shaped by specialised language, rules and constraints — not generic templates.
Multi-role systems
Products used by different actors with different permissions, views and decisions.
Operational data
Systems where live information must stay accurate, actionable and trustworthy.