I like understanding how a product works before deciding how it should look.
For 4 years I've been designing digital products and design systems, from single components to multi-brand ecosystems. My background in industrial design leads me to think about constraints, scalability and consistency before I even open Figma.
I like understanding how a product works before deciding how it should look.
Three projects that show how I work: from problem to system, from system to product.
A few words from people who have worked with me.
Giacomo brings a good balance between attention to detail and big-picture vision. He is particularly good at bringing order to complex systems and at working with designers and developers to turn ideas into concrete products.
Giacomo has a very concrete approach to design systems. He can get into the details without losing sight of the big picture and, above all, he turns complex problems into solutions that are simple to use and maintain.
Working with Giacomo was easy and stimulating. He is curious, precise and doesn't stop at the most obvious solution: he always tries to understand the problem before designing. His contribution improved both the product and the way the team worked.
I like talking about design systems, digital products and new opportunities.
Navigation and homepage weren't guiding users toward purchase. After a usability test and an A/B test with poor results, we rebuilt the homepage following the AIDA model, raising navigation success from 29% to 80%.
Natucain is a German e-commerce brand focused on hair regrowth, built on Shopify.
The navigation wasn't intuitive and the homepage didn't communicate the product's value right away.
The navigation structure wasn't intuitive and the homepage didn't clearly communicate the problem the product solves. As a result, some users left the site before they had even understood its value.
The work therefore split into two directions: making the navigation structure more intuitive, and rethinking the homepage with a more effective communication logic, validating the choices through real tests rather than assumptions.
We tested the navigation with a reverse tree test on 15 users.
For the homepage, a first A/B test on bounce rate, scroll rate and clicks gave no positive results. We therefore redesigned the page following the AIDA model — Awareness, Interest, Desire, Action.
Each correct answer scored +1, while each wrong answer scored -2.
For the homepage, we tested a first redesign with an A/B test, looking at bounce rate, scroll rate and clicks on the main events.
The results weren't positive on any of the three parameters. So we decided to start over and rebuild the homepage following the AIDA model — Awareness, Interest, Desire, Action — giving each section a precise role and repeating the interest and desire blocks after the first call to action.
The first redesign was a useful failure.
Instead of continuing to tweak the page, we went back to the method, giving each section a precise role in the user's journey.
The A/B test had improved neither bounce rate, scroll rate nor event clicks. This led us to change approach: stop moving elements around the page and start over from the method.
We then systematically applied the AIDA model, giving each section a precise purpose within the user's journey.
A negative test isn't a failure: it let us rebuild the homepage starting from method, not instinct.
The new navigation went from 29% to 80% success, with a test score going from -102 to 72 points.
The new homepage immediately communicates the problem the product solves and brings back the key content after the first call to action.
The new homepage makes the problem the product solves immediately clear and repeats the persuasion blocks after the first call to action, also catching users who weren't convinced yet.
Investing in, buying or financing a property in Dubai meant handling separate tools. PRYPCO brings research, investment and mortgages together in a single ecosystem.
PRYPCO is a real estate ecosystem made up of three sub-brands: Blocks, One and Mortgage.
They have different audiences and identities, but they have to feel part of the same family.
Each product has its own audience and visual identity, but still has to be perceived as part of the same family.
The challenge was designing components and screens for three different products, from low-fidelity wireframes to final interfaces, keeping consistency across brands without flattening their identities: same structure, specific palette and typography for each sub-brand.
We started from low-fidelity wireframes to define flows and hierarchies.
We then built a shared design system, with Aeonik, an icon set and a component library used across the three brands.
We then built a shared design system based on the Aeonik type family, a consistent icon set and a component library — buttons, text fields, checkboxes, radio buttons, avatars, toggles and chips — used across the three brands.
From there we moved on to the high-fidelity interfaces for mortgage, fractional investment and property search.
The system includes six dedicated palettes: Corporate, One, Blocks, Services, Mortgage and Rewards.
The token structure keeps each brand's identity without redesigning components from scratch.
Each product keeps its own colour identity while using the same components and the same Aeonik typography.
The token-based structure makes it possible to create new screens and adapt them to the different brands without redesigning every element from scratch.
One system, many voices: the same component library changes depending on the brand that uses it.
A single system for three brands, from the first wireframes to the final interfaces.
The system is now used in production for the fractional investment, property search and mortgage products.
From low-fidelity wireframes to final interfaces, the system now supports the products for fractional investment, property search and mortgages, currently live on PRYPCO.
A single design system for three brands, on web and app. A common base for components, patterns and assets, while keeping each brand's identity.
The digital group brings together several consumer brands, each with its own website and app.
The products have different visual identities, but share screens, features and patterns.
The goal is to create a common base without making the brands all look the same.
The goal is therefore to build a common base without making the brands all look the same.
The design system keeps the same structure and behaviour of components, leaving each brand free to express its identity through colours, typography and other visual elements.
The system starts from a hierarchy of tokens: base values, semantic and responsive tokens, down to components.
This way the same component can adapt to the different brands without being redesigned.
The library includes around 70 components, built in Figma and in code with React and Svelte, and documented in Storybook.
I also created a graphic assets library with the assets used by the brands, catalogued by area and component.
This way, the same component can be adapted to the different brands by working on the tokens, without redesigning it every time.
The library has grown to around 70 components, built both in Figma and in code with React and Svelte, and documented through Storybook.
In parallel I created a graphic assets library that collects all the graphic assets used by the different brands.
Assets are catalogued by area and by component, so they are easier to find, reuse and maintain within the system.
The base is common, while colours, typography and tokens are adapted to each brand.
The same logic applies to assets: a single, organised library makes it easier to find, reuse and maintain the right elements.
Components and pages are published as npm packages and also used in Figma Make to create prototypes based on production elements.
Components share structure and behaviour, while colours, typography and tokens are remapped according to the brand.
The same approach applies to assets: a single, organised library gives everyone a common reference point, avoiding duplicated elements or ones that are hard to find across different files and projects.
Components and pages are also published as npm packages, while designers can use Figma Make to create prototypes based on the same elements that are in production.
Same components, three different brands.
A single shared base for three brands, web and app.
Designers and developers work from the same documented source, while product teams can build new prototypes without starting from scratch.
The graphic assets library also keeps assets organised, accessible and consistent across the different brands.
Designers and developers work from the same documented source, while product teams can build new prototypes starting from an already stable base.
The graphic assets library also makes it easier to find and reuse the right elements, keeping the different brands more consistent.
The system keeps growing following shared conventions: new components and new assets can be added without starting from scratch every time.