Lors de la création d'un projet internet, vous devez intégrer développement informatique et développement graphique de la solution... Ces experts ont tendance à s'opposer plutôt qu'à cumuler leurs compétences

management collaboration
2
2

11 réponses

il y a 4 ans par emmanueldejean
Simplement trouver un duo qui fonctionne humainement. L'idéal est de flouter les frontières: plus le graphiste connaît le code, et plus le dev connaît le graphisme, plus ils peuvent empiéter sur le terrain l'un de l'autre. Et aller se chercher en cas de soucis. Si tu montes une équipe, écoute les suggestions de tes devs, ils ont souvent des copains graphistes avec qui ils ont déjà bossé !
9
il y a 4 ans par Julien_
Chez Apple, le graphisme a la priorité.

En fait, ce qui embête les développeurs, c'est le manque de structure des créations des graphistes.

C'est pour ça que c'est intéressant que les graphistes créent un "Framework", ou "UI Kit" (kit d'interface utilisateur) plutôt que des maquettes: Au lieu de dessiner chaque page, on crée une structure globale, et des composants. Par exemple "Le bouton à utiliser pour l'action principale sur la page", "Le bouton à utiliser pour des actions destructrices ("Supprimer")", le champ de formulaire "Email",...

D'ailleurs chez Apple, ils demandent aux graphistes de leur donner quelques fichiers Photoshop, et si ce n'est pas très bien structuré (calques bien organisés, avec des noms intelligents,...), eh bien ils ne prennent pas.

Pour illustrer ça, voici un exemple de "UI Kits" : designscrazed.org/flat-psd-ui-kits/
6
il y a 4 ans par Gerald
Bon, un petit commentaire de vieux réac : en fait ça a toujours été comme ça depuis que je bosse. Sauf que pour les sites, avant, on réalisait un graphisme relatif à des fonctionnalités / messages (cahier des charges ou cahier d'analyse fonctionnelle), c'est comme ça qu'on disait quand j'étais plus jeune) sur une largeur fixe qui passait sur tous les écrans, pardon, sur tous les "devices", à 980 pixels de large. Aujourd'hui, on veut des sites qui font papa-maman et qui s'affichent bien sur tous les "devices" y compris les smartphones, donc on ne designe plus des pages mais on réalise une charte graphique-web, ce que tu appelles le "framework" ou UI Kit au même titre qu'une charte graphique papier ou qu'un habillage TV, charte que l'on enrichit avec l'ajout de nouvelles fonctionnalités, il faut itérer ! (cf nouveaux supports pour une charte graphique papier).
En résumé, les méthodes qui ont fait leurs preuves restent. Elles se réajustent à la marge en fonction des supports et on les renomme avec quelques anglicismes pour faire plus "hype".
4
il y a 4 ans par Francis
Leur proposer de co-construire une solution step by step, en partant d'une proposition de l'un amélioré par l'autre, et en réitérant 2 ou 3 fois... Et puis, rappelez de temps en temps l'objectif poursuivi en commun !
4
il y a 4 ans par Julien_
De toute façon, il faut itérer !
2
il y a 4 ans par Gerald
C'est probablement la pire méthode que j'ai eu l'occasion d'expérimenter... ;-) On arrive à un résultat mais c'est très très très chronophage !
2
il y a 4 ans par SpaceTimeContinuum
des éléments de réponse dans le prochain Meetup de TheFamily à Paris -> www.meetup.com/StartupWorkshop/events/220453677...
"Designer/Déve­loppeur, Situation Amoureuse : C’est compliqué" par Alexis Porhiel
jeudi 19 février 2015
12:00 à 13:30
TheFamily
25 rue du Petit Musc, Paris

Avoir un bon work-flow entre les équipes de design et celles de développement est essentielle au succès d’un produit. Même avec des process parfaitement définis, la communication entre ces deux acteurs reste souvent chaotique. Ces querelles de vieux couples finissent par des réunions interminables, des produits mal testés et des deadlines manquées.

Pourtant pas si éloignés l’un de l’autre les designers et les développeurs peuvent, par de moyens simples, réussir à optimiser leur relation pour une exécution léchée et qui répond aux attentes du projet.

Rahman Kalfane :
Diplomé en design d’interaction a L’École de Design Nantes Atlantique, designer et développeur freelance. Co-fondateur de Pelo Studio.

Alexis Porhiel :
Diplomé en design d’interaction a L’École de Design Nantes Atlantique,
ancien Lead product designer chez Visual.ly a San Francisco et co-fondateur de Pelo Studio, un studio de design pour Startups.

Pelo Studio :
Pelo Studio est un studio de design pour startups portant des projets du concept au prototype fonctionnel. De Paris à San Francisco, nous sommes spécialisés en développement de produit digitaux, UI/UX Design et prototypage.
4
il y a 4 ans par alasin
Choisir des personnes expertes dans leur domaine qui ont une vision globale pertinente de la culture des autres métiers.
- un designer graphiste expert qui connait le processus de développement et un peu la culture geek.
- un développeur expert qui connait le processus de création et un peu les cultures "creative design" et hype.
OU
Trouver un/une webdesigner, association des 2 profils, le choix idéal. Il est très difficile d'en trouver des bon(ne)s, mais cela reste possible.
Comment le/la reconnaître? il/elle ne dit de mal ni des uns (designers) ni des autres (développeurs), est très patient(e) et très à l'écoute.
4
il y a 4 ans par VincentLafaye
Bien définir le cahier des charge fonctionnel avec précision et surtout les amener à communiquer de manière directe et orale tout au long du projet.
3
il y a 4 ans par AurelienClauzel
Pas évident en effet de gérer cette relation.
Je dirais que ça dépend également du projet et de l'importance de la UI finale.
J'aime bien la façon dont gère Apple en effet, aux développeurs de s'adapter et de trouver des solutions pour que ça fonctionne de la façon dont ils l'ont pensé.
Les kit d'UI sont une bonne façon de fonctionner.
3
il y a 4 ans par YaelAzoulay
En partant de l'usage. Il faut sans doute une troisième personne, pilote et modérateur de la relation : un designer de service, dès l'amont, et tout au long du process.
3
il y a 4 ans par gmaison
avant tout, c'est identifier l'intensité du couplage entre les deux (faible, moyen, fort) et la congruence de leur compétences (faible, moyenne, forte). Ensuite, c'est de leur montrer et de leur expliquer. Ensuite, c'est de leur expliquer pourquoi ils font leur travail là, ici et maintenant. Et qu'après ils sont chacun l'expertise de leur compétence et que c'est bien la collaboration et la coopération des deux qui amène le succès et la réussite et non le fait que l'une l'emporte sur l'autre, même de manière alternative :)
3
il y a 4 ans par ThierryVallee
Agilité, collaboration, itération. nopsd : thoughtworks.github.io/p2/issue02/continuous-de...
3
il y a 4 ans par oimoci
Merci @ThierryVallee, c'est très bon !
1
il y a 4 ans par laurentpovereau
Bonjour à tous. Personnellement, je rejoindrais plutôt l'idée d'Emmanuel à savoir qu'il est bon que chacune des deux parties connaissent "un bout" du travail de l'autre. c'est un sujet vieux comme le monde que l'on retrouve dans tous les secteurs. J'ai eu à manager des commerciaux d'un côté et des techniciens de l'autre, c'était...pire ! (on a par la suite inventé les "technico-commerciaux"...). il ne faut pas hésiter à organiser des sessions d’échange ou les uns vont pendant 1h ou 2 découvrir le travail des autres. Un groupe de grande distribution Français organisait il y'a quelques années des échanges de ce genre entre les gens du siège et ceux des magasins afin que chacun appréhende mieux le travail des autres...ça rapproche et ça permet aussi d'échanger sur les différents process.
3
il y a 4 ans par ThierryAoudja
Que chacun soit un expert dans son domaine !
2
il y a 4 ans par ElieSL
Bonjour,

Disclaimer : ma première intervention sur Skiller portera sur le sujet que je porte depuis quelques années. J'espère que vous ne m'en voudrez pas. Pour ma défense, les contenus vers lesquels je vais pointer sont en licence libre (CC BY-SA), et vous en êtes en quelque sorte co-propriétaires ;)

Donc, voilà, je n'ai pas tellement de solution pour obtenir le meilleur résultat possible, mais j'ai une belle check-list (en fait quelques unes) qui permettent de prévenir les principaux risques et de se mettre d'accord sur un grand nombre de choses.

checklists.opquast.com/fr/oqs-v2/

Bien évidemment, un développeur doit au minimum comprendre les règles qui concernent les designers
checklists.opquast.com/fr/oqs-v2?q=design


Et un designer doit au minimum comprendre les règles qui concernent les développeurs, notamment lors de la phase cruciale d'intégration :
checklists.opquast.com/fr/oqs-v2?q=int%C3%A9gra...

Ca ne fait pas tout, mais ça aide, je vous assure.

Voilà voilà, j'espère pouvoir apporter d'autres infos sur skiller et en trouver sur bien d'autres sujets, mais au moins sur ce sujet, j'avais du matos ;)
Amicalement
Elie


Elie Sloïm
Président
Temesis - Opquast
-------------------------------------------------------------------------------
www.temesis.com - www.opquast.com
Tél : +33 5 56 401 402 - Mob : +33 6 19 732 949 - @eliesl
-------------------------------------------------------------------------------

Pardon pour le premier post mal placé
2

Vous aimez Skiller?

Rejoignez la communauté.