Très souvent dans une entreprise, le design appartient entièrement au designer. Il peut même soudainement le changer complètement, malgré les cris de protestation des "fronts" et des "mobilshchiki". Nous avons une opinion différente: la vision du monde interne du concepteur ou la vision du développeur ne devrait pas affecter considérablement le produit. La conception de produits est la partie visible de l'entreprise avec laquelle le client interagit. Le designer ne peut pas introduire lui-même sa «liste de souhaits», il doit se concentrer sur les besoins des clients. Les bons produits se développent de manière organique, avec un œil sur le client. Cela s'applique à la fois à la saturation fonctionnelle et à la conception.
Un concepteur ne doit pas être porteur d'exigences pour une application; une entreprise doit dicter ce qu'elle sera. Peu importe qui travaille sur la conception des paiements électroniques, le site et l'application seront beaux et pratiques, et le style ne changera pas de 180 °. Ce principe fonctionne au bénéfice des développeurs frontaux et mobiles.
Aujourd'hui, moi, le concepteur du projet Timur, je vais vous dire comment nous avons repensé l'application mobile et comment notre système de conception est apparu.
Comment tout a commencé
Lorsque je suis arrivé au projet, l'application ressemblait à ceci:
Et avant cela, c'était généralement comme ça:
Ce qui ne me convenait pas:
1. La demande n'a pas évolué. Au départ, nous avions 2 devises (EUR et USD) et 2 cartes (pour les mêmes devises). Ils étaient rigidement interconnectés visuellement et logiquement. La section dollar est une carte dollar et ainsi de suite. Ensuite, RUB a été ajouté et la mise en page entière a commencé à "disparaître". Pour ajouter de nouveaux éléments, il fallait utiliser des béquilles. EPayments prévoit d'étendre la liste des devises et nous devions trouver comment les ajouter sans douleur pour le client. Le comportement sur tous les écrans doit rester prévisible. Si sur un écran la liste des devises a été traitée par un modèle de comportement spécifique, alors sur l'autre écran le modèle de travail avec les devises doit être répété.
2. Conception obsolète. L'application avait l'air très "poubelle" et dure, je voulais plus d'air et moins d'éléments inutiles. Pourquoi avons-nous besoin de dégradés et de "joliesse" si après 5 minutes les yeux commencent à se fatiguer dans l'application?
3. La différence de conception. Pour iOS et Android, il y avait 2 applications fondamentalement différentes. Si une personne passait d'un système d'exploitation à un autre, elle perdait toute l'expérience utilisateur accumulée. Le propriétaire de Samsung n'a pas pu dire au propriétaire de l'iPhone comment mener l'opération.
4. Flux de travail non optimal. Lorsque nous avons eu une nouvelle façon de transférer des fonds du portefeuille, cette tâche est venue à l'analyste qui a fait la mocap. Puis elle est venue vers moi et un écran a été dessiné pour la traduction. Ensuite, le développeur mobile a tout transformé en code et l'a enfoncé dans l'application. Il s'agit d'un processus malsain, à partir duquel il a été possible de jeter 80% des coûts de main-d'œuvre. Vous pouvez gagner beaucoup de temps ici en éliminant simplement le concepteur de la chaîne de montage. S'il existe des éléments d'interface prêts à l'emploi, vous pouvez en assembler des fenêtres de traduction.
Concevoir un avenir meilleur
Et j'ai donc commencé à travailler. Tout d'abord, je voulais créer une application conviviale. Les services financiers ne devraient généralement pas occuper longtemps un client. Vous devez y naviguer rapidement, choisir une opération, la mener et poursuivre vos activités.
Une autre constante importante est la convivialité des développeurs. Si nous avons une nouvelle puce, une nouvelle monnaie ou un nouveau service, les fronts et les mobilisateurs ne devraient pas souffrir et remuer tous les styles. Ils ajoutent simplement une nouvelle fonctionnalité qui semble claire et attendue.
Je cherchais l'analogie la plus simple et j'ai réalisé que nous avions besoin d'un constructeur de fenêtres. Nous avons un ensemble de contrôles (arrière, avant, sélection de compte, saisie des détails) et des règles pour travailler avec eux (couleurs, retraits, tailles des éléments). Dans le concepteur, les analystes et les travailleurs mobiles peuvent créer eux-mêmes de nouvelles cartes de service et fenêtres modales sans venir me «saluer».
Il était important de considérer que le produit évolue en largeur. Aujourd'hui, nous avons 3 devises, en un an il peut y en avoir 33. Aujourd'hui, nous donnons 15 façons de transférer de l'argent, demain ce sera 115. Dans l'application, de nouvelles entités peuvent apparaître: cartes virtuelles, achat d'actions ou autres services.
Briser les chaînes de limitations
Problème : le projet comporte un nombre croissant d'éléments - devises, méthodes de transfert, etc. De nombreux éléments sont disposés horizontalement, plus il y en aura, plus il sera gênant de l'utiliser.
Solution : prévoir une expansion à l'avance, choisir un positionnement pratique des éléments.
Le principal problème de la version précédente est la mise à l'échelle. Nous avons donc un écran conditionnel avec une résolution de 480 * 720 px. Et horizontalement, il y a 3 onglets avec des méthodes de transfert d'argent. Eh bien, demain, ils auront 15 ans. Qui dans leur bon sens fera défiler 15 onglets vers la droite? Ou avez-vous besoin de les faire micro-dimensionnés afin que vous puissiez y entrer uniquement avec votre petit doigt?
Dans ePayments, le client a un portefeuille avec plusieurs sections monétaires. L'élément le plus évolutif de l'interface utilisateur mobile est la liste. Il peut être renversé presque sans fin avec un mouvement complètement familier. Même s'il y a soudainement trop d'éléments, vous pouvez toujours fixer le filtre ou rechercher.
La limite de commodité se situe autour de 10 devises ou méthodes de transfert. Quand il y en aura plus, nous connecterons le deuxième mécanisme, qui est maintenant en développement - les sections sélectionnées. Le client choisit lui-même les sections monétaires les plus importantes pour lui et les marque d'un astérisque. Ou construit votre tableau de bord dans le constructeur, un peu comme l'écran de démarrage de Jira.
De plus, j'avais un "hamburger" à gauche et une barre à tapotement en bas. Les opérations les plus importantes que nous avons placées sur le panneau inférieur. Tout d'abord, vous regardez l'équilibre des sections et des cartes. Ensuite, vous pouvez aller à la réception ou au transfert, voir l'historique des transactions ou échanger des devises. Toutes les choses moins importantes que je mets dans le "burger". Maintenant, il y a, par exemple, un programme d'affiliation auquel on accède moins fréquemment.
D'accord, le problème est résolu, passez au suivant.
Nous gardons les différences dans le passé
Problème : les applications iOS et Android ne se ressemblent pas. Leur conception est dépassée, l'interface a beaucoup d'éléments supplémentaires. Il est difficile pour le client de se concentrer, il se fatigue rapidement.
Solution : faites des applications selon les directives, mais avec une conception unifiée. Nettoyer des dégradés, travailler sur la convivialité.
Comme je l'ai dit, les versions pour Android et iOS étaient des applications fondamentalement différentes. Il n'y a rien de bon pour le client ou pour nous. De plus, les développeurs ont eu des problèmes pour lancer de nouvelles fonctionnalités et tester. Par conséquent, nous avons décidé de tout mettre sous une seule forme.
Vous ne pouvez pas faire des demandes identiques. Google a Material Design, Apple a Human Interfaces. Mais les éléments de base que nous rendons similaires. La grille, la plupart des contrôles et l'emplacement des blocs sont les mêmes. Les contrôles responsables de la structure de base sont adaptés aux guides du système d'exploitation. La solution la plus simple consiste à porter entièrement l'application. Mais c'est plutôt un signe de paresse et d'ignorance des guides. Et les guides sont écrits par des gens beaucoup plus intelligents que nous, ça vaut le coup de les écouter.
Le premier, nous avons mis à jour l'application sur Android. C'était moins cher aux "points d'histoire", la plupart de nos clients utilisent cet OS. De plus, à un moment donné, nous avons eu un déséquilibre dans l'équipe de développement mobile - il y avait plus de personnes dans l'équipe de développement Android et nous pouvions en affecter certaines pour la refonte. Cette version a progressé et la version pour iOS la rattrape progressivement.
Il est basé sur des guides de conception de matériaux et grâce à cela, nous avons une application dans laquelle une personne avec Xiaomi conditionnelle est au courant de tout. Il apprend rapidement comment lui envoyer l'argent gagné sur une carte bancaire.
Lorsque nous avons lancé la refonte, nous avons commencé à recueillir des réactions et des critiques constructives. Premièrement, il y avait un petit flot de négativité de la part de ceux qui n'aiment pas la refonte en tant que phénomène. Ceci est normal et ne devrait pas avoir peur. Chaque service est confronté à cela. Ensuite, tout se calme et vous pouvez collecter des informations utiles.
Au début, la note a légèrement baissé, puis est revenue à 4,6. Nous avons fait des commentaires critiques et les critiques sont redevenues bonnes et gentilles. À partir de ce moment, vous pouvez prendre en charge l'application pour iOS.
Maintenant, les applications sont assez similaires. Certaines choses sont délibérément faites non pas selon les directives, mais la principale mesure est la réaction du client. Tout semblait convenir aux utilisateurs: l'évaluation n'a pas changé, nous avons été remerciés pour la refonte des avis.
Le fait que les applications soient devenues similaires s'est reflété dans le développement. Maintenant, ils sont plus faciles à tester, les cas dans Testrail sont les mêmes. Toute la documentation sur les cas est dupliquée - naturellement, telle que modifiée. Par exemple, lorsque nous préparons une fonctionnalité dans une application iOS, elle dispose déjà de JSON d'Android et les développeurs n'ont pas à entrer dans les demandes.
Nous donnons les rênes du gouvernement
Problème : le processus de développement n'est pas optimisé. Chaque nouvelle carte de traduction est dessinée et développée à partir de zéro.
Solution : créer un ensemble d'éléments et de règles prêts à l'emploi, transformant le processus en "concepteur".
L'idée du concepteur est apparue avec la refonte de l'application, mais nous l'avons implémentée un peu plus tard. Comme je l'ai dit, l'application ne devrait pas dépendre de moi. Si nous introduisons une nouvelle fonctionnalité, la tâche passe de l'analyste aux développeurs mobiles. Ils assemblent une fenêtre à partir des contrôles finis, vérifient ses styles, ses marges et tout le reste - et le tour est joué, la fenêtre est prête. Je peux faire une icône, mais ma participation directe devrait s'arrêter là.
Tout d'abord, j'ai dessiné chaque écran individuellement. Il a ensuite regroupé les éléments récurrents: listes, commandes, boutons, illustrations, écrans de confirmation, etc. Lorsque l'application était prête, j'avais une interface utilisateur de composant à part entière.
Regardez les éléments, tout le monde a quelque chose de similaire:
• rubrique
• "retour"
• liste déroulante
• ligne pour saisir les détails
• "suivant"
Nous faisons ces éléments à l'avance. De plus, nous préparons des guides pour les couleurs, les retraits et les polices. À la sortie, nous obtenons un constructeur dans lequel le développeur transforme le dessin dans la peinture conditionnelle de l'analyste en une fenêtre de traduction terminée.
Naturellement, les travailleurs mobiles ont dû travailler pour transformer un tas d'écrans en un système de composants soigné. Mais cela leur est arrivé par la suite: il n'était plus nécessaire d'aller chez Zeplin pour la mise en page de l'écran, le maquiller et le stocker à l'avenir. Il y a des composants, il y a une feuille de style stricte.
Pour résumer
J'aime ce que nous avons fait. L'application est devenue plus belle, elle a été appréciée par les clients. Il est devenu plus facile pour les fronts et les mobilisateurs de fonctionner.
Nous n'utilisons pas encore pleinement les mesures qui montrent comment le comportement des utilisateurs a changé. Alors maintenant, nous ne pouvons que juger par les notes et les commentaires des clients. La note est restée la même - 4,6 sur Google Play, 4,8 sur l'AppStore. La plupart des critiques négatives concernent le processus de vérification, il semble aux clients depuis longtemps. Et dans le positif, l'application est souvent louée.
Autre métrique, uniquement interne: j'ouvre très rarement un fichier d'esquisse avec un projet mobile. Les développeurs ajoutent de nouvelles façons de déposer et de retirer sans moi. Cela signifie que l'interface utilisateur du composant fonctionne et j'ai pu rendre la conception systémique, sans la dictature du concepteur.
Nous prévoyons maintenant de mettre le produit sous un seul aspect sur différentes plates-formes, y compris la version de bureau. De plus, nous prévoyons de «pelleter» toute la structure de scénario des fonctionnalités dans les applications mobiles afin que le client passe encore moins de temps sur les opérations. Eh bien, en même temps, nous abandonnerons le burger sur la gauche - c'est un modèle obsolète, il y a des options plus pratiques.
Vous cherchez un emploi?
Nous recherchons des employés pour travailler dans un bureau à Saint-Pétersbourg. Si vous êtes intéressé par la fintech, nous vous attendons. Vous trouverez ci-dessous les offres d'emploi et des liens vers les pages correspondantes de hh.ru.