Wie wir eine mobile Anwendung erstellt haben, die keinen Designer benötigt

Sehr oft liegt das Design in einem Unternehmen ganz beim Designer. Er kann es sogar plötzlich komplett ändern, trotz der protestierenden Schreie der "Fronten" und "Mobilshchiki". Wir sind anderer Meinung: Das interne Weltbild des Designers oder die Vision des Entwicklers sollten das Produkt nicht stark beeinflussen. Produktdesign ist der sichtbare Teil des Geschäfts, mit dem der Kunde interagiert. Der Designer kann seine „Wunschliste“ nicht selbst vorstellen, er muss sich auf die Bedürfnisse der Kunden konzentrieren. Gute Produkte entwickeln sich organisch mit Blick auf den Kunden. Dies gilt sowohl für die funktionale Sättigung als auch für das Design.

Ein Designer sollte kein Träger von Anforderungen für eine Anwendung sein, ein Unternehmen sollte vorschreiben, was es sein wird. Unabhängig davon, wer am Design von ePayments arbeitet, werden sowohl die Website als auch die Anwendung schön und praktisch sein, und der Stil wird sich um 180 ° nicht dramatisch ändern. Dieses Prinzip kommt Frontend- und Mobile-Entwicklern zugute.

Heute werde ich, der Projektdesigner Timur, Ihnen erzählen, wie wir die mobile Anwendung neu gestaltet haben und wie unser Designsystem aussah.



Wie alles begann


Als ich zum ersten Mal zu dem Projekt kam, sah die Anwendung folgendermaßen aus:



Und vorher war es im Allgemeinen so:



Was mir nicht dazu passte:

1. Die Anwendung wurde nicht skaliert. Anfangs hatten wir 2 Währungen (EUR und USD) und 2 Karten (für die gleichen Währungen). Sie waren sowohl visuell als auch logisch starr miteinander verbunden. Der Dollarbereich ist eine Dollarkarte und so weiter. Dann wurde RUB hinzugefügt und das gesamte Layout begann zu "gehen". Um neue Elemente hinzuzufügen, mussten Krücken verwendet werden. EPayments hat Pläne, die Liste der Währungen zu erweitern, und wir mussten herausfinden, wie wir sie ohne Schmerzen für den Kunden hinzufügen können. Das Verhalten auf allen Bildschirmen sollte vorhersehbar bleiben. Wenn auf einem Bildschirm die Liste der Währungen nach einem bestimmten Verhaltensmuster verarbeitet wurde, sollte auf dem anderen Bildschirm das Muster der Arbeit mit Währungen wiederholt werden.



2. Veraltetes Design. Die Anwendung sah sehr "Müll" und hart aus, ich wollte mehr Luft und weniger unnötige Elemente. Warum brauchen wir Farbverläufe und „Hübschheit“, wenn die Augen nach 5 Minuten bei der Anwendung müde werden?



3. Der Unterschied im Design. Für iOS und Android gab es zwei grundlegend unterschiedliche Anwendungen. Wenn eine Person von einem Betriebssystem zu einem anderen wechselte, verlor sie die gesamte gesammelte Benutzererfahrung. Der Besitzer von Samsung konnte dem Besitzer des iPhone nicht sagen, wie der Vorgang durchzuführen ist.



4. Nicht optimaler Workflow. Als wir eine neue Möglichkeit hatten, Geld aus der Brieftasche zu überweisen, kam diese Aufgabe zu dem Analysten, der das Mocap erstellt hat. Dann kam sie zu mir und ein Bildschirm wurde zur Übersetzung gezeichnet. Dann wandelte der mobile Entwickler alles in Code um und rammte es in die Anwendung. Dies ist ein ungesunder Prozess, bei dem 80% der Arbeitskosten abgeworfen werden konnten. Sie können hier viel Zeit sparen, indem Sie den Designer einfach vom Fließband entfernen. Wenn vorgefertigte Schnittstellenelemente vorhanden sind, können Sie daraus Übersetzungsfenster zusammenstellen.



Eine bessere Zukunft gestalten


Und so fing ich an zu arbeiten. Zunächst wollte ich eine benutzerfreundliche Anwendung erstellen. Finanzdienstleistungen sollten einen Kunden im Allgemeinen nicht lange beschäftigen. Darin müssen Sie schnell navigieren, einen Vorgang auswählen, durchführen und Ihr Geschäft weiter betreiben.

Eine weitere wichtige Konstante ist die Entwicklerfreundlichkeit. Wenn wir einen neuen Chip, eine neue Währung oder einen neuen Service haben, sollten Fronten und Mobilisierer nicht alle Stile leiden und aufrühren. Sie fügen einfach eine neue Funktion hinzu, die klar und erwartet aussieht.

Ich suchte nach der einfachsten Analogie und stellte fest, dass wir einen Fensterkonstruktor brauchten. Wir haben eine Reihe von Steuerelementen (Zurück, Vorwärts, Kontoauswahl, Eingabe von Details) und Regeln für die Arbeit mit ihnen (Farben, Einrückungen, Elementgrößen). Im Designer können Analysten und mobile Mitarbeiter selbst neue Servicekarten und modale Fenster erstellen, ohne zu mir zu kommen, um sich zu verbeugen.

Es war wichtig zu berücksichtigen, dass sich das Produkt in der Breite entwickelt. Heute haben wir 3 Währungen, in einem Jahr können es 33 sein. Heute geben wir 15 Möglichkeiten, Geld zu überweisen, morgen sind es 115. In der Anwendung können völlig neue Entitäten erscheinen: virtuelle Karten, Aktienkauf oder andere Dienstleistungen.

Verwerfen Sie die Fesseln der Einschränkungen


Problem : Das Projekt enthält eine wachsende Anzahl von Elementen - Währungen, Übertragungsmethoden usw. Viele Elemente sind horizontal angeordnet. Je mehr Elemente vorhanden sind, desto unpraktischer ist die Verwendung.

Lösung : Sorgen Sie für eine Erweiterung im Voraus und wählen Sie eine bequeme Positionierung der Elemente.

Das Hauptproblem der vorherigen Version ist die Skalierung. Wir haben also einen bedingten Bildschirm mit einer Auflösung von 480 * 720 px. Und horizontal gibt es 3 Registerkarten mit Geldtransfermethoden. Nun, morgen werden sie 15 Jahre alt. Wer wird bei klarem Verstand 15 Registerkarten nach rechts scrollen? Oder müssen Sie sie mikrogroß machen, damit Sie nur mit Ihrem kleinen Finger in sie eindringen können?



In ePayments verfügt der Kunde über eine Brieftasche mit mehreren Währungsabschnitten. Das skalierbarste Element der mobilen Benutzeroberfläche ist die Liste. Es kann mit einer völlig vertrauten Bewegung fast endlos nach unten geklappt werden. Auch wenn plötzlich zu viele Elemente vorhanden sind, können Sie den Filter jederzeit befestigen oder suchen.



Das Convenience-Limit liegt bei 10 Währungen oder Überweisungsmethoden. Wenn es mehr davon gibt, werden wir den zweiten Mechanismus verbinden, der sich derzeit in der Entwicklung befindet - die ausgewählten Abschnitte. Der Kunde wählt selbst aus, welche Währungsabschnitte für ihn wichtiger sind, und markiert sie mit einem Sternchen. Oder erstellt Ihr Dashboard im Konstruktor, ähnlich wie der Startbildschirm in Jira.

Außerdem hatte ich links einen „Burger“ und unten eine Tap Bar. Die wichtigsten Operationen haben wir auf der Unterseite platziert. Zunächst betrachten Sie das Gleichgewicht zwischen Abschnitten und Karten. Anschließend können Sie zur Rezeption oder Überweisung gehen, den Transaktionsverlauf anzeigen oder die Währung umtauschen. All die weniger wichtigen Dinge, die ich in den „Burger“ gesteckt habe. Jetzt gibt es zum Beispiel ein Partnerprogramm, auf das weniger häufig zugegriffen wird.



Okay, das Problem ist behoben. Fahren Sie mit dem nächsten fort.

Wir behalten die Unterschiede in der Vergangenheit


Problem : iOS- und Android-Apps sind nicht gleich. Ihr Design ist veraltet, die Oberfläche hat viele zusätzliche Elemente. Es fällt dem Kunden schwer, sich zu konzentrieren, er wird schnell müde.
Lösung : Stellen Sie Anträge gemäß den Richtlinien, jedoch mit einem einheitlichen Design. Reinigen Sie von Farbverläufen und arbeiten Sie an der Benutzerfreundlichkeit.

Wie gesagt, die Versionen für Android und iOS waren grundlegend unterschiedliche Anwendungen. Es gibt weder für den Kunden noch für uns etwas Gutes. Darüber hinaus hatten Entwickler Probleme beim Rolling neuer Funktionen und beim Testen. Deshalb haben wir uns entschlossen, alles in eine Form zu bringen.

Sie können keine identischen Anträge stellen. Google hat Material Design, Apple hat Human Interfaces. Aber die Grundelemente machen wir ähnlich. Das Raster, die meisten Steuerelemente und die Anordnung der Blöcke wurden gleich. Die Steuerelemente, die für die Grundstruktur verantwortlich sind, sind auf Betriebssystemhandbücher zugeschnitten. Die einfachste Lösung besteht darin, die Anwendung vollständig zu portieren. Dies ist jedoch eher ein Zeichen der Faulheit und Unwissenheit der Führer. Und die Leitfäden werden von Leuten geschrieben, die um ein Vielfaches schlauer sind als wir. Es lohnt sich, ihnen zuzuhören.

Das erste Mal haben wir die Anwendung auf Android aktualisiert. An den "Story Points" war es billiger, die meisten unserer Kunden verwenden dieses Betriebssystem. Außerdem hatten wir irgendwann ein Ungleichgewicht im mobilen Entwicklungsteam - es gab mehr Leute im Android-Entwicklungsteam, und wir konnten einige davon für das Redesign zuweisen. Diese Version wurde weiterentwickelt und die Version für iOS holt sie nun allmählich ein.

Es basiert auf Material Design-Anleitungen und dank dieser haben wir eine Anwendung, in der eine Person mit bedingtem Xiaomi mit allem vertraut ist. Er lernt schnell, wie man ihm das verdiente Geld auf eine Bankkarte schickt.



Als wir das Redesign starteten, sammelten wir Reaktionen und konstruktive Kritik. Erstens gab es einen kleinen Strom von Negativität von denen, die Redesign nicht als Phänomen mögen. Das ist normal und sollte keine Angst haben. Jeder Dienst ist damit konfrontiert. Dann beruhigt sich alles und Sie können nützliche Informationen sammeln.

Das Rating ging zunächst etwas zurück und kehrte dann auf 4,6 zurück. Wir haben einige kritische Kommentare abgegeben und die Bewertungen wurden wieder gut und nett. Ab diesem Moment können Sie die Anwendung für iOS übernehmen.

Jetzt sind die Anwendungen ziemlich ähnlich. Einige Dinge werden absichtlich nicht gemäß den Richtlinien ausgeführt, aber die Hauptmetrik ist die Kundenreaktion. Für die Benutzer schien alles bequem zu sein: Die Bewertung änderte sich nicht, wir wurden für die Neugestaltung in den Bewertungen gedankt.

Die Tatsache, dass die Anwendungen ähnlich wurden, spiegelte sich in der Entwicklung wider. Jetzt sind sie einfacher zu testen, die Fälle in Testrail sind die gleichen. Alle Falldokumentationen werden - natürlich in der geänderten Fassung - dupliziert. Wenn wir beispielsweise eine Funktion in einer iOS-Anwendung vorbereiten, verfügt sie bereits über JSON von Android, und Entwickler müssen keine Anforderungen bearbeiten.

Wir geben die Regierung


Problem : Der Entwicklungsprozess ist nicht optimiert. Jede neue Übersetzungskarte wird von Grund auf neu gezeichnet und entwickelt.
Lösung : Erstellen Sie eine Reihe vorgefertigter Elemente und Regeln und verwandeln Sie den Prozess in einen "Designer".

Die Idee des Designers erschien zusammen mit der Neugestaltung der Anwendung, aber wir haben sie etwas später implementiert. Wie gesagt, die Bewerbung sollte nicht von mir abhängen. Wenn wir eine neue Funktion einführen, geht die Aufgabe vom Analysten zu den mobilen Entwicklern. Sie bauen ein Fenster aus den fertigen Steuerelementen zusammen, überprüfen seine Stile, Ränder und alles andere - und voila, das Fenster ist fertig. Ich kann ein Symbol erstellen, aber meine direkte Teilnahme sollte dort enden.

Zuerst habe ich jeden Bildschirm einzeln gezeichnet. Dann gruppierte er sich wiederholende Elemente: Listen, Steuerelemente, Schaltflächen, Abbildungen, Bestätigungsbildschirme usw. Als die Anwendung fertig war, hatte ich eine vollwertige Komponenten-Benutzeroberfläche.



Schauen Sie sich die Elemente an, jeder hat etwas Ähnliches:
• Überschrift
• "zurück"
• Droplist
• Zeile zur Eingabe von Details
• "weiter"

Wir machen diese Elemente im Voraus. Außerdem bereiten wir Anleitungen für Farben, Einrückungen und Schriftarten vor. Bei der Ausgabe erhalten wir einen Konstruktor, in dem der Entwickler die Zeichnung in der bedingten Farbe vom Analysten in ein fertiges Übersetzungsfenster umwandelt.

Natürlich mussten die mobilen Mitarbeiter arbeiten, um aus einer Reihe von Bildschirmen ein ordentliches Komponentensystem zu machen. Aber es passierte ihnen später: Es war nicht mehr nötig, für das Layout des Bildschirms nach Zeplin zu gehen, es zu erfinden und in Zukunft aufzubewahren. Es gibt Komponenten, es gibt ein striktes Stylesheet.

Zusammenfassend


Mir gefällt, was wir gemacht haben. Die Anwendung ist schöner geworden, sie wurde von den Kunden geschätzt. Es ist für Fronten und Mobilisierer einfacher geworden, zu arbeiten.



Wir verwenden Metriken, die zeigen, wie sich das Benutzerverhalten geändert hat, noch nicht vollständig. Jetzt können wir nur noch nach Kundenbewertungen und -bewertungen beurteilen. Die Bewertung blieb gleich - 4,6 bei Google Play, 4,8 im AppStore. Die meisten negativen Bewertungen beziehen sich auf den Überprüfungsprozess, es scheint den Kunden eine lange Zeit. Und positiv ist, dass die App oft gelobt wird.

Eine andere Metrik, nur intern: Ich öffne sehr selten eine Skizzendatei mit einem mobilen Projekt. Entwickler fügen neue Möglichkeiten zum Ein- und Auszahlen ohne mich hinzu. Dies bedeutet, dass die Benutzeroberfläche der Komponente funktioniert und ich das Design ohne die Diktatur des Designers systemisch gestalten konnte.

Jetzt planen wir, das Produkt auf verschiedenen Plattformen, einschließlich der Desktop-Version, auf einen Blick zu zeigen. Darüber hinaus planen wir, die gesamte Szenariostruktur der Funktionen in mobilen Anwendungen zu „schaufeln“, damit der Client noch weniger Zeit für den Betrieb benötigt. Nun, zur gleichen Zeit werden wir den Burger auf der linken Seite aufgeben - dies ist ein veraltetes Muster, es gibt bequemere Optionen.

Auf der Suche nach einem Job?


Wir suchen Mitarbeiter für ein Büro in St. Petersburg. Wenn Sie sich für Fintech interessieren, warten wir auf Sie. Nachfolgend finden Sie offene Stellen und Links zu den entsprechenden Seiten von hh.ru.

Source: https://habr.com/ru/post/de437250/


All Articles