In unserem Entwicklungsteam erstellen wir viele kleine Anwendungen, die ganz auf die spezifischen Bedürfnisse unserer Kunden ausgerichtet sind.
Daher haben wir oft Probleme mit der Erstellung einer einheitlichen Benutzererfahrung bezüglich:
Ich kann mir mehrere Ansätze für diese Probleme vorstellen ...
Was ist der beste Weg, um eine konsistente Nutzererfahrung oder einheitliche Ergebnisse im Allgemeinen zu erzielen? Persönlich mag ich keine meiner Ansätze, aber vielleicht ist das ein Missverständnis, also fühlen Sie sich frei, sie zu unterstützen:)
Ich hatte mehrere Positionen, an denen ich die GUI vollständig übernommen habe. Dies beinhaltete mich alle Designs / Mockups zu tun und überwachte auch das Use Case Schreiben, um sicherzustellen, dass alles konsistent war. Dies ist bei weitem der beste Ansatz, um Konsistenz sicherzustellen, aber es ist möglicherweise nicht immer der praktischste Ansatz.
Alternativ wäre es, Richtlinien zu schreiben, aber das ist nicht wirklich dasselbe wie ein gutes GUI-Design-Wissen / HCI-Fähigkeiten. Zumindest kann es Entwicklern beibringen, benutzerdefinierte Bibliotheken / Komponenten zu verwenden, die Ihr Unternehmen haben könnte.
Ein Muss ist ein Wörterbuch, das die Domänensprache enthält, die Sie verwenden und wie sie in der GUI verwendet werden soll. Dies ist eines der wichtigsten Dinge, die ein Lead-GUI-Entwickler tun muss.
Zumindest sollten Sie sicherstellen, dass Sie alles überprüfen, was von anderen Entwicklern gemacht wird, es sei denn, Sie kennen es und vertrauen darauf, dass es das Richtige tut. GUI-Design ist oft eine weit unterschätzte Fähigkeit und es ist wichtig zu bedenken, dass nicht jeder es ohne richtiges Training tun kann.
Vielleicht möchten Sie einen Standardsatz von Vorlagen erstellen. z.B. Wenn Sie eine Website-Vorlage mit vordefinierten CSS-Regeln, HTML-Layouts usw. erstellen, können Entwickler eine einheitliche Ausgabe in Bezug auf Aussehen und Handhabung erstellen.
Ich glaube, dass das größte Problem oft darin besteht, dass die Entwickler nicht wissen, dass es eine Richtlinie für eine bestimmte Designüberlegung gibt, und nicht, dass sie diese Richtlinien nicht umsetzen wollen. Es ist die Aufgabe des Managements sicherzustellen, dass sie dieses Wissen haben.
Sie werden immer ausführliche schriftliche Richtlinien benötigen, wenn Sie jede Art von Teamarbeit standardisieren und die "Individualität" ausschließen wollen, die dem Systemdesign inhärent ist.
Sie sollten jedoch bedenken, dass, egal wie detailliert Ihre Dokumente sind, wahrscheinlich eine unvorhergesehene Bedingung fehlt. Um dieser Wahrscheinlichkeit entgegenzuwirken, sollten Sie eine Politik der offenen Tür haben, bei der Teammitglieder immer zum Teamleiter kommen und solche Szenarien diskutieren können. Diese neuen Elemente sollten dann in das Richtlinien-Repository aktualisiert werden.
Ihre Leitliniendokumente sollten für alle Beteiligten im Projekt leicht zugänglich sein. Das Erstellen einer "cheat-sheet" -ready-Referenz ist oft eine gute Idee.
Ein Ansatz, der für mich früher funktionierte, ist eine gemeinsame Bibliothek für Basisklassen, die Designs und Layouts erzwingen oder anwenden.
Wir waren ein Team von 7 Entwicklern und fast schon Desktop-Apps. Daher haben wir Basisklassen für Formulare und meist verwendete allgemeine Steuerelemente erstellt und alle Icons und Bilder in das Quellcode-Repository gestellt dass alle Symbole und UI-Sprache (Etiketten, Nachrichten und Tooltips) konsistent sind.
ive hatte eine Position, wo ich der UI-Designer war und das hat gut funktioniert. es war meine Verantwortung, Mockups zu erstellen und sie als Master-Seiten ins Visual Studio zu bringen.
Die Programmierer würden dann kommen und die Logik hinzufügen.
Dies ist ein exzellenter Ansatz, da es keinen Stilführer oder Dokumentationsvolumen erfordert, wenn eine Person dafür verantwortlich ist.
Die Realität ist, dass die meisten Unternehmen niemanden speziell für eine UI-Rolle einstellen (mehr Unternehmen beginnen das jetzt schon vor ein paar Jahren).
Als Projektmanager für 5 Jahre bei 4 verschiedenen Unternehmen gibt es einen anderen Ansatz.
Ich glaube nicht viel daran, einen UI-Guide zu schreiben und zu erwarten, dass Programmierer ihm folgen. Theres ein paar Gründe dafür: 1) Programmierer oft nicht gut im UI-Design, 2) es ist eine Menge zu erinnern, 3) es ist kontraproduktiv.
UI-Style-Guides verlangsamen Programmierer, weil Sie erwarten, dass sie gut in etwas sind, was sie nicht gut können. Sie sind gut im Codieren - also lassen Sie sie programmieren.
Was bekommst du? Inkonsistenzen in der Schnittstelle. Dies geschieht sogar, wenn Sie Programmierern Mockups zur Verfügung stellen, von denen aus gearbeitet werden kann (z. B. enthält Ihr Mock-Up möglicherweise keine Fehlermeldung, die ein Programmierer möglicherweise zeigen muss).
Also, was ist die Lösung? Einfach - Sie haben eine Person, die die gesamte Benutzeroberfläche an Meilensteinpunkten überprüft und Fehler in Ihrem Issue Tracker protokolliert. Diese Fehler würden als UI oder niedrig markiert werden. Wenn es einen Skriptfehler gibt, ist es offensichtlich viel wichtiger, das zuerst zu beheben, dann einen UI-Fehler.
Die nächste Frage ist, wer sollte die Überprüfung machen? wieder, einfach - nur eine Person (für Konsistenz), und diese Person sollte derjenige sein, der am talentiertesten mit HCI / UI Design ist.
mein Punkt ist; Lass Programmierer nicht versuchen, UI-Designer zu sein. Wenn Sie einen UI-Fehler protokollieren, der dort im Issue Tracker steht, werden die Programmierer kommen und sie reparieren, wenn sie gut und bereit sind. und sie sind im Allgemeinen wirklich einfach zu reparieren, so dass sie als eine gute Pause für einen Programmierer dienen können, der 2-3 Stunden damit verbringen kann, ein ernsthaftes Datenkorruptionsproblem zu beheben (ja, das Reparieren eines UI-Bugs kann tatsächlich ein Stressabbau sein!).
Alles, was geschrieben und ausgehändigt / gemailt wird, wird vergessen. Ich würde vorschlagen, ein internes Wiki zu erstellen, in dem die Standards enthalten sind, Links zu Symbolen, Schritte zum Erstellen / Speichern von Arbeit, Namenskonventionen, Arbeitsbeispiele usw., auf die jeder zugreifen und sie aktualisieren kann
Sie sollten eine Art Dependency-Injektion mit XML-Dateien verwenden, ähnlich wie bei Spring kann bereitstellen.
Alle Entwickler sollten ihre Auswahl von GUI-Teilen nicht fest in das Programm integrieren, sondern diese Wahl der XML-Datei überlassen.
Dann muss eine einzige QA-Person die Anwendungen prüfen, und sollte sie nicht standardisiert sein, ändern Sie nur die XML-Datei, anstatt sie neu zu kompilieren, usw. '... Dies wird viel schneller und einfacher, da Sie den Code der Anwendung nicht sehen müssen.
Wenn Spring nicht mit Ihrer Umgebung funktioniert, bin ich mir sicher, dass Sie mit einem anderen Framework oder im schlimmsten Fall mit Ihnen arbeiten werden kann selbst ein kleines bauen, aber das wird viel mehr Zeit brauchen.
Erstellen Sie ein Dokument, das alle allgemeinen Funktionen für das Layout beschreibt.
Dieses Dokument sollte Folgendes enthalten:
Farbe des Hintergrunds Farbe des Textes Farbe des aktiven Textes Farbe des inaktiven Textes Farbe des Kommentartextes Schriftart Schriftgröße usw.
Stellen Sie sicher, dass die Entwickler den Richtlinien folgen.
Sie können Bestrafung (Feuer, weniger Verkauf, keine Förderung) implementieren, wenn ein Entwickler nicht.
Tags und Links project-management