8 min lecture • Guide 63 of 877
Intégrer les Workflows Design et Développement
L'intégration design et développement élimine le retravail coûteux, accélère les livraisons, et améliore la qualité du produit. La clé est de briser les silos à travers des outils partagés, des processus qui se chevauchent, et une collaboration continue plutôt que des handoffs séquentiels. GitScrum fournit l'infrastructure collaborative pour unir les workflows design et développement.
Le Défi d'Intégration
Problèmes courants avec workflows séparés:
| Silo Design | Silo Développement |
|---|---|
| Designer en isolation | Construire ce que disent specs |
| Contraintes surprises | Exigences surprises |
| Designs finalisés modifiés | "Ce n'est pas ce que j'ai designé" |
| Découvertes tardives faisabilité | Changements design tardifs |
| Cycles de retravail | Cycles de retravail |
Modèles d'Intégration Workflow
Niveaux de Collaboration
MATURITÉ INTÉGRATION DESIGN-DEV:
┌─────────────────────────────────────────────────────────────┐
│ SPECTRE D'INTÉGRATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ NIVEAU 1: HANDOFF CASCADE (Plus de Friction) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Phase Design ─────────→ Handoff ──────→ Phase Build ││
│ │ (Semaines) (Specs) (Semaines) ││
│ │ ││
│ │ ❌ Pas de chevauchement, retravail maximum ││
│ │ ❌ Problèmes faisabilité trouvés tard ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ NIVEAU 2: SPRINTS PARALLÈLES (Mieux) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Sprint N: Design travaille sur features Sprint N+1 ││
│ │ Dev construit designs Sprint N ││
│ │ ││
│ │ ✓ Design reste 1 sprint en avance ││
│ │ ✓ Points sync réguliers ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ NIVEAU 3: MÊME SPRINT, PHASES (Bon) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Sprint Semaine 1: Design + Dev collaborent sur concepts ││
│ │ Sprint Semaine 2: Dev construit pendant Design affine ││
│ │ ││
│ │ ✓ Feedback plus rapide ││
│ │ ✓ Compréhension partagée ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ NIVEAU 4: PAIRING CONTINU (Meilleur) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Design + Dev travaillent ensemble tout au long: ││
│ │ ├── Designer dans équipe dev (ou embarqué) ││
│ │ ├── Pair sur interactions complexes ││
│ │ ├── Prototyper en code tôt ││
│ │ └── Design évolue avec build ││
│ │ ││
│ │ ✓ Minimum retravail ││
│ │ ✓ Contraintes techniques informent design ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Structure Tâches pour Travail Design
Types de Tâches Design
TRAVAIL DESIGN DANS GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ TAXONOMIE TÂCHES DESIGN │
├─────────────────────────────────────────────────────────────┤
│ │
│ TÂCHES DÉCOUVERTE (Pré-Sprint): │
│ ├── Label: "design:discovery" │
│ ├── But: Recherche, comprendre problème │
│ └── Output: Définition problème, insights utilisateur │
│ │
│ TÂCHES EXPLORATION: │
│ ├── Label: "design:exploration" │
│ ├── But: Multiples concepts solution │
│ └── Output: Options concept pour review │
│ │
│ TÂCHES SPEC DESIGN: │
│ ├── Label: "design:spec" │
│ ├── But: Designs finaux prêts pour dev │
│ └── Output: Fichiers Figma/Sketch, specs, assets │
│ │
│ TÂCHES REVIEW: │
│ ├── Label: "design:review" │
│ ├── But: QA implémentation correspond au design │
│ └── Output: Approbation ou feedback │
│ │
│ WORKFLOW GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ À Faire → En Design → Review Design → Prêt Dev → ││
│ │ En Cours → Code Review → QA Design → Fait ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Lier Tâches Design et Dev
STRUCTURE TÂCHES CONNECTÉES:
┌─────────────────────────────────────────────────────────────┐
│ FEATURE: Édition Profil Utilisateur │
├─────────────────────────────────────────────────────────────┤
│ │
│ TÂCHE DESIGN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Titre: Designer flux édition profil ││
│ │ Type: design:spec ││
│ │ Assigné: @designer ││
│ │ Statut: Fait ✓ ││
│ │ ││
│ │ Pièces jointes: ││
│ │ └── 🔗 Figma: Designs Édition Profil ││
│ │ ││
│ │ Tâches Liées: ││
│ │ └── → Bloque: "Implémenter édition profil" (DEV-234) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TÂCHE DÉVELOPPEMENT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Titre: Implémenter édition profil ││
│ │ Type: feature ││
│ │ Assigné: @developer ││
│ │ Statut: En Cours ││
│ │ ││
│ │ Description: ││
│ │ Construire édition profil selon designs: ││
│ │ 🔗 Design specs: [lien Figma] ││
│ │ ││
│ │ Critères Acceptation: ││
│ │ - [ ] Form correspond au layout Figma ││
│ │ - [ ] Validation selon états design ││
│ │ - [ ] Approbation QA @designer ││
│ │ ││
│ │ Tâches Liées: ││
│ │ └── ← Dépend de: "Designer édition profil" (DES-123) ✓ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques Handoff
Specs Design Efficaces
CHECKLIST HANDOFF DESIGN:
┌─────────────────────────────────────────────────────────────┐
│ CE QUE DÉVELOPPEURS ONT BESOIN DES DESIGNERS │
├─────────────────────────────────────────────────────────────┤
│ │
│ SPÉCIFICATIONS VISUELLES: │
│ ├── [ ] Espacement et dimensions (pixels ou design tokens) │
│ ├── [ ] Couleurs (codes hex ou noms token) │
│ ├── [ ] Typographie (font, size, weight, line height) │
│ └── [ ] Breakpoints responsive │
│ │
│ ÉTATS COMPOSANT: │
│ ├── [ ] État default │
│ ├── [ ] État hover │
│ ├── [ ] État actif/pressé │
│ ├── [ ] État focus (accessibilité) │
│ ├── [ ] État disabled │
│ ├── [ ] État loading │
│ └── [ ] État error │
│ │
│ VARIATIONS CONTENU: │
│ ├── [ ] Contenu minimum (états vides) │
│ ├── [ ] Contenu maximum (règles troncation) │
│ └── [ ] Différentes langues (expansion texte) │
│ │
│ COMPORTEMENT INTERACTION: │
│ ├── [ ] Transitions et animations │
│ ├── [ ] Comportement gestes (mobile) │
│ └── [ ] Navigation clavier │
│ │
└─────────────────────────────────────────────────────────────┘
Collaboration Continue
Design dans Cérémonies Sprint
PARTICIPATION DESIGNER DANS SCRUM:
┌─────────────────────────────────────────────────────────────┐
│ CÉRÉMONIES AVEC INTÉGRATION DESIGN │
├─────────────────────────────────────────────────────────────┤
│ │
│ SPRINT PLANNING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Rôle Designer: ││
│ │ ├── Présenter designs pour items sprint ││
│ │ ├── Répondre questions dev sur specs ││
│ │ ├── S'engager sur travail design dans sprint ││
│ │ └── Identifier dépendances design ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ STANDUP QUOTIDIEN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Designer Rapporte: ││
│ │ ├── Tâches design en cours ││
│ │ ├── Blockers nécessitant input dev ││
│ │ └── Changements design affectant travail en cours ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ REVIEW SPRINT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Implication Design: ││
│ │ ├── Présenter décisions design ││
│ │ ├── Comparer implémentation avec design ││
│ │ └── Célébrer victoires collaboration design-dev ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Processus QA Design
Workflow Quality Assurance
QA DESIGN DANS GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ WORKFLOW QA DESIGN │
├─────────────────────────────────────────────────────────────┤
│ │
│ ÉTAPE 1: DEV DEMANDE QA DESIGN │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Développeur: ││
│ │ ├── Déplace tâche vers colonne "QA Design" ││
│ │ ├── Ajoute commentaire: "Prêt pour review design" ││
│ │ ├── Lie URL staging/preview ││
│ │ └── @mentionne designer ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ÉTAPE 2: DESIGNER RÉVISE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Designer Vérifie: ││
│ │ ├── [ ] Précision visuelle vs. designs ││
│ │ ├── [ ] Tous états implémentés ││
│ │ ├── [ ] Comportement responsive ││
│ │ └── [ ] Animations/transitions ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ÉTAPE 3: FEEDBACK │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Si Problèmes Trouvés: ││
│ │ ├── Screenshot avec annotations ││
│ │ ├── Comparer avec Figma (côte à côte) ││
│ │ ├── Sévérité: Critique / Majeur / Mineur ││
│ │ └── Déplacer tâche retour vers "En Cours" ││
│ │ ││
│ │ Si Approuvé: ││
│ │ ├── Commentaire: "QA Design ✓" ││
│ │ └── Déplacer tâche vers "Fait" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques
Faire
SUCCÈS INTÉGRATION DESIGN-DEV:
✓ DESIGNERS DANS ÉQUIPE
Embarquer designers dans équipes développement
✓ IMPLICATION TÔT
Inclure devs dans exploration design
✓ SOURCE UNIQUE
Liens Figma toujours dans descriptions tâche
✓ QA DESIGN COMME PORTE
Étape obligatoire avant compléter tâche
✓ PENSÉE COMPOSANT
Langage design system partagé
Ne Pas Faire
ANTI-PATTERNS INTÉGRATION:
✗ HANDOFFS CASCADE
Designs complets jetés par-dessus mur
✗ CHANGEMENTS DESIGN NON ANNONCÉS
Updates sans notification développeur
✗ OBSESSION PIXEL-PERFECT
Bloquer release pour différences mineures
✗ OUTILS SÉPARÉS
Designers ne peuvent pas voir progrès dev