it-swarm.com.de

Sollten zuerst Drahtmodelle oder funktionale Anforderungen erstellt werden?

Wann sollten Sie ein Dokument mit funktionalen Anforderungen für ein Website-Redesign-Projekt erstellen? Gibt es Fälle, in denen ein FRD die Wireframes informieren würde? Ich bin es gewohnt, dass funktionale Anforderungen geschrieben werden, nachdem Drahtmodelle erstellt und genehmigt wurden, aber ich habe kürzlich jemanden das Gegenteil erwähnen lassen.

Ist es für die Wireframes nicht sinnvoll, funktionale Anforderungen zu informieren, anstatt umgekehrt?

21
Sree Bhandaram

Begriffe wie "Dokument mit funktionalen Anforderungen" sind notorisch mehrdeutig und werden häufig missverstanden, insbesondere wenn Dokumente zwischen Design- und Entwicklungsteams weitergegeben werden. Daher ist es häufig am besten, den Zweck und den Umfang des von Ihnen erstellten Dokuments zu definieren

  • Bevor Sie beginnen, müssen Sie sich auf Inhalt und Format einigen
  • Im Dokument selbst, um Fehlinterpretationen und tangentiales Feedback zu vermeiden

Für wen ist es? Was wird dokumentiert?

Die Mehrdeutigkeit ergibt sich aus dem Begriff "Anforderungen" - im Grunde genommen, ob die zu dokumentierenden Anforderungen sind

  1. geschäftsbeschränkungen für das Verhalten einer gültigen Lösung des Entwurfsproblems
  2. einschränkungen bei der Implementierung einer bestimmten Entwurfslösung

Im ersten Fall müssen die Anforderungen dokumentiert werden, bevor eine Entwurfslösung versucht wird, und müssen daher vor dem Abschluss von Drahtgittern abgeschlossen werden.

Im zweiten Fall kann die FRD erst gestartet werden, wenn eine Entwurfslösung dokumentiert werden muss. Daher kann sie erst gestartet werden, wenn der Schnittstellendesign stabil ist, d. H. Spät im Wireframing-Prozess.

Die erste Art von Dokument schränkt das Design ein .

Die zweite Art von Dokument beschränkt die Implementierung des Entwurfs als Code .

Content Management-Anforderungen

Dies ist eine weitere Unklarheit, auf die Sie achten müssen.

Für viele Webentwickler sollte ein Dokument mit funktionalen Anforderungen alle Geschäftsregeln enthalten, die als Teil der Anwendung implementiert werden müssen. Dies kann z.B. Content-Management-Prozesse und Governance, die die meisten UXer normalerweise nicht als etwas betrachten, das sie als Teil ihrer Wireframes angeben müssen.

gemeinsames Verständnis

Wenn Sie diese Unklarheiten berücksichtigen und mit Ihren Stakeholdern und Entwicklern zusammenarbeiten, um ein gemeinsames Verständnis darüber zu erzielen, welche Dokumentation erforderlich ist, sind Sie in einer guten Position, um zu vermeiden, dass Sie viel unnötiges und nicht hilfreiches (und nervenaufreibendes) tun ) Dokumentation.

10
Justin

Meine Lieblingsillustration über Designprozesse ist die folgende:

A well-known illustration of the RUP process

Es ist nicht einmal wichtig, woher es kommt, es ist das längst vergessene Software-Design im alten Stil (wenn es kein separates UX- und technisches Design gab, gab es Software-Engineering und Engineering-Prozesse), aber es enthält immer noch den Schlüssel .

Wie Sie sehen, beginnen alle ungefähr am Anfang, aber ihre Intensität ändert sich. Dies sind ungefähr 2-4 Wochen Iterationen.

Es gibt kein erstes oder letztes : Wir könnten sagen: zuerst gestartet oder zuerst beendet.

Persönlich würde ich denken, dass Sie mit der Funktionalität beginnen sollten, da sie definiert, wofür das System verwendet wird.

Andererseits sprechen Benutzer die Benutzersprache, dh die Benutzeroberfläche. Sie können es nur in einer vertrauten Umgebung erklären, und das ist normalerweise eine grafische Benutzeroberfläche. In Bezug auf Änderungsanforderungen erfolgt dies immer entweder als Änderung der Benutzeroberfläche oder basierend auf einem seltsamen Modell der mentalen Implementierung, dem Benutzermodell der vom System wahrgenommenen Implementierung.

In jedem Fall geht es darum, an den Bedürfnissen festzuhalten, nicht an den Schaltflächen : Ihre Benutzer benötigen keine weitere Schaltfläche (auch wenn sie das sagen). Sie haben ein neues Problem, das sie mit dem Knopf lösen wollen. Stellen Sie sicher, dass Sie diese Informationen so früh wie möglich aufzeichnen.

Da Tasten kommen und gehen, bleiben die Probleme gleich. Bei Anwendungen geht es um Probleme. Es geht darum, wie nicht computerbezogene Bedürfnisse gelöst werden können, um nicht computerbezogene Ziele zu erreichen.

Ihre Spezifikation sollte eine klare systematische Aufzeichnung des Systems dieser Bedürfnisse sein, genau wie Linné versucht hat, das System der Lebewesen zu beschreiben : Ihre zu beschreibende Welt ist eine Welt voller Bedürfnisse und Bedürfnisse fährt.

Eine elegante Lösung ist diejenige, die zu ihrem Gegenstück passt, das Problem effektiv, die einfachste und doch genialste Art und Weise. Eleganz ist Minimalismus in der Schönheit.

Designer sollten nach Eleganz streben, insbesondere wenn es um Anwendungen geht, die die Bedürfnisse der Benutzer erfüllen sollen. Alles, was sich nicht mit dem Problem befasst, trägt nur zum Problem bei.

Die Benutzeroberfläche ist das System für Ihre Benutzer. Es ist die Metapher des Systems.

Wie können Sie erwarten, ein elegantes Lösungssystem für das Problem zu entwerfen, wenn Sie nicht zuerst eine klare Beschreibung des Problems haben?

Tun Sie alles, was Sie brauchen, um das Problem zu verstehen (wenn Sie Benutzeroberflächenmodelle benötigen, um Benutzern zu helfen kommunizieren über diese Anforderungen, verwenden Sie sie, wenn es mit Diagrammen oder Text besser ist, verwenden Sie sie), und tun Sie alles Sie brauchen eine Lösung für dieses Problem, die nichts anderes lösen will.

Aus diesem Grund denke ich, dass ein Schlüsselartefakt ein Anforderungsdokument ist, das die Lösung nicht detailliert beschreibt, auf das sich das tatsächliche Design des Lösungssystems (das normalerweise in UI-Begriffen angegeben wird) stützt. Wenn Sie zuerst vollständige Drahtgitter entwerfen, hängen diese in der Luft.

Aber das ist natürlich ein Henne-oder-Ei-Problem. Stellen Sie sicher, dass Sie beide gleichzeitig in Ihrem Garten haben.

12
Aadaam

Das Team, mit dem ich zusammenarbeite, hat eine Person, die sowohl für die Geschäftsanalyse als auch für das Design zuständig ist (die zufällig ich bin). Ich variiere zwischen dem Beginn mit Anforderungen und dem Beginn mit groben Modellen/Drahtgittern, hauptsächlich abhängig von einigen Faktoren:

  • Komplexität der Aufgabe: Wenn es etwas Einfaches ist, springe ich wahrscheinlich einfach zu einem Drahtmodell
  • Persönliche oder Entfernungsüberprüfung: Wenn ich an geografisch getrennte Personen verteilen möchte, beginne ich mit schriftlichen Anforderungen und wechsle dann zu einem Drahtmodell
  • Technisch v. Nicht technisch: Wenn die Anfrage etwas Technisches/Komplexes ist, beginne ich mit schriftlichen Anforderungen

Das Schöne an den schriftlichen Anforderungen ist, dass sie verwendet werden können, um die Mehrdeutigkeit zu verhindern, die einem Modell innewohnt. Wenn Benutzer jedoch sehen, wie ihre Anfrage tatsächlich aussehen wird, stellen sie häufig höhere Anforderungen.

Und manchmal beginne ich einfach mit einem Modell, weil ich ein visueller Typ bin, und es hilft mir, genau herauszufinden, wie die Anforderungen geschrieben/kommuniziert werden sollten. Meine super-rauen Balsamiq-Modelle helfen oft dabei, die Anforderungen zu informieren. Mit diesem Ansatz bin ich definitiv bereit, meine Entwürfe zu werfen und von vorne zu beginnen, sobald die Anforderungen finalisiert/mehr finalisiert wurden.

4
Ray V

Wenn Sie zuerst ein Drahtmodell erstellen, definieren Sie eine Lösung, bevor Sie wissen, was Sie lösen möchten. Sie müssen das Problem definieren, bevor Sie wissen, wie Sie die Lösung entwerfen. Daher geben die Anforderungen an, was ein Produkt benötigt, nicht die Lösung.

Sind Ihre Wireframes auch buchstäblich Ideen für Diskussionen oder streben Sie nach voll funktionsfähigen Spezifikationen?

Ich bin eine UX-Person, aber eher eine Mischung aus UX- und Business-Analyse, und es macht mir Spaß, wenn Wireframes zuerst erstellt werden. Ich glaube, dass UX-Leute wissen sollten, wie die Dinge auf der Website aussehen, wie sie inhaltlich verwaltet werden usw.

Jedes Mal, wenn ich an designorientierten Projekten arbeite, stoßen wir auf massive Probleme. Und das liegt hauptsächlich daran, dass keine Anforderungen vorliegen. Designer denken oft, dass Drahtgitter immer der Beginn eines Projekts sind. Sie haben oft festgestellt, dass Anforderungen die Kreativität zerstören. Ich denke, das ist so falsch und führt in späteren Phasen des Projekts zur totalen Hölle im gesamten Team.

Erstens muss jedes einzelne Projekt anders angegangen werden. Keine zwei Projekte sind gleich, daher sollte entsprechend vorgegangen werden. Ich sage immer, bevor Drahtgitter überhaupt erwähnt werden, müssen wir zuerst Folgendes verstehen und dann ausgleichen:

  • kennen Ihre Benutzer (Benutzerforschung)
  • kennen Ihre Inhalte (Audits & Modellierung, Fachexperteninterviews)
  • kennen Ihren redaktionellen Prozess (Workflows & Governance)
  • kennen Ihr Geschäft (Geschäftsmodell)
  • kennen Ihre Systeme (CMS & kontrolliertes Vokabularmanagement & Governance)

Die Anforderungen sind in funktionale und nicht funktionale unterteilt. Es ist wichtig, die funktionalen Anforderungen frühzeitig aufzulisten. Die Art und Weise, wie sie geschrieben sind, sollte für alle technischen und nichttechnischen Personen einfach sein.

Diese Anforderungen stammen aus einer Kombination von Quellen:

  • geschäftsbedürfnisse und -wünsche
  • benutzerbedürfnisse und -wünsche, die aus verschiedenen Benutzerforschungsmethoden stammen können
  • redaktionelle Anforderungen (wenn es sich um ein End-to-End-Projekt handelt)
4
AKF

Ich arbeite in einem Beratungsunternehmen, und unsere Kunden reichen von Supertechnologie und verstehen Design und können über Serverkonfigurationen sprechen, bis sie eines über Technologie oder Design nicht verstehen. Ich habe den Prozess bei meinem derzeitigen Arbeitgeber irgendwie umgestellt.

Ich habe festgestellt, dass ein paar Besprechungen, um Design-/Funktionsanforderungen zu ermitteln, eine großartige Möglichkeit sind, Elemente und Funktionen festzulegen, die der Kunde unbedingt auf einer Seite haben muss. Ich lasse mich jedoch nicht von diesen Besprechungen davon abhalten, dem Kunden nur einige schnelle und schmutzige Skizzen/Prototypen zu zeigen, um die Abläufe und Interaktionen zu verstehen. Mit diesen Entwurfsanforderungsbesprechungen erstelle ich ein UX/Designanforderungsdokument. Es ist eine Tabelle in unserem Wiki, in der der Abschnitt/Inhaltstyp und alle auf dieser Seite erforderlichen Elemente zusammen mit sehr allgemeinen Hinweisen zu dieser Anforderung aufgeführt sind. Sobald dies genehmigt ist, gehe ich zum Wireframing oder Prototyping über. Als Prototyp oder Drahtmodell wird an der Funktionsdokumentation für die Entwickler gearbeitet.

Ich denke, dass eine funktionale Dokumentation die Entwurfsentscheidungen beeinflusst, bevor man überhaupt sieht, wie diese Interaktion funktioniert und sich anfühlt, wirklich eine Katastrophe ist, die darauf wartet, passiert zu werden, und nur zu viel mehr Iterationen als normal führt.

2
dsawler

Ich glaube, die Anforderungen sollten vor den Drahtgittern geschrieben werden, und so habe ich es meistens während meiner Karriere gesehen. Die Anforderungen kommen vom Kunden oder Produktmanager, und es ist Sache des UX-Teams, diese Anforderungen in Drahtmodelle zu übersetzen, die die gesamte Erfahrung liefern und die Benutzeroberfläche, Entwickler usw. anleiten.

1
user17508

Es hängt alles vom Projekt ab. Wer daran arbeitet, Geschäftsanforderungen zu erfassen und Benutzer- und Wettbewerbsforschung zu betreiben, benötigt ein gewisses Maß an Verständnis, bevor ein Vision erscheint und die Magie beginnt.

Ich werde einen anderen Ansatz anbieten, den ich nicht besonders bevorzuge, aber im Moment nichts ausmacht. Ich arbeite mit einem Kollegen an einem Projekt, bei dem der Kunde auf einer Kombination aus kommentierten Drahtgittern und interaktiven Prototypen besteht, ohne die Anforderungen zu kennen. Sie verwenden die Drahtgitter für eine schnelle interne Überprüfung und die Prototypen für noch schnellere Tests und verwenden dann die Daten, um auf früheren Arbeiten aufzubauen. Dieser Prozess wird nicht von den Benutzeranforderungen und Geschäftsanforderungen bestimmt, da diese beide im Verlauf generiert werden.

In diesem Projekt wird die FRD zum letztmöglichen Zeitpunkt für die Entwickler nur mit allen zusätzlichen Drahtmodellen und interaktiven Prototypen geschrieben, die als Referenz verfügbar sind. Ich würde diese Methode nicht empfehlen, aber der Kunde arbeitet gerne für bestimmte Aspekte seines Geschäfts auf diese Weise und es scheint für ihn zu funktionieren. Man könnte sagen, sie denken gerne über den Tellerrand hinaus.

Funktionale Anforderungen kommen vor Drahtgittern.
Vor FRs gibt es Geschäftsanforderungen, die die Ereigniskette starten.
Geschäftsanforderungen kommunizieren einen Bedarf, etwas, das ein Stakeholder gerne tun würde.
Funktionale Anforderungen kommunizieren, wie Dinge funktionieren sollen, nachdem die neue Funktionalität implementiert wurde.

Eine Geschäftsanforderung könnte wie folgt lauten: Benutzern erlauben, sich mit ihrer Identität auf anderen Websites wie Google, FB oder Twitter anzumelden . Dies kann aus einem Wettbewerbsvergleich resultieren.

Die Drahtmodelle für die Implementierung solcher Funktionen könnten ziemlich offensichtlich sein und von einer anderen Site kopiert werden, die OAuth implementiert. Aber die Funktionalität ist nicht so offensichtlich.

So ist es möglich, den Stakeholdern nach ein wenig Ausschneiden und Einfügen Screenshots zu zeigen und sich abmelden zu lassen.

Die Realität der Auswirkungen einer solchen Implementierung an diesem bestimmten Standort ist jedoch erst bekannt, nachdem jemand, der als Funktionsanalyst fungiert, dies verstanden hat. Wie zum Beispiel kann dies tiefgreifende Auswirkungen auf alle Backoffice-Interaktionen und die Datenbankstruktur der Benutzer haben und überall umfangreiche Änderungen und einen Migrationsplan erfordern.

Diese technische Komplexität spiegelt sich in höheren Entwicklungskosten wider.
Nachdem wir dem Manager ein vereinfachtes OAuth Login-Drahtmodell) gezeigt haben, wie können wir sie einige Tage später ansprechen und um ein riesiges Budget bitten? Nachdem sie ihr die Bildschirme gezeigt hat mittlerer VP?

Deshalb stehen funktionale Anforderungen an erster Stelle.

Natürlich können Sie ihr die Mischlings-Screenshots zeigen und ihr sagen, dass sie den Atem anhalten soll, während die Hausaufgaben erledigt sind, aber dies hängt von der Formalitätsstufe ab. Wenn es sich um ein Unternehmen mit 12 Mitarbeitern handelt, sind die Dinge anders als bei einem Fortune-500-Unternehmen.

Die Kunst, funktionale Anforderungen zu erfüllen, beinhaltet jedoch viel zu vermeiden, die Benutzeroberfläche zu erwähnen. Es ist schlecht zu schreiben "Setze eine Schaltfläche für den Benutzer zur Auswahl", der FR sollte nur angeben, dass der Benutzer wählen dürfen muss.

Die großen Vorteile, die Benutzeroberfläche von den FRs fernzuhalten, sind seit vielen Jahren bekannt (möglicherweise in den siebziger Jahren, glaube ich) und werden in Larry Constantine Befunden ausgedrückt.

Eine wichtige Erkenntnis von ihnen (Larry & Lucy) war, dass je früher mit dem Zeichnen von Boxen in einer Programmier-IDE begonnen wurde, desto mehr Zeit würde die Anwendung benötigen, um ein akzeptables Usability-Niveau zu erreichen.

Funktionsanforderungen sehen häufig aus wie lange Listen mit kurzen Sätzen, die alle mit beginnen. Das System soll ... . Dies sind keine FRs, mit etwas Glück können sie als Geschäftsanforderungen angesehen werden (, was zu tun ist, nicht wie um es zu tun).
Der beste Weg, um funktionale Anforderungen auszudrücken, sind Anwendungsfälle.
Aber runzeln Sie nicht so schnell die Stirn. Dies sind nicht die UCs Ihres Vaters und definitiv nicht die UCs von RUP.

Ich bin erreichen Wenn Sie die Länge einer vernünftigen Antwort überschreiten, ist es ideal, informelle, leichte UCs zu schreiben, um die funktionalen Anforderungen zu erfassen.
Zwei Hauptgründe:

  1. Sie sind das Scharnier zwischen den Benutzern und der IT-Mitarbeiterwelt
  2. Wenn sie gut geschrieben sind, machen die UCs das Codieren schneller und sicherer und damit viel billiger.
1
Juan Lanus

Wasserfall = Anforderungen stehen an erster Stelle. Agil = sie werden parallel entwickelt.

0
DA01

Für die Entwicklung von Web-Apps empfehle ich, mehrere Dokumente zu erstellen, die Sie während des Wachstums parallel aktualisieren/verwalten:

  1. 1-5 Seiten Zusammenfassung über die App, was ist die Story
  2. definieren Sie alle möglichen Benutzerrollen - und hören Sie danach auf, auf den Benutzer zu verweisen. Es ist registriert, Pro-Benutzer, Administrator-Benutzer, Eigentümer, Betrachter usw.
  3. definieren Sie alle möglichen Seitenaufrufe, die Sie sich vorstellen können. Login, Home, Benachrichtigungseinstellungen - ohne Hierarchie einzurichten
  4. listen Sie alle möglichen Aktionen auf, die jede Rolle ausführen kann, unabhängig davon, auf welcher Seite. Anmelden, wie, kommentieren, eigenen Kommentar löschen, etc.
  5. jede App hat etwas Einzigartiges, z. Auktion, Abstimmung, Bestellvorgang usw. Zeichnen Sie in diesen Fällen ein Flussdiagramm, um alle möglichen Ergebnisse abzudecken. Für fortgeschrittene Benutzer ist das Swimlane-Flussdiagramm sehr hilfreich.

Wenn Sie die obigen Schritte ausführen, werden Sie ein neues Element entdecken. Verbessern Sie Ihre Story und die Schritte 1 bis 5, bis Sie sich bereit fühlen, mit dem Wireframing zu beginnen. Technische Anforderungen können als Notizen direkt in Drahtgitter eingefügt werden.

Ein weiteres langweiliges Dokument, das ich pflegen möchte, ist die Liste der Variablen für jede Seite. Feldname, Typ, Dropdown-Optionen, erforderliches Feld, Validierung, Standardwert usw. - Verwenden Sie für fortgeschrittene Benutzer das Datenbankdiagramm.

Mit dieser Methode können Sie in kürzester Zeit Drahtgitter ohne konstanten Block erstellen.

0
LKB

Viele gute Gedanken hier zu einem Thema, das ich gerade mit einem Kunden kläre.

Wie ich sehe, sind die beiden (Wireframes/Prototypen und FRD) so eng miteinander verflochten, dass es keine Rolle spielt, dass "Es gibt keinen Ersten vom Letzten". Wichtiger ist, dass keiner abgeschlossen (abgemeldet) wird, bis der andere in einem vergleichbaren Vertrag ist Zustand.

Wenn ein FRD die Geschäftsregeln, Datenanforderungen (Quellen) und Funktionen, die das Unternehmen dem Benutzer zur Verfügung stellen möchte, detailliert beschreiben soll, muss sich das Unternehmen verpflichten oder bestätigen, dass diese Daten beim Entwerfen der Schnittstelle und der Folgenabschätzung verfügbar sind Diese Daten/Funktionen sind durch zu liefern. Ohne diese Bestätigung ist die Existenz von Daten meiner Erfahrung nach manchmal fraglich, da die zugrunde liegenden Grundlagen nicht immer so solide sind, wie erhofft.

Die Geschäftsregeln, Datenanforderungen und Funktionen sind zu diesem Zeitpunkt alle Designherausforderungen. Fast niemand, der das Unternehmen vertritt, wird die Details oder das Fehlen einer FRD vollständig zu schätzen wissen.

Als Designer besteht unsere Aufgabe darin, die FRD (eine Entwurfsaufgabe, wenn Sie möchten) zu etwas Sinnvollem zusammenzuführen - dh vorzeigbar und verständlich -, das die Konzepte und Anforderungen innerhalb des Dokuments beantwortet und vor allem in Frage stellt. An diesem Punkt haben wir uns an "Bedürfnisse nicht Schaltflächen" gehalten, vertraute Methoden zur Navigation allgemeiner Informationen werden zusammen mit genügend Details angewendet, um sicherzustellen, dass die Komplexität oder dieses spezielle Geschäft auf verständliche Weise verfügbar gemacht wird, die auf soliden Grundlagen aufbauen.

Ohne diese soliden Grundlagen kann ein Großteil des durch Forschung, Design und Prototyping gewonnenen Verständnisses sofort ungültig werden. In seltenen Fällen kann dies durch Hinzufügen oder Entfernen von Schaltflächen oder Funktionen behoben werden, da jedes Element häufig darauf angewiesen ist, dass andere für den Kontext vorhanden sind, der das Metallmodell eines Benutzers darüber informiert und bestätigt, auf was er navigiert oder Zugriff erhält.

Wiederum, wie Aadaam bemerkt "Es gibt kein erstes oder letztes", sind sie eins in der gleichen Sache.

0
Adam Fellowes

Sie könnten bis zu einem gewissen Grad.

Aber Sie werden feststellen, dass Sie auf dem arbeiten, was vorher gedacht wurde. Dies kann zu einer nicht unterstützten Funktionalität bei einer mangelhaften Site-Struktur und einem mangelhaften Layout führen, die nicht mit den wachsenden Ideen fertig werden.

Erstellen Sie besser eine Funktionsspezifikation, die nicht über wichtige Interaktionen, Sitemap und Navigation hinausgeht. Und dann müssen Sie sie wiederholen und aktualisieren.

0
user16811