Wireframing sta effettuando una overplanning?

Question

37 Getting Real di Signal mi ha convinto che il wireframing e la scrittura di documenti di specifiche funzionali sono passaggi intermedi non necessari per la creazione di applicazioni Web e siti Web dinamici.

Il sovraccarico di questi passaggi vale il suo peso? La prototipazione in documenti HTML / CSS o PhotoShop (in modo che i progettisti possano lavorarci direttamente) è un'opzione migliore rispetto all'utilizzo di software come Visio? Personalmente, sto ondeggiando verso quest'ultimo, ma non sono sicuro.

Answer 1

" Impossibile pianificare si prevede di fallire " - o qualcosa del genere.

Wireframing non si limita alle app Web; è utilizzato pervasivamente ovunque sia necessaria una panoramica di alto livello di qualsiasi sistema (si chiama semplicemente qualcos'altro).

Specifiche funzionali, quando sai cosa devi fare & amp; come farlo sarebbe davvero eccessivo. Un diagramma di alto livello delle tue intenzioni sarebbe sufficiente. E non sarà mai superfluo . Ti aiuta principalmente a concentrarti sull'ambito e l'intento / l'obiettivo di ciò che vuoi fare.

Il focus dovrebbe essere sulla prevenzione di sforzi sprecati: scoprire a metà strada che manca qualcosa di essenziale, che ha un impatto su tutti gli altri oggetti, non è ciò che si desidera scoprire. Il wireframing in questo caso aiuterebbe a rilevare le principali esigenze funzionali. Dovresti solo elaborare specifiche funzionali dove assolutamente necessario. Usare Photoshop per progettare il tuo sarà anche uno sforzo sprecato " - molto meglio usare la prototipazione evolutiva (tecnica RAD) con CSS / HTML - ma ancora pen & amp; mock-up cartaceo delle tue intenzioni.

Answer 2

37Signals sostiene di saltare anche Photoshop e passare direttamente all'HTML. Vedi http://www.37signals.com/svn/posts / 1061-perché-ci-saltare-photoshop . Concordo con la loro valutazione della pre-pianificazione. Non credo che valga la pena, nel lungo periodo, di poter passare il tempo a costruire un prototipo funzionante in HTML / CSS / JS.

Answer 3

Nella vita reale vuoi evitare di cercare "l'ideale" modo di fare le cose. Usa invece quello che hai capito per scopi chiari e specifici.

I modelli possono farti risparmiare un sacco di tempo e fatica. Dato che possono essere solo del tempo extra che hai speso per crearli e mantenerli.

Esempio di vita reale n. 1: i modelli hanno salvato la giornata. Grande sistema per il governo, la scadenza è ridicola.

Motivo: sono trascorsi mesi nella produzione di tutti i tipi di documenti di architettura che sono in realtà del tutto superflui perché sia ??l'architettura HW che quella SW sono fissate in pietra nei minimi dettagli e in realtà esistono già.

Soluzione: 20 giorni frenetici di creazione di modelli insieme al cliente, fino a quando non abbiamo semplicemente consegnato gli schermi con le nostre note agli sviluppatori. Gli sviluppatori hanno dovuto chiedere alcuni chiarimenti, ma con un'architettura fissa e requisiti chiari e visualizzati sono stati in grado di avviare tonnellate di funzionalità richieste in pochissimo tempo.

Esempio di vita reale n. 2: i modelli hanno rovinato la giornata. Grande sistema governativo che "ha riconosciuto" la necessità di modelli.

Questo mostra la capacità umana (o corporativa?) di trasformare la cosa migliore del mondo in un incubo.

La grande agenzia governativa ha chiesto alla grande società di consulenza di guidare la grande azienda IT a risolvere un problema. L'agenzia governativa ha anche istituito un grande organo ad hoc di esperti in materia governativa per aiutare e accelerare il processo.

Sono passati mesi in grandi parole e nel decidere su metodologie appropriate da usare e modi adeguati per usarle. Sono stati fatti tutti i tipi di compromessi, ovviamente, per non danneggiare i sentimenti o l'importanza di nessuno.

Risultato: l'architettura Sw doveva essere la fonte di tutto, compresi i modelli. Che dovevano essere progettati per primi e disegnati in secondo luogo. Mappando le azioni da OOAD e diagrammi di sequenza, sono stati realizzati diagrammi UX, quindi sono stati riconosciuti oggetti logici dell'interfaccia utente e pacchetti di contenuti, schermate effettive sono state disegnate e incorporate in casi d'uso formali, gli UC sono stati presentati agli utenti in seminari formali una volta al mese, quei seminari sono raddoppiati come riunioni di accettazione dei requisiti poiché qualcuno ha capito che il tempo sta passando.

In quei seminari, anche con la forza i clienti non potevano essere costretti a capire (altamente formale, con molte tabelle che descrivevano attributi di dati e simili) UC, ciascuno lungo circa 30 pagine. Quando i clienti hanno avuto un feedback, è stato sui modelli. Ma il feedback è stato scoraggiato, perché qualsiasi cambiamento nel mockup ha comportato la modifica dei diagrammi di sequenza, dei diagrammi dei componenti, del modello operativo, dei diagrammi UX, il controllo delle matrici di tracciabilità, l'aggiornamento dei testi UC, ecc ecc. E solo per ottenere più feedback. (" Accidenti ai clienti, non sono mai soddisfatti. " era la moto). Dopo il lancio di v1.0 con funzionalità limitate, a nessuno importava più della documentazione, ce n'era così tanto. Gli sviluppatori stavano combattendo per la propria vita, apportando una miriade di piccoli cambiamenti ogni giorno, solo per mettere in funzione il sistema (dopo che la serie di modifiche di ieri ha fatto rompere qualcos'altro).

Questo NON è il modo di usare i modelli. Il progetto è durato quasi 2 anni in più del previsto.

In altre parole, non cercare la metodologia ideale. O qualsiasi metodologia che non capisci. Qual è il tuo obiettivo al momento? Qual è il modo più veloce che conosci (gli altri modi non contano) per raggiungere questo obiettivo? Fallo.

Answer 4

Probabilmente dipende da chi stai lavorando. Se sei tu e un designer, allora una specifica funzionale potrebbe essere un problema. Ma, nel mio lavoro, i dirigenti vogliono sapere esattamente cosa otterranno alla fine di un progetto e quindi abbiamo avuto delle difficoltà a implementare lo sviluppo iterativo. Di solito le iterazioni sono definite con wireframe, specifiche funzionali e mock up .. :)

Answer 5

Lo scopo principale di realizzare wireframe è chiarire i requisiti. È sempre consigliabile documentare chiaramente i requisiti e non c'è modo migliore di visualizzare un requisito. Wireframes aiuta molto in questo senso, offre al proprietario del prodotto (cliente) una chiara idea di cosa aspettarsi dal prodotto finale. Su approvazione del proprietario del prodotto, fornisce anche al team di sviluppo un'immagine più chiara di cosa sviluppare, risparmiando molto tempo di sviluppo ed evitando conflitti. A mio avviso, i wireframe sono sempre utili per una corretta esecuzione del progetto anche quando il progetto è piccolo.

Answer 6

Credo che dipenda da quanto bene capisci cosa stai cercando di fare. Se lavori per un cliente che non ha espresso molto in termini di requisiti, potresti voler adottare un approccio con iterazioni estremamente rapide. Se hai già una buona comprensione e riesci a produrre qualcosa di più sostanziale senza preoccuparti di buttarlo via perché era nella direzione sbagliata, allora si può dedicare più tempo. Ad ogni modo, un prototipo cliccabile può fare molto per determinare ciò che il sito reale deve essere alla fine. Se riesci a ottenere un accordo sul prototipo, quando la tua applicazione corrisponde al prototipo sai che è completo.