Die Geschichte eines Redesigns, das den Entwicklungsansatz bei ISPsystem verändert hat.
Ich bin seit April 2016 bei ISPsystem. Zu diesem Zeitpunkt war die Situation beim Produktdesign wie folgt: Produktentscheidungen wurden vom Management und von Programmierern getroffen, es gab keine Designer oder Designer. Die Marktsituation erforderte Produkte mit „anderen Schnittstellen“, daher entschied sich das Management, den
BILLmanager- Client-Teil neu zu gestalten. Dies sollte ein Testballon sein, der erste Versuch, etwas mit einem neuen Design zu tun.
Ich war der einzige UX-Designer im Unternehmen: Ich habe ein vorhandenes Produkt untersucht, mich mit Benutzerrecherchen befasst und das Feedback von Partnern und deren Vermarktern kennengelernt. Dies sind die üblichen Praktiken des Produktdesigns unter Berücksichtigung der Besonderheiten eines komplexen Produkts. Der Produktmanager hat mir sehr geholfen, da er das Produkt am besten kannte.
Jede Woche zeigte ich der Unternehmensleitung das Ergebnis in Form von Prototypen, Schaltkreisen usw. Dies ähnelt der Arbeitsweise von Kunden-Designern mit Kunden mit allen Vor- und Nachteilen: Sie können sich von der Verantwortung für Entscheidungen entlasten. Die Hauptsache ist, sie an das Management zu „verkaufen“. Da ich jedoch bereits Erfahrung in einem Produktunternehmen hatte und das Management mir in diesen Angelegenheiten vertraute, arbeiteten wir schnell gemeinsam an Lösungen, die ich entwickelte und in einen Prototyp verwandelte.
Entwickler treffen Prototyp
Bis August 2016 waren die Prototypen des BILLmanager-Kunden in ihrer konzeptionellen Form fertig. Die Funktionalität der alten Version des Produkts wurde mit einigen Verbesserungen vollständig auf die neue Benutzeroberfläche übertragen. Die Prototypen waren aus visueller Sicht gut entwickelt, aber ich wollte mehr, also bestellte ich ein visuelles Design bei einem Drittunternehmen. Wir stellten jedoch schnell fest, dass dieser Versuch erfolglos war, dass ständige iterative Arbeiten an der visuellen Komponente erforderlich waren und dass wir einen visuellen Designer für die Mitarbeiter benötigten. Innerhalb weniger Monate entwickelten wir unsere eigene visuelle Sprache. Tatsächlich hatten wir zu diesem Zeitpunkt mehrere Teile des zukünftigen Designsystems: eine visuelle Sprache, Elemente und Vorlagen.
Parallel dazu begannen die Entwickler ab etwa August 2016 mit der Implementierung einer neuen Schnittstelle. Die Jungs betrachteten den Prototyp als Alternative zur technischen Aufgabe. In solchen Momenten tauchten in großer Zahl Fragen auf, die sich auf eines beschränken: Tun wir, was Programmierer schnell und einfach implementieren oder was von einem Designer erfunden und entworfen wurde? Um diese Probleme schnell zu lösen und die Kommunikation zu vereinfachen, haben wir ein Team aus Designern und Front-End zusammengestellt.
UX-Abteilung als Team von Designern und Front-Renderern
Mitte Herbst 2016 wurde unter meiner Leitung eine UX-Abteilung im Unternehmen gebildet, die aus UX-Designern, einem visuellen Designer, Front-End-Tendern und Testern bestand. Unsere unmittelbare Aufgabe bestand darin, das persönliche Konto des ISP-Systems mit einer neuen Schnittstelle (wir verwenden BILLmanager zu Hause) bis Ende März 2017 zu starten, und wir hatten zwei Gruppen von Problemen. Entwickler haben den Zeitpunkt ihrer Arbeit schlecht vorhergesagt, und wir haben nicht ganz verstanden, wie man eine Interaktion zwischen Entwicklern und Designern aufbaut.
Was wir Entwicklern geben
Wenn Sie Sketch und Zeplin verwenden, ist die Interaktion zwischen Designern und Entwicklern sehr einfach. Wir hatten jedoch mehr als 150 Seiten in einem interaktiven Prototyp, den wir als Alternative zu TK für Programmierer und als Spezifikation für Tester verwenden lernten. Wir wollten nicht alle mehr als 150 Seiten mit verschiedenen Status in Sketch rendern und kamen zu dem Schluss, dass wir dies nur für eindeutige Seiten tun würden. Außerdem sollten alle Elemente in Zeplin enthalten sein: Schaltflächen, Formularfelder usw. Nach einiger Zeit haben wir den Namen eines solchen Ansatzes gelernt - dies ist ein
Entwurfssystem, das auf atomarem Entwurf basiert . Es befindet sich noch in der Entwicklung, aber sowohl Designer als auch Entwickler verwenden es bereits. Der letzte im Unternehmen für das Designsystem ist der visuelle Designer.
Als Ergebnis liefern wir Entwicklern zwei Arten von Artefakten:
- Layouts dessen, was jemals ein Design-System in Zeplin (oder besser gesagt schon in Figma) werden wird,
- Produktprototypen, Alternative zu TK in Form von aus Axure generiertem HTML.
Gleichzeitig ist der UX-Designer immer bereit, Entwicklern und Testern mitzuteilen, was und wie es funktionieren und aussehen soll.
Scrum mit Designern
Im Februar 2017 haben wir beschlossen, die Genauigkeit der Prognosefristen zu verbessern, und versucht, Scrum zu implementieren. Die Komplexität unseres Scrums besteht darin, dass sich die Teammitglieder in Bezug auf Kompetenzen und Kultur stark unterscheiden. Designer sind nicht wie Programmierer: Wir planen unsere Aufgaben unterschiedlich, wir haben unterschiedliche Einstellungen zu dem, was als gutes Ergebnis angesehen wird.
So haben wir den Prozess aufgebaut:
- Designer sprinten vorwärts;
- Es gibt einen allgemein ausgearbeiteten Prototyp-Rückstand, in dem Sie sehen können, wie das gesamte Produkt aussehen sollte.
- Zum Zeitpunkt der Planung des Sprints stellen Designer Prototypen und Modelle des Teils des Produkts zur Verfügung, der für den Sprint geplant ist. Diese Prototypen werden vom UX-Designer so detailliert und beschrieben, dass Entwickler ihre Aufgaben festlegen und zerlegen können.
- Zum Zeitpunkt der Planung berät der UX-Designer Entwickler und Tester aktiv darüber, was und wie funktionieren soll.
- Zum Zeitpunkt der Planung muss der Produktmanager dem UX-Designer mitteilen, welcher Teil des Produkts im nächsten Sprint ausgeführt werden soll, damit der UX-Designer seine Arbeit planen kann.
Die Entwickler erkannten schnell den Wert eines UX-Designers, der schnell angegangen werden kann, wenn nicht klar ist, was und wie funktionieren soll. Konflikte treten immer noch auf, aber Scrum-Praktiken, Teamwork und gemeinsame Ziele helfen, sie zu überwinden.
Was hat der Tester damit zu tun?
Die Rolle des Testers in den Prozessen war sehr wichtig. Dies ist die Person, die die Produktfunktionalität am besten kennt. Der Tester war der erste, der sich die Prototypen eines UX-Designers ansah und schnell Feedback zur Einhaltung und Funktionalität von Prototypen gab. Genehmigte Prototypen werden für den Tester zu einer Wissensquelle über die Funktionsweise des Produkts. Beide Seiten waren an einer engen Zusammenarbeit interessiert.
Infolgedessen veröffentlichte das Team rechtzeitig die neue Schnittstelle des persönlichen Kontos des ISP-Systems. Wir haben gelernt, wie man an Scrum arbeitet, um die Arbeit der UX-Abteilung als Team aus Front-End und Designern vorherzusagen. Und bis zum Sommer 2017 standen sie vor einem neuen Problem.
BILLmanager ist ein flexibles Produkt. Und das ist ein Problem für den Designer
Wenn ein Designer ein Poster zeichnet, ein Buch setzt oder ein Cover für eine Zeitschrift erstellt, arbeitet er mit statischen Informationen. Es enthält bestimmten Text, bestimmte Bilder und andere Inhalte.
Wenn ein Designer eine Anwendungs- oder Site-Oberfläche entwirft, sind die Informationen nicht statisch. Es gibt Informationen darüber, was die Daten sein können, die Daten selbst jedoch nicht. Angenommen, es gibt ein Blog, jeder Blogeintrag hat einen Titel, eine Anmerkung, ein Veröffentlichungsdatum, ein Bild usw. Es gibt keinen bestimmten Titel, aber es besteht das Verständnis, dass es immer einen Titel geben wird und das Datum immer ein Datumsformat hat. Die Aufgabe ist komplizierter geworden, wir haben Datentypen, aber es gibt keine Daten: Wir müssen darüber nachdenken, welcher Inhalt sein kann, welche Einschränkungen ihm auferlegt werden können und sollten. Höchstwahrscheinlich gibt es weniger künstlerischen Wert als das Poster, aber der Designer möchte ein Ergebnis erzielen, das schön, bequem und verständlich ist.
Im Fall von BILLmanager kann der Administrator des Hosting-Anbieters die Einstellungen so ändern, dass beispielsweise für das Bestellformular eines dedizierten Servers die Felder unterschiedlich sein können. In einem Fall werden wir definitiv einen Prozessor, eine Festplatte und einen Speicher haben, und in dem anderen Fall wird dies nicht der Fall sein (oder wird, aber zum Beispiel ein Feld sein), und dies kann nicht vorhergesagt werden. In diesem Fall verfügt der Designer nicht einmal über einen festen Datensatz. Wir kennen nicht nur bestimmte Daten, wir kennen auch nicht die Typen dieser Daten. Dies erschwert die Arbeit.
Als wir mit der Erstellung der Box-Version begannen, begannen die Tester, alle in BILLmanager möglichen Einstellungen zu überprüfen. Dann wurde klar, dass einerseits die Prototypen nicht vollständig genug sind, um die Möglichkeiten flexibler Einstellungen von BILLmanager abzudecken. Andererseits war die Architektur des alten Produkts nicht flexibel genug, um eine große Anzahl von Designideen umzusetzen. Von Herbst 2017 bis Frühjahr 2018 haben wir die Prototypen neu gestaltet und nach Kompromissen gesucht, um dieses Problem zu lösen. Mit einigen Einschränkungen bei den Einstellungen wurde im Mai 2018 eine
Box-Version des Client-Teils von BILLmanager 6 Beta veröffentlicht .
UX-Abteilung für Designer
Während die UX-Abteilung Probleme mit der Flexibilität von BILLmanager löste, beschloss das Management, die Schnittstellen anderer Produkte des Unternehmens zu verarbeiten und Scrum- und Designprozesse in anderen Teams zu implementieren. Wir haben mit VMmanager 6 begonnen und ein vollwertiges Produktteam aus Teilnehmern unterschiedlicher Kompetenzen zusammengestellt, das autark ist, um ein Produkt zu erstellen: Back-End, Front-End, Tester, UX-Designer, Produkt- und Projektmanager. Es wurde klar, dass alle anderen Produkte schrittweise von denselben Teams entwickelt werden, und wir begannen einen schrittweisen Übergang zu einer Matrixstruktur für das Management der Produktentwicklung.
In diesem Zusammenhang sollte die UX-Abteilung nicht mehr zu den Produktteams gehören. Nach der Veröffentlichung des Client-Teils von BILLmanager 6 Beta wurde der größte Teil der UX-Abteilung Teil des BILLmanager-Teams und beschäftigt sich nun mit der Lösung von Architekturproblemen und der mobilen Version des Client-Teils. Gleichzeitig haben wir begonnen, eine UX-Abteilung aufzubauen, die mit allen Produkten gleichzeitig arbeiten kann.
UX Designer für jedes Produktteam. Design-Kompetenzzentrum
ISPsystem verfügt über vier komplexe Produkte. Wir haben dafür gesorgt, dass jedes Team seinen eigenen UX-Designer hat. Dies ist die Person, die für das Design seines Produkts verantwortlich ist. Zu seinen Aufgaben gehört die Vorbereitung von Prototypen für die Sprintplanung und die Kontrolle, dass alles, was für Entwickler erforderlich ist, in der pixelperfekten Version enthalten ist. Er ist der Leiter der Designpolitik des Unternehmens für sein Team. Eine seiner Aufgaben ist es, sicherzustellen, dass das Ergebnis der Entwicklung ein Produkt ist, das zum Design passt.
Wir haben auch mehrere Mitarbeiter, die das Zentrum der Designkompetenzen des Unternehmens bilden. Es enthält einen visuellen Designer. Dieses Zentrum bildet die Designpolitik der Produkte des Unternehmens, arbeitet am Designsystem. Sie unterrichtet UX-Designer in Teams, löst die komplexesten Designprobleme, bringt Entwicklern, Produkt- und Projektmanagern bei, wie sie mit UX-Designern arbeiten, und implementiert Designprozesse in Scrum-Teams.