Designer et son rôle dans le développement d'applications mobiles
Nous savons tous que le design joue un rôle très important dans la conception et le développement d'applications mobiles. Chaque concepteur a sa propre approche, ses méthodes et ses outils pour travailler sur des applications. Le rythme de développement dépend des plates-formes sur lesquelles le concepteur travaillera et de la manière dont il présentera le matériau fini à l'équipe du projet.
Ce n'est un secret pour personne que les équipes de projet changent fréquemment. Aujourd'hui, on travaille sur le projet, et demain une personne complètement différente travaille déjà. Par conséquent, la conception d'une application mobile n'est pas seulement des images bien dessinées, mais aussi du matériel transmis de haute qualité, montrant aux autres comment l'application devrait fonctionner.
Dans cet article, je veux parler de l'interaction du développeur avec le concepteur, sur la base de ma propre expérience dans le développement d'une application mobile, de mes attentes vis-à-vis du projet et de la réalité brutale. J'espère que cet article incitera de nombreux nouveaux designers à réfléchir à leur travail, ainsi qu'à aider les développeurs à faire face à des situations difficiles.
Comment un designer peut-il simplifier la vie d'un développeur?
Ainsi, le designer, quels que soient son profil et sa concentration, dispose de nombreux outils avec lesquels il peut dessiner ce qui lui est demandé. Il ne suffit pas de dessiner simplement les écrans d'une application mobile. Ce n'est ni un site Web ni une application Web. Cette catégorie de produits numériques a des règles plus strictes auxquelles vous devez vous conformer. Des directives distinctes ont été créées pour les plates-formes IOS et Android (voir la section "Liens utiles").
Tout cela a été inventé pour une raison. Si un illustrateur ou simplement un concepteur de sites Web décide soudainement de faire partie d'une équipe mobile, il est sûr de dire qu'il remettra le projet relativement mal. Même s'il lui semble qu'il a tout fait cool, un développement ultérieur peut conduire à la conclusion inverse.
Actuellement, la situation est telle que les développeurs, comme les concepteurs, disposent de nombreux outils et guides spécifiques. Non seulement ils ne veulent pas se plonger dans les outils de conception, mais ils n'ont tout simplement pas le temps. Le designer vient de passer son travail, et le chef de projet et le client exigent déjà les résultats du développeur. Que peut faire un designer dans ce cas? Comment peut-il gagner du temps aux développeurs? Tout est assez simple - vous devez choisir les bons outils non seulement pour dessiner le projet, mais aussi pour les travaux ultérieurs avec l'équipe de développement.
Après plusieurs années de travail dans de nombreuses équipes différentes les unes des autres, j'ai réalisé comment le design affecte la vitesse de développement et le travail confortable en équipe. Par conséquent, maintenant, avant de prendre la conception en développement, je vérifie sa conformité à certaines normes et règles.
Le designer fait partie de l'équipe
Ce ne sont pas que des mots pathétiques. Le concepteur doit faire partie de l'équipe avant de mettre l'application en magasin, communiquer constamment avec ses collègues, clarifier les problèmes et répondre rapidement aux demandes des développeurs. La durée minimale de son séjour dans l'équipe est jusqu'à la première livraison du MVP.
Comme le montre la pratique, les concepteurs ne donnent pas toujours leurs mises en page de manière de haute qualité, et avec le développement, certaines lacunes apparaissent, par exemple, des écrans vides non dessinés ou un état des éléments, des blocs d'éléments mal coupés, le manque de ressources. Il arrive aussi que le client veuille ajouter quelque chose.
Le designer doit terminer son travail, et il est bon qu'il soit dans l'équipe à ce moment-là pour que les changements puissent être effectués rapidement. Ou il doit être en contact pour que le projet et l'équipe n'aient pas de problèmes avec le changement opérationnel d'UI / UX.
Le développeur ne doit pas comprendre dans quels programmes le projet a été dessiné. Les fichiers devraient s'ouvrir facilement
Comme mentionné ci-dessus, le développeur doit maintenant étudier tellement qu'il n'a tout simplement pas le temps de comprendre les éditeurs graphiques. Par conséquent, le concepteur ne doit pas dessiner d'éléments dans Photoshop / Illustrator et faire don de la mise en page dans des fichiers * .psd / * .ai. Ces fichiers pèsent beaucoup et nécessitent l'installation du package Adobe. Même si cela ne joue pas un rôle particulier, nous n'avons tout simplement pas le temps d'étudier ces éditeurs.
Le développeur veut simplement sélectionner les éléments et voir comment les composer, et ne pas comprendre la structure des couches d'un énorme fichier. Il existe désormais de nombreux éditeurs graphiques pour le rendu d'applications mobiles: Sketch, Figma et autres. En général, il y a beaucoup de choix. La façon dont le concepteur présentera un prototype cliquable et des «écrans en direct» pour le frontend dépendra de l'éditeur sélectionné.
Si le concepteur a choisi Figma, les écrans «en direct», le prototype cliquable, la user story, les transitions d'écran, les familles de polices et la couleur, les ressources peuvent être téléchargées indépendamment - tout est au même endroit. Les modifications de conception sont immédiatement visibles. Comme de nombreux services, Figma a ses inconvénients. Mais c'est un très bon choix, ne serait-ce que parce que cet éditeur ne nécessite pas l'installation de logiciels spéciaux. Il vous suffit de cliquer sur le lien vers le projet. L'essentiel est d'avoir Internet.
Le croquis est également un bon choix. Un concepteur peut utiliser des outils de prototypage tels que Zeplin ou InVision pour cet éditeur si l'équipe de développement travaille déjà avec eux. Ces programmes ne nécessitent pas d'étude approfondie des outils.
Le concepteur doit connaître les directives pour les différentes plateformes et leurs différences
Très souvent, les concepteurs dessinent des projets sans comprendre les lignes directrices, mélangent les styles ou créent des éléments non standard, en pensant à la beauté de l'écran. Il existe de nombreux exemples de ce type sur Dribbble et Behance. Les clients, ignorant ces nuances, approuvent les dispositions. En matière de développement, les choses s'arrêtent. Le concepteur ne veut pas refaire le mauvais travail. Le client a besoin d'un tel écran ou effet, qu'il a approuvé, mais cela ne peut pas être fait.
Par conséquent, il est très important que le concepteur comprenne quoi et comment dessiner.
Les ressources
C'est le problème le plus douloureux lors de l'interaction avec un designer. En règle générale, les concepteurs ne coupent pas les ressources. Pour la plupart, ils croient que: ils ne sont pas tenus de le faire; il est long et monotone, et si le développeur en a besoin, il coupera tout lui-même ou vous pouvez réinitialiser * .svg; ils ne savent pas exactement ce qui doit être coupé et dans quelles tailles.
Néanmoins, si vous regardez du côté du développeur, la résolution de ce problème réduit considérablement le temps de travail. Il lui suffit de regarder le nom de la ressource sur le prototype et de le trouver dans le dossier des ressources - et c'est tout, continue-t-il de composer. Et si vous imaginez que le développeur doit lui-même couper les ressources? Il doit mettre complètement en évidence l'élément souhaité à l'écran, trouver l'exportation, spécifier la taille et le chemin.
Il semble que ce soit un travail rapide. Mais il y a de nombreux éléments et beaucoup de temps est perdu. Encore une fois, les mises en page n'abandonnent pas toujours en parfait état. Le designer ne prend pas toujours tout en compte. En outre, l'outil de prototypage peut ne pas fonctionner correctement lors de l'exportation.
En essayant de sélectionner des éléments à découper, les développeurs ne sélectionnent parfois qu'une partie de l'élément ou s'accrochent à l'arrière-plan (qui devrait être transparent). Par conséquent, il est bon que le concepteur coupe non seulement les ressources, mais utilise également les tailles correctes.
TK avec une description des écrans
C’est bien lorsque l’application se compose d’un petit nombre d’écrans et, en un coup d’œil, son fonctionnement est clair. Si l'application dispose d'un grand nombre d'écrans et que le prototype ne donne pas une image complète de son fonctionnement, ou que l'application a grandi après avoir effectué des modifications à la demande du client, une description technique de tous les écrans, chaque élément de cet écran et son statut peuvent sauver la situation.
Comme indiqué ci-dessus, les membres de l'équipe de projet changent souvent. Personne ne veut jouer avec les débutants. Peut-être que mes collègues feront un bref examen, déposeront des liens vers toutes les ressources publiées par le concepteur - et c'est tout. Le développeur devrait commencer à travailler avec une compréhension complète du fonctionnement de l'application. Le plus souvent, aucun savoir traditionnel n'explique cela, car le concepteur ne savait pas que c'était nécessaire ou ne voulait pas le faire. Et qu'est-ce qui sort? Le travail s'arrête. Un nouveau membre de l'équipe ne comprend pas quoi et comment cela fonctionne, fonctionne à moitié, tout en perdant du temps en équipe.
Et s'il n'y a rien de ce qui précède, mais que je dois travailler?
Il se trouve que toutes les exigences ci-dessus sont devenues obligatoires dans l'un de mes projets.
Le projet était associé à la location de biens immobiliers et a été développé pour deux plateformes: IOS et Android. Le processus de développement a commencé comme les autres. Plus tard, il s'est avéré que le concepteur n'était pas pleinement familiarisé avec les applications mobiles. Quels guides il ne savait pas. La conception a été accompagnée d'éléments transparents, les polices n'ont été utilisées que pour une seule plate-forme. La coloration pourrait être décrite comme utilisant «50 nuances de gris».
On m'a donné un fichier * .psd. Il semble que ce ne soit rien de mal. Ces fichiers sont remis par de nombreux concepteurs. Mais j'ai dû installer le package Adobe pour jeter un œil à la mise en page. Le fichier était très «lourd» et ouvert pendant environ 10 minutes. Tous les écrans n'étaient pas dessinés séparément sur l'espace de travail. Ils étaient superposés en tant que couches, et pour voir un écran, vous deviez désactiver tous les autres. Comme je n'avais pas d'expérience significative avec le package, j'ai pensé à Avocode comme un outil de traitement du matériel de conception. Bien sûr, ce programme n'est pas parfait, mais il m'a littéralement sauvé.
Le prototype cliquable m'a été transféré dans InVision. Remarque, juste un prototype cliquable sans écrans en direct.
Conclusions:
Ce que j'attendais du designer:
- prototype cliquable et écrans en direct (InVision, Zeplin ou Figma)
- savoirs traditionnels révisés avec une description du fonctionnement des écrans
- écrans de carte avec transitions
- histoire d'utilisateur
- ressources hachées de tailles @ 1, @ 2, @ 3
- polices
De tout ce qui précède, je n'ai reçu qu'un prototype cliquable et un fichier * psd.
Le projet est terminé et téléchargé dans le magasin. Mais pour atteindre ce résultat, mon équipe a traversé sept cercles de l'enfer ou, comme on dit, a rencontré certaines difficultés.
Beaucoup seront en désaccord et diront que le matériel fourni est suffisant. Mais nous parlons de professionnalisme et de l'apparence de la situation du côté des développeurs. Après tout, un concepteur d'applications mobiles n'est pas seulement un artiste. Il s'agit d'un membre d'une équipe travaillant sur un projet complexe. Il doit bien faire son travail, car pour lui ce n'est pas la fin du travail sur le projet, mais pour l'équipe ce n'est que le début.
Merci à tous pour votre attention et vos projets réussis!
Liens utiles:
Directives IOSConsignes pour AndroidProblèmes de développement du projet mobile héritéFigmaEsquisse