it-swarm.com.de

Dateiverwaltung als UX-Team

In einem UX-Team haben wir nach Möglichkeiten gesucht, die Erfahrung unserer eigenen Mitarbeiter bei der Erledigung ihrer Aufgaben zu verbessern, und ich war gespannt, wie andere Teams mit der Dateiverwaltung umgegangen sind.

Während eines großen Projekts mit vielen beteiligten Personen können unsere typischen Projektdateien aus einer Vielzahl von Benutzerforschungsdokumenten, Entwurfsreferenzen und Iterationen, Besprechungsnotizen usw. bestehen. Wenn Sie ein neues Mitglied des Teams zu einem vorhandenen Projekt (oder besser noch zu einem neuen Mitarbeiter) hinzufügen, kann es oftmals überwältigend sein, sich einfach durch Anzeigen des Projektordners auf den neuesten Stand zu bringen.

Hat jemand eine Struktur, ein Werkzeug oder eine Methode gefunden, um Dateien so anzuordnen, dass die Dinge nicht außer Kontrolle geraten? Verwenden Sie insbesondere das Dateiverwaltungssystem eines nativen Betriebssystems und konzentrieren sich auf die Ordnerstruktur und Namenskonventionen oder verfügen Sie über eine Software, die Dateien verständlicher verwaltet usw.?

9
gotohales

Mir scheint, dafür wurde das Web entwickelt. Es kann eine Website erstellt werden, auf der die Assets in jeder gewünschten Organisation dargestellt werden. Links verweisen auf die Asset-Dateien, unabhängig von ihrem Format, möglicherweise neben einer Zusammenfassung oder einigen Metadaten. Wenn das Format der Asset-Datei vom Browser nicht angezeigt werden kann, erleichtert der Browser das Herunterladen. Natürlich wäre es schön, wenn die Assets so weit wie möglich in einem Browser angezeigt würden. Die Asset-Dateien selbst erfordern keine bestimmte Organisation, solange die Webseiten auf ihre Existenz verweisen. Wenn sie verschoben werden müssen, müssen die Webseiten, auf die sie verweisen, aktualisiert werden.

Bei diesem einfachen Modell wird davon ausgegangen, dass die Assets schreibgeschützt sind und kein Auschecken oder Versionsverwaltung erforderlich ist.

Sobald grundlegende Seiten erstellt wurden, können sie als Vorlage dienen. Der HTML-Code sollte so einfach sein, dass ein Nicht-Webentwickler sie verwalten kann (gibt es jemanden im Team, der Aufgaben vom Typ Bibliothekar hat?).

Das Tolle an Webseiten ist, dass jeder bereits weiß, wie man sie benutzt.

Ich habe einmal für ein Unternehmen gearbeitet, bei dem die gesamte interne Dokumentation in HTML geschrieben sein musste (wir verwendeten zuvor MS Word). Programmierer kannten bereits genug HTML, und Tech-Autoren hatten kein Problem damit, es zu lernen. Mit der Zunahme der Dokumentationsdateien wuchs die Organisation von HTML-Seiten organisch um sie herum. Das Ganze war informell, hat aber super funktioniert. Es wäre wahrscheinlich noch besser gewesen, wenn es zu Beginn eine zentrale Planung gegeben hätte.

3
obelia

Sie können sich UXenterprise von HFI ansehen, das speziell für UX-Profis entwickelt wurde und genau dieses Problem behebt und über weitere Funktionen verfügt.

UXenterprise hilft beim Speichern aller Objekte, die Sie normalerweise in einem UX-Prozess verwenden würden. Das Beste daran ist, dass der Prozess sehr iterativ ist und über eine Versionsfunktion verfügt, mit der Sie zu dieser Version zurückkehren und bei Bedarf darauf verweisen können. Mit jedem Projekt können Sie auch Multimedia-Objekte speichern. Beispielsweise können die gesammelten Daten nach einem ersten Stakeholder-Treffen zum Projekt hinzugefügt werden. Habe es einmal benutzt und die Idee geliebt. Es bleibt tatsächlich auch im Einklang mit dem Prozess. Früher haben wir in unserer Organisation ein ähnliches Setup durchgeführt, alles in Freigabeordnern gespeichert und zeitleistenbasierte Namen verwendet. Es war jedoch ein Problem, Ihre Konzepte mit Ihren Kunden zu teilen, aber UXenterprise hat uns auch bei der Lösung dieses Problems geholfen.

1
ajvasudhar
  1. Ein Wiki + ein Datei-Hosting (Dropbox oder etwas für Bilder/Datenspeicherung)
  2. Ein funktionierender High-Fidelity-Prototyp, der alle jüngsten Änderungen enthält und die meisten Dokumente ersetzt (wie in einem ausgezeichneten Buch beschrieben Inspiriert: Wie man Produkte erstellt, die Kunden lieben von Marty Cagan)

Der Hauptpunkt hier ist, dass ein funktionierender Prototyp + ein Wiki für verwandte Informationen ruhig genug ist. Beispielsweise spiegelt Ihr Prototyp (oder bei Bedarf sogar mehrere Versionen davon) den gesamten Wert wider, den Sie während Besprechungen, Benutzerrecherchen oder Entwurfssitzungen, Funktionsspezifikationen usw. gesammelt haben. Andererseits sollte das Wiki alle Referenzinformationen enthalten (wie Benutzerforschungsstatistiken usw.) und die Dinge, die noch nicht im Prototyp enthalten sind (wie offene Fragen, Vorschläge usw.). Und sobald diese Dinge mehr oder weniger klar werden, um zu einem Prototyp hinzugefügt zu werden, sollten Sie sie archivieren (oder sogar löschen).

Nach meiner eigenen Erfahrung sind diese Daten umso weniger nützlich, je mehr Dokumente/Besprechungszusammenfassungen/usw. Sie haben: Etwas ist veraltet, etwas ist in mehreren Versionen dargestellt und Sie können nicht verstehen, welches richtig ist und so weiter. Die Leute werden also nicht nach Informationen suchen, sondern stattdessen ihre Kollegen fragen und sie von den Aufgaben unterbrechen, an denen sie arbeiten.

Sie sollten auch davon ausgehen, dass einige Daten eine vorübergehende oder sogar technische Bedeutung haben (wie sie der Interaktionsdesigner von Wireframes jeden Tag an den visuellen Designer sendet) und sie selbst damit umgehen, wie sie möchten (es ist cool, ein generisches Dokumentenverwaltungssystem im gesamten Unternehmen zu verwenden, aber In Wirklichkeit haben die Menschen in diesen Situationen ihre eigenen bevorzugten Arten der Interkommunikation.

0
alexeypegov