Sept ans en environnements techniques complexes

Product Designer

Je conçois des outils métier clairs pour des secteurs où la complexité technique est la norme.
Lille · Mobile en France · Télétravail en EuropeLille · Mobile en France · Télétravail en Europe
© 2026 Yibo Sun · Tous droits réservés
Seven years in complex technical environments

Product Designer

I design clear business tools for sectors where technical complexity is the norm.
Lille · Open to relocation in France · Remote across EuropeLille · Mobile en France · Télétravail en Europe
© 2026 Yibo Sun · All rights reserved

Études de cas

Deux études de cas chez Axione · un projet personnel en cours
Page d'accueil du portfolioPUBLICATION LE 30 OCTOBRE
PORTFOLIO PERSONNEL · 2026Mon portfolio 2026 : du moodboard au site responsiveLe processus de conception de ce portfolio : itérations, problèmes résolus et choix de design.FigmaClaude (AI)Étude de cas à venir
© 2026 Yibo Sun · Tous droits réservés

Case studies

Two case studies at Axione · one personal project in progress
© 2026 Yibo Sun · All rights reserved
{{ remainNum }} min{{ remainNum }} min
Axione

Réduire la complexité d'un workflow technique dans un projet télécom

Conception d'un système d'onboarding et de transmission de connaissances pour des collaborateurs non experts dans un environnement à forte charge cognitive.
Conception 0 → 1ArcGISQGISOffice
Date2025
Durée3 mois
Lieu · modeLille · hybride
ContexteProjet DOE, secteur télécom FTTH
RôleChargé d'études techniques — conception du parcours, animation des ateliers, accompagnement des utilisateurs
Utilisateurs6 collaborateurs non experts (4 externes + 2 anciens collègues internes)
Parties prenantesResponsable d'équipe, responsable de projet, chargés d'études seniors
OutilsArcGIS, QGIS, Microsoft Office (Word, Excel, PowerPoint, Teams)
LECTURE RAPIDEL'essentiel en 2 minutes. Désactivez pour lire l'étude complète.
≈ 2 min de lecture
LECTURE RAPIDELECTURE COMPLÈTEVersion complète affichée. Réactivez pour revenir à l'essentiel.
≈ 7 min de lecture
2 j
Temps moyen observé par collaborateur sur les réalisations effectuées après la période d'accompagnement (suivi individuel sur les 3 premiers exercices).
−33 %
Charge experte avant/après sur les projets suivis : 6 jours → 4 jours en moyenne par projet.
6/6
Collaborateurs opérationnels : 4 après 3 suivis, 2 après une session ciblée
20 %
du volume ciblé du dossier de fin de chantier (DOE) délégué
TEAMS · Q/R

Fin 2025, un chantier de fibre optique risquait de ne pas atteindre ses objectifs de production. Le dossier de fin de chantier reposait sur quelques experts, et il fallait plusieurs mois pour devenir autonome sur ce workflow.

Ma mission : rendre 6 collaborateurs non experts opérationnels pendant un renfort de 3 mois.

Résultat : ils réalisaient la tâche seuls en 2 jours, et la charge des experts a baissé d'un tiers.

Le projet en 3 temps

PROBLÈME
Un workflow non linéaire pour produire le dossier de fin de chantier (DOE), peu documenté et transmis à l'oral : plusieurs mois pour devenir autonome, alors que la production prenait du retard.
DÉMARCHE
Entretiens et atelier, deux profils d'apprentissage, puis un parcours en trois temps : process illustré, checklist, modèle QGIS. 4 itérations sur le terrain.
RÉSULTAT
6 collaborateurs sur 6 opérationnels, la tâche réalisée en 2 jours en moyenne, la charge des experts réduite de 33 %.

Les livrables

À retenir

Les experts sous-estiment souvent la charge cognitive des nouveaux utilisateurs.
Tous les utilisateurs n'apprennent pas de la même manière.
Une documentation efficace réduit la charge cognitive, elle ne se contente pas de transmettre.
Axione

Reducing the complexity of a technical workflow in a telecom project

Designing an onboarding and knowledge-transfer system for non-expert team members in a high cognitive-load environment.
0 to 1 designArcGISQGISOffice
Date2025
Duration3 months
Location · modeLille · hybrid
ContextDOE project, FTTH telecom sector
RoleTechnical design engineer — journey design, workshop facilitation, user support
Users6 non-expert team members (4 external + 2 former internal colleagues)
StakeholdersTeam lead, project manager, senior design engineers
ToolsArcGIS, QGIS, Microsoft Office (Word, Excel, PowerPoint, Teams)
QUICK READThe essentials in 2 minutes. Switch off to read the full study.
≈ 2-min read
QUICK READFULL READFull version shown. Switch on to go back to the essentials.
≈ 7-min read
2 days
Average time observed per colleague on tasks completed after the support period (individual follow-up over the first 3 exercises).
−33 %
Expert workload before/after on the tracked projects: 6 days → 4 days on average per project.
6/6
Team members operational: 4 after 3 follow-ups, 2 after a targeted session
20 %
of the targeted as-built file (DOE) volume delegated
TEAMS · Q&A

In late 2025, a fibre-optic project was at risk of missing its production targets. The as-built file depended on a few experts, and it took months to become autonomous on the workflow.

My mission: get 6 non-expert colleagues operational during a 3-month reinforcement.

Result: they completed the task on their own in 2 days, and the experts' workload dropped by a third.

The project in 3 steps

PROBLEM
A non-linear workflow to produce the as-built file (DOE), poorly documented and passed on orally: months to become autonomous, while production was falling behind.
APPROACH
Interviews and a workshop, two learning profiles, then a three-step journey: illustrated process, checklist, QGIS template. 4 iterations in the field.
OUTCOME
6 out of 6 team members operational, the task completed in 2 days on average, and expert workload cut by 33%.

Deliverables

Key takeaways

Experts often underestimate the cognitive load on new users.
Not all users learn the same way.
Good documentation reduces cognitive load — it doesn't just transfer information.
IN FRENCH ONLYThe full version is currently available in French only. An English version is in progress — expected in November.
2 j
Temps moyen observé par collaborateur sur les réalisations effectuées après la période d'accompagnement (suivi individuel sur les 3 premiers exercices).
−33 %
Charge experte avant/après sur les projets suivis : 6 jours → 4 jours en moyenne par projet.
6/6
Collaborateurs opérationnels : 4 après 3 suivis, 2 après une session ciblée
20 %
du volume ciblé du dossier de fin de chantier (DOE) délégué
Glossaire
DOEDossier des Ouvrages Exécutés : document contractuel établi après l'exécution des travaux et remis au maître d'ouvrage à la livraison du chantier.
FTTHFiber To The Home : fibre optique jusqu'au domicile.
QGIS / ArcGISLogiciels de cartographie et d'analyse géographique.
SIGSystème d'Information Géographique (GIS en anglais).
ChambreRegard souterrain du réseau fibre, où sont posés et raccordés les câbles.
TEAMS · Q/R

Contexte

Le projet DOE (Dossier des Ouvrages Exécutés) d'un déploiement FTTH risquait de ne pas atteindre ses objectifs de production avant la fin de l'année 2025. Devenir autonome sur l'ensemble du workflow demandait plusieurs mois d'expérience opérationnelle.

En analysant le workflow global, l'équipe a identifié une tâche accessible à des profils non experts : elle ne nécessitait ni usage avancé de logiciels complexes, ni maîtrise approfondie de toutes les règles d'ingénierie. La déléguer permettait de réduire la charge des experts et d'accélérer le projet.

MON RÔLE
Concevoir l'expérience qui rendrait ces collaborateurs en renfort d'équipe autonomes en un minimum de temps, puis les accompagner jusqu'à l'autonomie.
01

Discover

Comprendre les utilisateurs et le terrain
J'ai combiné trois sources pour comprendre le problème avant de concevoir quoi que ce soit.
SOURCE 1
Entretien de cadrage
Avec mon responsable — clarifier les résultats attendus de la mission.
SOURCE 2
Entretiens utilisateurs
Courts, avec chaque collaborateur — comprendre leur parcours, leurs compétences et leur aisance avec les outils.
SOURCE 3
Atelier
Avec les managers et les chargés d'études seniors — identifier ensemble les points de difficulté du workflow.
Les difficultés identifiées se regroupent en trois thèmes :
Complexité cognitive
  • Workflow non linéaire
  • Difficulté à prioriser les bonnes données
Accessibilité des connaissances
  • Vocabulaire très technique
  • Procédures transmises surtout à l'oral, sans support visuel standardisé
Hétérogénéité des profils
  • Parcours spécialisés sur des projets différents
  • Niveaux inégaux de maîtrise des règles d'ingénierie et des applications métier
02 — DEFINE · FORMULER LE BON PROBLÈME
Comment pourrions-nous permettre à des collaborateurs non experts de réaliser une tâche technique du dossier de fin de chantier (DOE) en 2 jours en moyenne, dans le cadre d'un renfort de 3 mois, tout en maintenant une qualité acceptable pour la production ?
Deux profils d'apprentissage
Les entretiens puis l'observation ont fait émerger deux façons d'apprendre.
PROFIL 01ThomasL'Expérimentateur · apprend par l'essai
Besoin principalPratiquer vite, être corrigé au bon moment
FRUSTRATIONS
  • Les longues explications avant de pratiquer
  • Les erreurs découvertes trop tard, en revue finale
PROFIL 02CamilleL'Analyste · apprend par la compréhension
Besoin principalComprendre le « pourquoi » avant d'agir
FRUSTRATIONS
  • Le jargon non expliqué
  • Les étapes « évidentes » passées sous silence
Profils synthétisés à partir de l'observation des 6 collaborateurs accompagnés.
PRINCIPES DE CONCEPTION
Les experts omettaient les étapes jugées « évidentes » et le jargon restait implicite. D'où quatre principes :
1Réduire la charge cognitive plutôt qu'ajouter de l'information.
2Rendre visible l'implicite : jargon, étapes « évidentes », dépendances.
3Proposer plusieurs modes d'apprentissage : visuel, exemple, feedback.
4Prévenir l'erreur au moment de l'action, pas seulement à la relecture.
03

Develop

Concevoir le parcours d'onboarding
TEMPS 1Apprendre
TEMPS 2Pratiquer en étant accompagné
TEMPS 3Devenir autonome avec des aides au bon moment
1 Simplifier le workflow
  • Segmentation des étapes
  • Hiérarchisation des actions
  • Clarification des dépendances
  • Mise en évidence des priorités
2 Une documentation visuelle
  • Captures d'écran annotées
  • Vocabulaire harmonisé entre les projets
  • Exemples concrets
  • Modes opératoires illustrés
3 Des outils qui préviennent l'erreur
  • Checklist d'auto-vérification (Excel) avec indications visuelles, aides contextuelles et rappels ajoutés selon les retours terrain
  • Modèle QGIS préconfiguré pour réduire la charge cognitive pendant la réalisation
4 Un accompagnement après la formation
  • Suivi individuel sur les 3 premiers exercices : observer, corriger, répondre aux questions
  • Support collaboratif : groupe Teams de questions/réponses, documentation partagée, sessions collectives, accompagnement asynchrone
AVANT / APRÈS · LE TRI DES DONNÉES
Du tri à l'aveugle à une priorité lisible
AVANTTout se faisait directement dans ArcGIS.
01Chercher les données brutesSources multiples, versions incertaines.
→
02Comparer dans ArcGISAvec les données déjà existantes.
→
03Superposer 3 à 8 couchesLes mêmes objets se chevauchent.
→
04Deviner la bonne chambreComparaison visuelle, à la main.
→
05Intégrer et livrerAu client.
LES QUESTIONS SANS RÉPONSE CLAIRE
  • Pourquoi plusieurs chambres du même nom à des endroits différents ?
  • Laquelle intégrer aux données livrées au client ?
CONTRAINTES OUTIL
  • ArcGIS lent avec plusieurs couches
  • Déconnexion automatique si l'on n'enregistre pas à temps
  • Allers-retours entre les étapes 02 et 04
APRÈSQGIS prépare, ArcGIS finalise.
01Télécharger les données brutesGarantit la version la plus récente.
→
02Déposer dans les dossiersUn dossier numéroté par usage.
→
03Ouvrir le modèle QGISLes couches s'affichent par priorité.
→
04Trier et finaliser dans QGISRapide, sans risque de déconnexion.
→
05Importer dans ArcGISUniquement pour la mise en forme finale.
02 · Un dossier numéroté par source : chaque fichier a sa place.
03 · À l'ouverture, les couches se relient aux dossiers, déjà symbolisées et ordonnées par priorité.
Noms de fichiers et de couches floutés pour confidentialité.
ZOOM SUR LE PROCESS ILLUSTRÉ
14 pages, une même grammaire visuelle
Chaque page suit les mêmes règles : l'utilisateur n'a plus à chercher où lire, il suit le process.
12345
1
TitreToujours au même endroit : on sait où l'on se trouve dans le process.
2
Sous-étapeUne étiquette par action pour découper la tâche en étapes courtes.
3
Texte explicatifEn bleu : consignes brèves, vocabulaire harmonisé entre les projets.
4
Capture d'écranEn gris : l'interface réelle, pour reconnaître chaque écran.
5
FlècheL'ordre des actions, de la consigne vers la capture.
LES 14 PAGESDéfilement horizontal
Couverture
Étape 01
Étape 02
Étape 03
Étape 04
Étape 05
Étape 06
Étape 07
Étape 08
Étape 09
Étape 10
Étape 11
Étape 12
Étape 13
Contenus masqués pour confidentialité : seule la structure des pages est montrée.
04

Test & itérations

Observer pour ajuster
Les séances de suivi ont servi de tests en situation réelle : observer un utilisateur en difficulté m'en apprenait plus que corriger immédiatement son erreur.
PROBLÈME OBSERVÉAJUSTEMENT DE CONCEPTION
Difficulté à identifier la bonne source de données.→Sources valides centralisées dans le process, tri par priorité dans le modèle QGIS.
Confusion entre les terminologies des projets.→Harmonisation du vocabulaire dans le process.
Habitudes ArcGIS reproduites automatiquement dans QGIS.→Prétraitement dans QGIS, ArcGIS réservé à la mise en forme finale.
Oubli d'étapes critiques.→Rappels ajoutés dans la checklist.
Manque de confiance lors des validations finales.→Checklist d'auto-vérification.
4 versions du process2 versions de la checklistIntégration de nouvelles contraintes clientAmélioration continue des explications et des exemples
05

Résultats & impact

L'objectif est atteint : les collaborateurs non experts réalisent la tâche en 2 jours en moyenne, et l'équipe a atteint ses objectifs de production en fin d'année.
2 jtemps moyen de réalisation par un non-expert
−33 %charge des experts : 6 → 4 jours par projet
6/6collaborateurs opérationnels
~20 %du volume ciblé du dossier de fin de chantier (DOE) délégué
POUR LES UTILISATEURS
  • Le plus apprécié : les supports visuels (process, modèle, checklist), les exemples concrets, les séances de suivi et l'accompagnement asynchrone.
POUR L'ÉQUIPE
  • Des savoir-faire implicites, transmis jusque-là à l'oral, sont désormais formalisés : partage de bonnes pratiques et harmonisation des méthodes.
  • Projet reconnu positivement par le management et plusieurs collaborateurs seniors.
06

Arbitrages de conception

Certains experts estimaient que la qualité finale restait inférieure à celle de collaborateurs très expérimentés ; des retouches ponctuelles étaient parfois nécessaires lors des revues finales. Ce constat révèle un arbitrage assumé entre trois exigences :
Rapidité de montée en compétenceAutonomie opérationnelleNiveau d'expertise attendu
07

Ce que j'ai appris

Cette expérience m'a amené à adopter une approche centrée utilisateur dans un environnement technique complexe.
Observer un utilisateur en difficulté apporte souvent plus que corriger immédiatement son erreur.
Rendre un workflow scalable implique des compromis entre qualité, rapidité et autonomie.
Elle a aussi renforcé mon intérêt pour l'optimisation des systèmes complexes, l'UX en environnement B2B et la conception d'outils qui rendent le travail accessible.
Merci de votre lecture, vos questions sont bienvenues :)
Thanks for reading — your questions are welcome :)
SUIVANT · ÉTUDE DE CAS 02Aligner les parties prenantesUn plugin QGIS et des règles communes pour réduire les incohérences de données.SUIVANT · À PROPOSQui suis-je ?Mon parcours, du paysagisme au Product Design.
Un projet complexe à rendre simple ?
Parlons-en.
© 2026 Yibo Sun · Tous droits réservés
NEXT · CASE STUDY 02Aligning stakeholdersA QGIS plugin and shared rules to reduce data inconsistencies (in French).NEXT · ABOUTWho am I?My path, from landscape design to Product Design.
Got a complex project to simplify?
Let's talk.
© 2026 Yibo Sun · All rights reserved
{{ remainNum2 }} min{{ remainNum2 }} min
Axione

Aligner les parties prenantes pour réduire les incohérences de données

Une approche UX dans un contexte d'outil interne (plugin QGIS).
AlignementOutil interneQGISFMEPython
Date2024
Durée2 semaines
ContexteProjet SIG (cartographie des réseaux) de 121 dossiers
RôleRéférent UX et facilitateur (rôle sur le projet, distinct de mon poste officiel)
Utilisateurs5 opérateurs au démarrage, environ 25 personnes au fil du projet
Parties prenantes3 responsables d'étude (dont mon manager), 1 collègue développeur, le client
OutilsQGIS, FME
LECTURE RAPIDEL'essentiel en 2 minutes. Désactivez pour lire l'étude complète.
≈ 2 min de lecture
LECTURE RAPIDELECTURE COMPLÈTEVersion complète affichée. Réactivez pour revenir à l'essentiel.
≈ 5 min de lecture
IN FRENCH ONLYThis case study is currently available in French only. An English version is in progress — expected in November.
2 sem.
Plugin développé et testé en interne
−50 %
Temps de production par projet avant/après le plugin (1–2 jours → ~0,5–1 jour), constaté sur les projets après stabilisation (4 itérations).
25
Personnes utilisant l'outil au fil du projet (5 au démarrage)
121
Projets traités
Formes irrégulières (A) transformées par des règles de correspondance en formes homogènes (B)

Au lancement d'un projet de 121 dossiers, l'outil existant s'est vite révélé inadapté : des exports FME à corriger et à compléter à la main, projet après projet. Chaque responsable appliquait ses propres règles, les attentes du client restaient floues, et une solution du département digital n'était pas attendue avant 1 à 2 mois.

Mon rôle : faciliter l'alignement entre le client, les responsables d'étude et le développeur pour transformer ces besoins ambigus en règles communes, puis tester avec l'équipe un plugin QGIS développé en interne en 2 semaines.

Résultat : environ 50 % de temps gagné par projet, et un outil adopté par toute l'équipe.

Le projet en 3 temps

PROBLÈME
Un outil existant inadapté (exports FME corrigés à la main), des règles de saisie différentes selon les responsables, des attentes client floues : une perte de temps et des incohérences à répétition.
DÉMARCHE
Obtenir des fichiers réels du client, aligner deux responsables d'étude sur une règle commune, formaliser le mapping A → B, puis 4 itérations de test.
RÉSULTAT
Un plugin QGIS développé en interne en 2 semaines, un temps par projet réduit d'environ 50 %, utilisé par l'ensemble des équipes du projet.

Correspondances A → B

SCHÉMA A → B
Exports FME
outil interne
(A)
→
Analyse des écarts
→
Règles de transformation
→
Tests et itérations
→
Attendu client
(B)
Données confidentielles : exemples anonymisés et simplifiés.

À retenir

Le problème était organisationnel, pas seulement technique.
Transformer des données ambiguës en règles exploitables.
Formaliser les règles dans un document de référence partagé.
Formes irrégulières (A) transformées par des règles de correspondance en formes homogènes (B)

Contexte

Dans le cadre d'un projet SIG (système d'information géographique), notre équipe devait livrer 121 projets en 1 à 2 mois.
Le processus existant reposait sur des exports générés via FME (outil interne de transformation de données), suivis de corrections et de complétions manuelles. Cependant :
POINTS DE BLOCAGE
  • Le département digital travaille en méthode agile, par sprints de 2 semaines. Le premier sprint ayant été manqué, et notre besoin n'étant pas forcément prioritaire au sprint suivant, le délai avant de pouvoir tester sur nos fichiers était incertain (estimé à 1–2 mois) ;
  • Les règles de saisie variaient selon les responsables d'étude ;
  • Les attentes du client n'étaient pas clairement définies.
Résultat : une perte de temps, des incohérences et des modifications à répétition.
MON RÔLE
Référent UX et facilitateur (rôle sur le projet, distinct de mon poste officiel). Je faisais le lien entre les attentes du client, les responsables d'étude et le développeur, afin de transformer des besoins ambigus en règles claires et testées.
01

Problème

Des symptômes à une cause commune
Question de départ : comment améliorer rapidement la productivité et la cohérence des données ?
Les symptômes (perte de temps, incohérences, allers-retours) avaient une cause commune :
LES CAUSES
  • Des règles de saisie non unifiées ;
  • Des attentes client ambiguës ;
  • Plusieurs responsables aux visions divergentes ;
  • Aucun mapping clair entre les données issues d'outil interne FME (A) et les attentes du client (B).
PROBLÈME CLÉ
Un manque d'alignement entre les parties prenantes. Le véritable enjeu n'était donc pas seulement de développer un outil, mais de concevoir cet alignement.
02

Parties prenantes

Des visions à aligner
RESPONSABLES D'ÉTUDE
3 responsables d'étude, dont mon manager : définition des règles, visions divergentes.
OPÉRATEURS
5 opérateurs au démarrage du projet (saisie et traitement des données), dont 1 collègue développeur (plugin Python / QGIS).
CLIENT
Validation finale.
03

Démarche

Quatre étapes, de besoins ambigus à des règles testées
01Clarifier les besoins
CONTRAINTEJe n'avais pas d'accès direct au client.
ACTIONPour éviter de travailler sur des hypothèses, j'ai mobilisé mon expérience d'un projet similaire de l'entreprise pour convaincre mon manager de demander au client, avant le démarrage du projet, des fichiers réels et des exemples de résultats attendus, sous forme d'un fichier nomenclature pour le remplissage des données, plutôt que de définir les données en interne à partir de notre propre expérience.
RÉSULTATUne source de vérité fiable et des critères attendus plus clairs.
02Aligner les parties prenantes
CONTRAINTELes responsables d'étude n'étaient pas d'accord sur les règles de saisie ni sur le niveau de qualité attendu. Sans standard, il était impossible de valider les résultats.
ACTIONJ'ai contribué à convaincre deux responsables d'étude de définir une règle commune et d'éviter des logiques parallèles contradictoires.
PRINCIPE UXLa cohérence du système prime sur les optimisations individuelles.
03Structurer la logique de transformation (A → B)
CONTRAINTEAucun mapping clair n'existait entre les outputs FME (A) et les résultats attendus par le client (B). Le projet comptait de nombreuses sous-unités, chacune avec plus de 10 champs nécessitant des règles de mapping différentes.
ACTIONJ'ai vérifié et corrigé ce mapping en comparant systématiquement les deux, en m'appuyant sur les exemples réels du client comme source de vérité. Plutôt que de corriger au cas par cas, j'ai identifié des patterns récurrents et aidé à les formaliser en règles de transformation.
SCHÉMA A → B
Exports FME
outil interne
(A)
→
Analyse des écarts
→
Règles de transformation
→
Tests et itérations
→
Attendu client
(B)
Données confidentielles : exemples anonymisés et simplifiés.
04Itérer et valider
ACTIONAvec deux collègues, nous avons comparé l'ensemble des données entre l'output initial, l'output du plugin et l'attendu client. J'ai rédigé les rapports de test : après chaque mise à jour du plugin, j'y consignais les résultats ainsi que les problèmes de mapping identifiés.
RÉSULTAT4 itérations ont été nécessaires pour stabiliser la solution.
04

Solution

Un plugin QGIS développé en interne
Plutôt que d'attendre un prochain sprint du département digital, nous avons développé et testé le plugin en interne en 2 semaines, avec un collègue ayant des compétences en Python.
LE PLUGIN QGIS PERMET DE
  • Automatiser une grande partie de la saisie ;
  • Appliquer des règles homogènes ;
  • Réduire les corrections manuelles.
Les règles de transformation ont été établies et testées par rapport aux exigences de données du client, puis formalisées dans un document de référence partagé.
05

Résultats & impact

L'outil a été adopté par l'ensemble des équipes du projet : environ 25 personnes, sur 121 projets.
AVANTAPRÈS
Mise à disposition de l'outilDélai incertain, estimé à 1–2 mois (sprints du département digital)2 semaines (développement interne)
Temps par projet1–2 jours (correction entièrement manuelle)~0,5–1 jour (environ −50 %)
Utilisateurs5 opérateurs au démarrageEnviron 25 personnes au fil du projet
VolumeProjet test parmi les 121 projets121 projets
GAINS OBSERVÉS
  • Productivité accrue ;
  • Cohérence des données améliorée (constat qualitatif, non mesuré) ;
  • Réduction des allers-retours.
06

Ce que j'ai appris

Ce projet m'a permis de comprendre que le principal défi n'était pas de développer un outil, mais de concevoir un alignement entre des interprétations divergentes et d'établir un process pour le projet.
CE QUI A FONCTIONNÉ
Identifier que le problème était organisationnel, pas seulement technique.
Transformer des données ambiguës en règles exploitables.
Aligner, même partiellement, les parties prenantes malgré des contraintes hiérarchiques.
Formaliser les règles dans un document de référence partagé.
AMÉLIORATIONS POSSIBLES
Aligner plus tôt : proposer d'organiser un workshop dès le départ.
Définir des métriques : taux d'erreur, nombre de corrections, etc.
J'ai ainsi joué un rôle de pont entre des attentes client floues, des contraintes internes et une implémentation technique.
Merci de votre lecture, vos questions sont bienvenues :)
Thanks for reading — your questions are welcome :)
PRÉCÉDENT · ÉTUDE DE CAS 01Réduire la complexité d'un workflow techniqueUn système d'onboarding pour des collaborateurs non experts.SUIVANT · À PROPOSQui suis-je ?Mon parcours, du paysagisme au Product Design.
Un projet complexe à rendre simple ?
Parlons-en.
© 2026 Yibo Sun · Tous droits réservés
PREVIOUS · CASE STUDY 01Reducing the complexity of a technical workflowAn onboarding system for non-expert colleagues.NEXT · ABOUTWho am I?My path, from landscape design to Product Design.
Got a complex project to simplify?
Let's talk.
© 2026 Yibo Sun · All rights reserved
Hello, Nice to meet you :)

Je suis Yibo, Product Designer. Je rends simples les systèmes complexes.

Graphiste
Paysagiste
Urbaniste
Chargé d'études techniquesen poste
Product Designen cours

Sept ans d'expérience dans des secteurs variés, un parcours multiculturel et pluridisciplinaire. Je parle couramment trois langues, et j'ai appris à traduire tout aussi couramment les besoins et les idées entre pays, cultures et disciplines.

Avant le Product Design, mon parcours a traversé le design graphique, l'architecture du paysage, l'urbanisme et l'ingénierie d'études techniques. Un mélange inhabituel, mais chaque domaine a affiné ma compréhension de la façon dont les gens parcourent des pages, des espaces, des systèmes et des idées — et révélé des parallèles évidents entre concevoir un parc urbain et concevoir un produit numérique.

Je m'intéresse particulièrement à la pensée systémique et au design centré sur l'humanité. Je suis actuellement une formation en Product Design augmenté par l'IA auprès de l'Interaction Design Foundation. Je participe aux événements de la FLUPA depuis 2025 et j'en suis membre depuis 2026. Je recherche aujourd'hui un poste de Product Designer — Lille, hybride en France ou remote en Europe. Disponible avec un préavis d'un mois.

En dehors du travail : la cuisine, le sport, les voyages, les musées et les points de vue qui dépassent mes propres biais.

J'aime rencontrer de nouvelles personnes : n'hésitez pas à me contacter !

© 2026 Yibo Sun · Tous droits réservés
Hello, Nice to meet you :)

I'm Yibo, a Product Designer. I make complex systems simple.

Graphic designer
Landscape architect
Urban planner
Technical studies engineercurrent role
Product Designin progress

Seven years of experience across diverse industries, with a multicultural and multidisciplinary background. I speak three languages fluently — and I've learned to translate needs and ideas just as fluently across countries, cultures and disciplines.

Before Product Design, my path ran through graphic design, landscape architecture, urban planning and technical engineering. An unusual mix — but each field sharpened my understanding of how people move through pages, spaces, systems and ideas, and revealed clear parallels between designing an urban park and designing a digital product.

I'm especially interested in systems thinking and humanity-centered design. I'm currently taking an AI-augmented Product Design program with the Interaction Design Foundation. I've attended FLUPA events since 2025 and became a member in 2026. I'm now looking for a Product Designer role — Lille, hybrid in France or remote in Europe. Available with one month's notice.

Outside of work: cooking, travel, museums, and perspectives that challenge my own biases.

I love meeting new people — feel free to reach out!

© 2026 Yibo Sun · All rights reserved