it-swarm-eu.dev

I wireframe sono appropriati per la documentazione dei requisiti?

Le persone che progettano, sviluppano e testano al momento stanno discutendo dei requisiti.

Parte della conversazione riguarda lo scopo e l'uso dei wireframe. Il nostro analista del cambiamento è fortemente contrario all'utilizzo di wireframe come parte dei requisiti per lo sviluppo o il testing. Devono essere utilizzati per "ulteriori informazioni" solo quando necessario - "qualcosa a cui fare riferimento" per chiarezza.

In breve: usare requisiti scritti, non visivi.

I wireframe dovrebbero essere usati come parte del processo di raccolta e documentazione dei requisiti?

Qualcuno di voi ha mai lavorato in un team in cui i wireframe sono stati i principali documenti richiesti per lo sviluppo e/o i test?

Modifica: ho una propensione a usare i wireframe come documentazione sui requisiti formali. Ho trascorso un paio d'anni in un ambiente in cui erano la unica forma di requisiti documentali - lo sviluppo non è iniziato fino a quando i proprietari del prodotto (impostazione Agile) hanno firmato sui wireframe. Molto efficiente in quel contesto.

13
gef05

Penso che qui rischi i rischi rispetto al dibattito sul design. I wireframe sono piuttosto importanti ma penso che dipenda da come li concettualizzi. Quella che segue è la mia opinione, ma supportata da processi industriali piuttosto standard nella mia esperienza.

  • I requisiti dovrebbero generalmente essere scritti solo perché stai descrivendo cosa deve fare una soluzione. Dovrebbero essere sufficientemente dettagliati per descrivere chiaramente tutti i passaggi che devono accadere e dovrebbero essere suddivisi in secchi logici, a seconda del tipo di prodotto per cui sono destinati.
  • I wireframe fanno parte del processo di progettazione perché descrivono come la soluzione deve comportarsi per soddisfare i requisiti. A volte potrebbe essere necessario sviluppare una mappa mentale o un diagramma di nodo o disegnare qualcosa per convincere un cliente a descrivere più chiaramente i propri requisiti, ma non è questo lo scopo di un wireframe.
  • Nei progetti in cui qualcuno ha elaborato il modo in cui un'applicazione dovrebbe fluire e/o ha creato wireframe (che essenzialmente iniziano a posizionare elementi su un'interfaccia utente) direttamente in anticipo, distorce invariabilmente il processo di progettazione e IMHO di solito finisce per essere sostanzialmente modificata o eliminata del tutto.

I requisiti sono generalmente (non sempre ovviamente) scritti da un analista aziendale o PM e non da un progettista centrato sull'utente. A volte questi ruoli si sovrappongono e le persone possono fare entrambe le cose bene, ma dove sono i ruoli i wireframe differenziati come parte dei requisiti di solito non funzionano nella mia esperienza. Per necessità, vengono in seguito, quando il cliente ha firmato ciò che il prodotto deve fare, non come dovrebbe farlo.

12
jameswanless

Uso Storyboard in PowerPoint in fedeltà semi-alta. Trovo che la documentazione scritta abbia grossi difetti.

  1. Le persone non possono reagire emotivamente all'interattività immaginandolo dal testo. Non puoi scrivere un paragrafo su come qualcosa funzionerà e far capire alle persone la sfumatura del progetto di interazione. È come scrivere "Il design grafico sarà bello usando un sacco di viola". Cosa significa? Come puoi definirlo senza mostrarlo?

  2. La lingua fa schifo . Ho un minor numero di argomenti di persona rispetto all'e-mail. L'e-mail (comunicazione testuale) ha troppe possibilità di interpretazione errata. Quando state insieme e guardate qualcosa di visivo, le cose diventano più fluide. Inoltre, molti ingegneri che conosco non sono l'inglese come madrelingua. Il testo è molto spesso interpretato male.

  3. Non puoi testare il testo . Puoi testare uno storyboard e metterlo di fronte alle persone per ottenere reazioni. Il testo non funziona in questo modo.

CAVEAT: tutte le aziende hanno stranezze e circostanze speciali. Devi trovare ciò che funziona per te. Non lasciare che le persone ti dicano qualcosa che sai che è sbagliato. Se devi, fai entrambe le cose e dai segretamente gli storyboard agli ingegneri.

6
Glen Lipka

La mia frustrazione come BA è la mancanza di chiarezza tra "Requisiti" che sono unità testabili e "Progettazione" che, quando creati come parte dei requisiti, DIVENTANO effettivamente requisiti. Quando l'azienda firma su un wireframe low-fi o high-fi, ha reso quella visualizzazione il suo requisito. Ora sto scrivendo script di test per assicurarmi che il wireframe si stia generando esattamente come mostrato in figura. Parliamo di granularità !! I requisiti dovrebbero riguardare la FUNZIONE dell'applicazione, non la progettazione visiva a meno che la progettazione non abbia una necessità commerciale legittima da coprire, come ADA, standard di marketing o miglioramenti della produttività identificati.

Il più delle volte, le aziende e gli sviluppatori fanno affidamento sull'aspetto perché non possono concettualizzare il loro prodotto finale senza di esso. È la differenza tra leggere un libro e guardare il video di questi requisiti. È una pendenza scivolosa di sposarsi con un design e l'azienda inizia a dettare "come" quel design dovrebbe funzionare (pulsanti di salvataggio, messaggistica di errore, raccolta dati, navigazione, ecc.) Per quanto gli sviluppatori non dovrebbero dettare UX, né dovrebbero il business, a meno che non siano nel business di UX e design e quindi mi chiedo perché non stiano scrivendo codice da soli.

Il grande gemito è spesso raccogliere e documentare i requisiti più velocemente in modo da poter iniziare lo sviluppo, il che pone la domanda sul perché scriverli? Se gli sviluppatori non sono in grado di leggere i requisiti e iniziare a strutturare lo sviluppo senza progettazione, è probabile che non si preoccupino di rielaborare i dati e che la modifica della progettazione sia molto più scomoda da modificare. Essere agnostici alla raccolta dei requisiti significa opportunità aperte per la progettazione agnostica - progettazione non legata a una piattaforma e ai suoi vincoli. Creando il processo di firma su wireframe, stai configurando il business per accettare ciò che sei disposto a dare loro invece di dare loro ciò di cui hanno bisogno. Quindi il processo finisce sulle belle immagini e non sulla funzione dell'applicazione.

Sicuramente ... Penso che sia essenziale per il tuo team UI avere un wireframe per vedere tutte le diverse interazioni che devi visualizzare sul progetto.

Alcune persone dicono che dovrebbe essere sufficiente avere una descrizione scritta del progetto, ma a volte non è possibile ottenere l'intero quadro di un progetto con solo parole.

Specialmente con i wireframe dinamici, per i designer è più facile, ad esempio, avere un'idea di cosa dovrebbe fare un menu.

È anche bello lavorare con i clienti, poiché hanno un quadro chiaro di ciò che il tuo team intende programmare per il loro progetto.

Questo ti farà risparmiare un sacco di tempo dal punto di vista della programmazione e le interazioni dell'interfaccia utente per me un buon wireframe è la rappresentazione grafica di un buon documento scritto.

Non ho dubbi sul valore di un wireframe valido, dettagliato e interattivo.

1

I wireframe non sono la documentazione dei requisiti. I documenti dei requisiti non sono wireframe. Entrambi dipendono e si influenzano a vicenda, tuttavia.

Trovo che lavorano meglio insieme in parallelo. In altre parole, entrambi si evolvono insieme (al contrario di uno finito prima dell'inizio dell'altro).

Dici che usi i wireframe come requisiti in un ambiente agile. Penso che sia probabilmente l'eccezione. Idealmente, tutto sarebbe fatto in un ambiente agile.

In quello scenario, i wireframe sono in realtà schizzi di tovaglioli. Sono un documento interno per comunicare un'idea in modo che possa essere immediatamente costruita.

La cosa grandiosa di Agile è che (IMHO), se fatto bene, riduce notevolmente la necessità di documentazione in generale e, in un certo senso, rende questa domanda particolare meno rilevante.

1
DA01

Ho trovato le idee trovate nel libro "Prototyping: A Practitioners Guide" per essere un buon esempio di come a volte un MRD scritto non sia così utile come una volta, basato sull'idea che a volte mostrando, è meglio che raccontare. Concesso che le specifiche dei libri riguardano la prototipazione, penso che le stesse idee possano passare anche al wireframing.

  • La prototipazione è generativa: il significato, mentre attraversi il processo di prototipazione (o wireframing), stai attraversando centinaia di idee. Alcuni brillanti, altri meno brillanti. Ma le idee meno brillanti possono essere un catalizzatore di soluzioni brillanti.
  • Il prototipo comunica attraverso show and tell.
  • Il prototipo riduce l'interpretazione errata. Prendi un documento di requisiti di 60 pagine. Porta 15 persone in una stanza. Distribuiscilo. Lascia che tutti lo leggano. Ora chiedi loro cosa stai costruendo. Riceverai 15 risposte diverse. Ora immagina di provare la stessa cosa con un MRD da 200 pagine - peggiora ancora ...
  • Il prototipo crea un rapido ciclo di feedback, che alla fine consente di risparmiare tempo, fatica, denaro e riduce i rischi.

Con tutto questo in mente, l'argomento contro questo sarebbe, a volte la prototipazione/wireframing può anche essere eccessiva per alcuni progetti, quindi davvero, tutto dipende molto dal progetto.

1
Armando

Assolutamente no - i wireframe non appartengono ai requisiti.

I wireframe sono un ottimo modo per:

  • Generare requisiti
  • Progettare soluzioni ai requisiti

Ma inserirli nei requisiti è un incubo, che porterà a pensiero e documentazione confusi e confusi (spesso confondendo forma e funzione).

Questo è particolarmente un problema in ambienti o contratti regolamentati - guarda in questo modo, se l'interfaccia utente cambia un elenco a discesa in una vista elenco:

  1. Il requisito non è più soddisfatto ed è per impostazione predefinita un fallimento normativo o contrattuale. Il prodotto funziona ancora bene ma i documenti sono ora una responsabilità legale.
  2. La documentazione deve essere rifatta ogni volta che cambia l'interfaccia utente - questo è folle.
  3. Prima ho lavorato per un'azienda abbastanza folle non solo per inserire i wireframe nei requisiti ma anche nei test corrispondenti! Quella follia significava che quando l'interfaccia utente veniva revisionata con nuovi design e toolkit, tutta la documentazione doveva essere rifatta (che non avevano tenuto conto delle stime dei loro progetti).

Suppongo che intendi solo wireframe dell'interfaccia utente. Diagrammi a blocchi, diagrammi di flusso, ecc. Sono essenziali.

0
Mr Blah

Il prodotto finale che stai costruendo è un'applicazione web.

I wireframe possono arrivare a metà strada con poco sforzo, quindi ha senso utilizzare i wireframe come requisiti purché contengano un'adeguata granularità tra i passaggi.

In caso contrario, ho scoperto che i wireframe mal eseguiti possono essere interpretati erroneamente quasi quanto i requisiti scritti.

Tuttavia, i requisiti scritti sono ancora essenziali per documentare tutti i flussi. Senza di essi, diventa difficile eseguire test strutturati di accettazione dell'utente e test di qualità.

0
Jung Lee

Qui è dove credo che i tuoi requisiti possano diventare pieni di risorse: diagrammi a blocchi e diagramma di flusso.

http://www.leacock.com/deliverables/block_diagram_ex2.pdf

Qui, spiega il processo in un diagramma di flusso, che è ancora una volta meglio della semplice documentazione. L'uso di Wireframe richiede tempo, budget per aggirare, ma l'utilizzo di diagrammi a blocchi e diagrammi di flusso è più significativo e aiuta altri sviluppatori e membri del team a impegnarsi con la documentazione.

Per lo più alle persone non piace guardare le informazioni testuali che secondo la mia esperienza non attirano nessuno a guardarle per più di 10 minuti. Abbiamo realizzato un progetto rivolto al cliente, in cui ha tratto grande vantaggio dalla visualizzazione di wireframe parallelamente ai dati testuali. Le persone hanno iniziato a capire in cosa stiamo cercando di documentare. Ma ci vuole molto sforzo. Quindi il modo ideale per mantenere intatte le risorse è utilizzare diagrammi di flusso e diagrammi a blocchi per renderlo interessante.

0
inkmarble