Costruisci funzionalità attorno al design o viceversa?

Vedo solo dei vantaggi nel fare prima l'interfaccia utente:

• Coinvolgi i tuoi clienti nella progettazione dell'applicazione prima o dopo
• Avere un'idea migliore di ciò che l'applicazione deve coprire (che aggiunge semplicemente a un documento dei requisiti esistente)
• I titolari delle azioni possono vedere meglio quello che stanno pagando in modo che possano prendere una decisione più istruita
• Apporta le modifiche in anticipo sulla base delle discussioni sull'interfaccia utente
• Avere la possibilità di costruire un prototipo (o proof-of-concept) se le persone non sono ancora completamente fiduciose sulla soluzione
• Sono in grado di dividere il tuo team per lavorare sull'interfaccia utente mentre altri lavorano su altri livelli
• È più probabile che l'applicazione sia di facile utilizzo (come hai indicato tu stesso)
• Ti fornisce un riferimento molto migliore per discutere le funzionalità con i tuoi colleghi e il tuo cliente
• Consentono di decidere meglio su cosa sarà implementato in modo che in seguito, se il tuo cliente torna lamentando che alcune funzionalità sono mancanti, puoi richiamare i mockup e dimostrarli sbagliati

Non devi nemmeno usare Photoshop o niente di interessante (o costoso) per progettare prima la tua interfaccia utente. Potresti usare questo bellissimo (e non costoso) strumento chiamato Balsamiq . Ti consente di creare mockup molto puliti che ti consentono di concentrarti sulla funzionalità piuttosto che su oggetti di fantasia che sono molto importanti in una fase iniziale.

Ho attraversato praticamente tutti gli scenari che ho appena elencato e la progettazione dell'interfaccia utente è stata per me una decisione molto buona in diversi progetti.

L'unico inconveniente che vorrei dire è che ci vuole più tempo in anticipo. Ma questo non è nemmeno un argomento valido contro di esso dal momento che potrai sicuramente risparmiare più tempo in base a tutto ciò che ho appena elencato.

Se hai qualche coinvolgimento con il cliente, lavora prima l'interfaccia utente, mostralo a loro, cambialo alcune volte (da quello che hanno chiesto a ciò che vogliono veramente), quindi scrivi il back-end. Ciò ti consente di risparmiare tempo durante la scrittura, quindi di riscrivere e quindi riscrivere di nuovo l'intero stack.

Se non hai il coinvolgimento del cliente, in realtà non fa molta differenza nella mia esperienza.

Devo dire che non sono non a raccomandare di scrivere l'intera intera UI prima di scrivere il back-end. Tutto dovrebbe essere fatto un comportamento alla volta, in modo che ci sia sempre un'applicazione funzionante da dimostrare, anche se manca molto del comportamento previsto.

Ho trovato che spesso devi fare entrambi in parallelo. ad esempio, l'interfaccia utente potrebbe imporre che è necessaria una API Web per l'interazione AJAX o una determinata struttura per le pagine. d'altra parte, dovrai progettare come il tuo livello inferiore accederà ai dati e fornirà servizi. quindi la parte divertente è creare i controller per collegarli tutti.

Dipende davvero dal tipo di applicazione che svilupperai. Ma supponiamo che creerai un'interfaccia utente piuttosto complessa con molte funzionalità, quindi avere un concetto chiaro prima, scritto su un pezzo di carta o come schizzo in una sorta di programma di disegno, ti aiuterà a farlo bene.

Questo non significa che dovresti implementare quell'interfaccia utente nel suo complesso prima di iniziare a implementare i functionalites alla volta. Meglio implementare solo la maggior parte di ciò che è necessario per far funzionare una certa funzionalità (scrum la gente potrebbe chiamarla una "user story"). Usa la tua "UI di Photoshop" come una guida o una "visione" approssimativa di come apparirà l'interfaccia utente finale alla fine, ma non di più.

Disadvantages: the programming will get more complicated, so development time increases

Cosa ti fa pensare questo? Seguire un piano non renderà le cose più complicate, specialmente a lungo termine, questa è la mia esperienza.

In generale dovresti progettare attorno alla funzionalità.

Il ragionamento alla base di questo è che il tuo cliente avrà un'idea per un sistema in mente, e tuttavia non avrà davvero tutti i dettagli risolti. Queste sono cose che dovrai prendere in giro nel tempo, e sono cose che potrebbero - e molto probabilmente cambieranno -. Quando inizi con la GUI, chiedi al cliente di mettere tutte le sue idee sullo schermo, e tuttavia hai perso l'opportunità di avere una visione imparziale dei processi e delle funzionalità di cui il cliente ha bisogno. Certo, potrebbero avere molti dei loro bisogni definiti con il modo in cui potrebbero sembrare uno schermo, ma senza capire il flusso di lavoro critico e i problemi di gestione dei dati, si ottiene solo una piccola parte dell'immagine in primo piano. Le GUI possono essere pignoli per avere ragione, e puoi trovarti a spendere un sacco di tempo su di loro, il che potrebbe rischiare di finire il tempo per fare il serio back-end, e basandoti sulla GUI per dettare il design generale, si rischia di creare una dipendenza tra l'interfaccia utente e il back-end.

L'avvio del contrario sembra meno intuitivo per molte persone (incluso il cliente), ma in seguito può farti risparmiare molto mal di cuore. Mentre da un lato si desidera prendere decisioni importanti fino all'ultimo momento, avere tutte le informazioni possibili in anticipo vi permetterà una certa flessibilità nel modo in cui implementate un sistema. Avrai bisogno di sapere in anticipo se gestirai grandi volumi di dati e se comunicherai quei dati oltre i confini del PC locale dell'utente. Avrai bisogno di un sistema distribuito, N-Tier, Web-Based, ecc.? Conoscere questa roba in primo piano ti dà il tempo di ricercare le opzioni mentre codifichi le tue regole aziendali in librerie che potrebbero esistere in quasi tutte le configurazioni.

Qualcos'altro su cui ponderare, è che potresti voler consegnare un intero sistema alla fine, o programmare importanti rilasci di pietra miliare, o rilasciare in modo incrementale nello stile Agile. Quando si inizia con la GUI, si blocca il cliente in una particolare modalità di pensiero, cioè in come il software verrà percepito. Se inizi con il back-end e rilasci in modo incrementale, puoi costruire un'interfaccia rudimentale e dire al tuo cliente che si tratta semplicemente di fornire un mezzo per condurre un test controllato di funzionalità, in modo che il cliente possa decidere il modo migliore per presentare tale funzionalità ai loro utenti, mantengono il loro marchio e così via. A partire dalla GUI si limiterà a limitare il pensiero di tutti in termini di possibilità di presentazione di essere prevenuti verso ciò che tutti vedono per primi.

Disadvantages:

the programming will get more complicated, so development time increases

Non c'è alcun motivo per cui questo deve essere vero.

Se si sta sviluppando un'applicazione di una linea di tipo business, è necessario adattare l'applicazione al flusso aziendale richiesto per ogni funzione aziendale. Ci sono alcuni aspetti della GUI dell'applicazione che non saranno influenzati molto dalle funzioni specifiche dell'applicazione come accesso, aiuto, sfondi, stili di menu, piè di pagina, ecc. Puoi costruire le parti comuni in un prototipo e aggiungere la tua funzionalità a quello o dimostrare la funzionalità utilizzando prima BPM, quindi unirlo nel prototipo, se necessario.

Prova a separare il design dalla funzionalità, laddove possibile e disponi di uno strato di comunicazione tra i due.

In questo modo puoi avere un ui stupido e un backend intelligente e lo sviluppo di entrambi è piuttosto indipendente, offrendoti il meglio di entrambi i mondi.

In generale, vuoi lavorare con gli utenti, per assicurarti di creare qualcosa che troveranno utile. Questo è il modo migliore per creare applicazioni che supportano il flusso di lavoro esistente degli utenti.

D'altro canto, il semplice supporto dei flussi di lavoro esistenti può non cogliere l'opportunità di creare un'app killer rompicapo: il supporto informatico a volte può consentire un flusso di lavoro completamente diverso. Questa è un'opzione più rischiosa (se è disponibile a tutti), ma a volte può ripagare in grande.

Per quanto riguarda la funzionalità: dopo aver compreso a fondo i requisiti degli utenti, è necessario assicurarsi che le funzionalità di base facciano effettivamente ciò di cui hanno bisogno. Quindi (idealmente) dovresti assicurarti che l'interfaccia utente rispetti questa funzionalità di base, in modo che un utente possa capire quali azioni sta eseguendo. In questo modo, supportando anche i flussi di lavoro come menzionato sopra (sia tradizionali che nuovi) può essere non banale.

In ogni caso, inizia con i tuoi utenti. Più comprendi le esigenze dell'utente, più è probabile che tu possa produrre software utilizzabile.

Sono un dev di interfaccia utente web e penso davvero, a meno che non sia un sito di contenuti one-off molto semplice con un minimo di comportamento specializzato, che crea e approva un mockup con l'intento di creare un duplicato esatto senza aver toccato uno qualsiasi dei sottostanti back-end / model-controller / dati, o qualunque cosa tu stia lanciando sotto un termine un po 'generico di "funzionalità" è la peggiore strada da percorrere.

Ci sono tre ragioni per questo.

1. È fin troppo facile per i clienti e altrettanto facile per i project manager, i boss e gli exec e sì, anche gli sviluppatori, per investire eccessivamente nell'IU e dimenticare i problemi che l'app avrebbe dovuto risolvere in primo luogo.

2. Nessuno potrà prevedere a priori tutti i problemi / sfide inerenti l'ambito di applicazione generale. Quando hai un set di aspettative UI molto specifico, potresti dover svolgere molto lavoro non necessario a causa di complicazioni se hai a che fare con tipi aziendali poco flessibili che conoscono meglio i punti su Is e crosses su Ts, quindi risolvono i problemi quando risolvono problemi una semplice modifica che non influenza UX avrebbe potuto significare la differenza tra giorni e settimane.

3. Potresti perdere importanti opportunità per trovare un modo migliore di fare cose che semplicemente non si avvantaggiano senza qualcosa con cui davvero mettere le mani e giocare. Quando decidiamo cosa è l'interfaccia utente buona e cattiva o cosa potrebbe essere migliore? Quando utilizziamo le app, non quando i nostri nasi sono in Photoshop.

Se sei nella posizione fortunata di avere un certo controllo sul processo di sviluppo, fai un po 'di pianificazione e poi butta fuori il primo prototipo nella sua forma più grezza possibile al più presto. Certo, i comboBox sono belli ma una casella di selezione lo farà. I modali con contenuto Ajax sono puliti, ma ricaricare la pagina non ucciderà nessuno alla prima esecuzione. Prima risolvi il problema. POI inizierai a trafficare con l'interfaccia utente.

Leggi su concetti come MVC. Se hai familiarità con la separazione lato cliente delle preoccupazioni sul web, il concetto non sarà del tutto estraneo a te. Quindi separa le preoccupazioni come ritieni opportuno (ma non applicare l'applicazione dogmatica di alcun modello, ma manca il punto). Alla fine della giornata, l'interfaccia utente dovrebbe essere nient'altro che una maschera che si adatta a un'app sottostante che ti offre già un mezzo per accedere ai dati e ai metodi di comunicazione di cui hai bisogno ma quando inizi con l'interfaccia utente senza alcun piano sottostante o completo comprensione del problema, è facile avere preoccupazioni distorte. Ottieni i tuoi dati e i problemi di comunicazione risolti prima con un'interfaccia utente semplice e brutta. Allora immagina.

La funzionalità non è la stessa dell'interfaccia utente tranne alcune applicazioni molto banali.

Funzioni, quali: -

• Mantieni una cronologia delle transazioni.
• Conserva una somma delle imposte sulle vendite per i rapporti ai mostri IVA.
• Convalida il pagamento paypal.
• Saldo del saldo paypal.
• Trova l'ufficio FedEx più vicino da googleMaps

Non può essere espresso in un'interfaccia utente.

Inoltre, una buona interfaccia utente riguarda sia la sequenza di un flusso di eventi sia l'aspetto e il layout. Usa Use Case per catturare l'essenza dell'interazione dell'utente prima di iniziare a progettare qualsiasi schermo.

Quindi sei sulla buona strada. Ma prova a ottenere un elenco di funzioni e una serie di casi d'uso prima di iniziare a progettare l'interfaccia utente. Sarai sorpreso di quanto questo approccio possa semplificare il tuo design.