CROSS-ENTITY CODEX
[0VERVIEW]
For my second Master's studio at Politecnico di Milano, my team and I worked directly with Intesa Sanpaolo on a brief about communication across their international banks.
Our answer is the Cross-Entity Codex: a living record of how each team actually communicate, so collaborating with another team stops meaning guessing.
TIMELINE & GOALS
2 months. A co-design project with a real client.
MY ROLE
A five-person team and the project where I left the deepest mark. The concept was mine, and so was the visual identity and created the poster campaign end to end (idea and artwork). Research, service architecture and deliverables were shared work.
[THE PR0BLEM]
language barrier is the easy part
Every team has its own way of working, what they put in writing, how fast they reply, when silence means yes and when it means no. None of it is written down anywhere.
So when a team in Serbia works with a team in Egypt, the hard part isn't translation: it's that neither side can see how the other actually communicates.
11
banks
[IBD DIVISION]
12
countries
[IBD DIVISION]
10
languages
[IBD DIVISION]
INTESA SANPAOLO international ECOSYSTEM PICTURE
[THE RISK]
Today CROSS-CULTURAL COMMUNICATION works because of individuals, relationships, trial and error. That's not a system, it's a dependency.
[0UR S0LUTI0N]
Unify the people, not the communication
The Group is unifying under one brand, and the instinct is to make everyone communicate the same way. We designed the opposite.
The Codex unifies people not communication, it protects the fact that they work differently, and makes that difference readable instead of erasing it . One brand, many communication cultures. That distinction is the whole design.
[THE SERVICE]
Four moments, one cycle
A team builds its codex in a facilitated session. When a cross-bank collaboration starts, two teams put their codices side by side, understanding each others, getting insights on how they communicate.
Then it gets used in real work, under real pressure. And when something shifts, the team updates it. Built by the teams themselves, never imposed from above.
[WHAT'S INSIDE]
CODEX CONTENT
A working document splits in two for a reason. The first half is what you hear: how a team sounds, how directly they say things, what words they use that no one outside would decode. The second is what you don't: how information and decisions actually move, what has to be written down, who needs to be asked, when a reply is coming.
You need both, because misunderstanding lives in both. Get the tone right and you can still break a process nobody told you existed. Follow the process perfectly and you can still sound wrong.
[THE M0MENT IT WORKS]
[THE Service purp0se]
Use isn't a session we run
If you look at our service blueprint, one moment isn't there: the actual use of the codex.
That's deliberate. Use isn't a session we run; it's the codex working on its own, with no facilitation and no service in the room. Everything we designed exists so that the most important moment needs nothing from us. A service like this succeeds when it disappears.
[BRAND IDENTITY]
DARK SLATE #507079
FLASH ORANGE #EC8147
MINT CREAM #F2FFF6
COAL BLACK #141517
[C0-DESIGNED WITH INTESA]
We built this with Intesa, with a 2 hours co-design sessions plus a constant back-and-forth with our contacts inside the company.
Their input didn't decorate the concept, it changed it in three concrete way: the adoption through pilot teams, the target, not "every team at Intesa", but the internal communication teams, the ones most exposed to cross-cultural frictiod, and last the content of the codex itself.
[TAKEAWAYS]
Abstract topics need visual answers
When a project is abstract by nature, the easy path is to explain it with words, slides or more talking.
The harder and better one is to make it visible: turn concepts into images, maps, artifacts. And not only in the final output, but in how you communicate while you're still figuring it out.
For a designer that isn't just a practical need. It's the value you bring.
Working with a company is a project of its own
Understanding a real client, their language, their pace, how decisions actually move inside their walls, is a second project you run in parallel with the first. Nobody schedules it, but if you skip it, the design work suffers.
Designing inside someone else's ecosystem
It was the first time I designed a service that isn't standalone, but a piece of something enormous that already exists.
The challenge is the balance: holding on to your identity as a designer and owner of the project, while it lives inside (and must belong to) someone else's.
