Ho progettato e oscurato altri progettando più sistemi in passato e ho visto il processo svolgersi in molti modi diversi, ma quello che trovo comune è che l'architettura iniziale dovrebbe almeno pianificare l' esistenza delle principali funzionalità.
Per esempio, ho visto un sistema di controllo HVAC che non aveva il concetto di edifici, piani, stanze ecc. Che venivano adattati con quelli e il risultato era brutto come loro. O un dispositivo musicale mobile costruito con componenti più adatti al tuo orologio da tasca (non intelligente). Inutile dire che i prodotti finali in entrambi i casi non erano i preferiti dai clienti.
Quando dici "concezione" questo è solo un passo avanti rispetto a "idea" e un concetto può essere molto confuso. Gli affari di solito si preoccupano dei concetti. Di solito i clienti si preoccupano di UX: un concetto che diventa realtà in un modo facile e piacevole da usare e porta un valore attraverso il suo utilizzo.
Devi fare un "concetto" prima di qualsiasi programmazione, non riesco a immaginarmi di aprire Visual Studio (o il tuo IDE preferito) e scrivere casualmente il codice, per vedere dove va.
Non puoi fare un progetto completo (e non dovresti) prima della codifica, ma dovresti avere uno schizzo approssimativo di quale sarebbe il flusso di lavoro dell'utente.
La progettazione e la codifica di UX si nutrono abbastanza spesso l'una dell'altra, probabilmente sarai costretto a usare un approccio Agile per progetti tutt'altro che piccoli come modo per incorporare questo fatto nel modo in cui approcci il lavoro. Quindi non pensare di essere il peggiore dei programmatori se non riuscissi a vederlo tutto in una volta: nessuno può e le persone che pensano di poter essere sono quelle che ignorano abbastanza il problema in modo da poter affermare di avere un completo immagine.
Un esempio per dare una dimensione a qualcosa di grande. Concetto: "Creare uno strumento basato su cloud visivo che consenta alle aziende di integrare le proprie piattaforme software". Sembra fantastico e si può iniziare a scrivere materiale di marketing e venderlo prima ancora che sia lì. Devi avere questo prima di scrivere codice.
Pre-progettazione: "Avere forme e frecce come in Visio per descrivere la logica; avere funzionalità plug-in per consentire connessioni a varie piattaforme (SAP, SF, database ...); avere una console di monitoraggio in cui è possibile cercare i dati passando attraverso il sistema; avere un modo di descrivere visivamente i dati e trasformare un formato in un altro ". Un altro grande blob di marketing. Ti dà anche alcune idee su ciò che è importante, dovrebbe avere uno schizzo così approssimativo prima di scrivere anche il codice.
Design / Codice: "Avere un browser HTML designer ospitato con tali e tali funzionalità; codificare il back-end in Java in modo che possa essere eseguito su qualsiasi server esistente; definire strutture di dati e UX per interrogarli o modificarli in base alle esigenze; pianificare il ripristino di emergenza, errore rendicontazione, registrazione di audit; controllo della versione del piano; controllo dell'accesso al piano; .... ": più fine è l'elenco, più non realistico è prevederlo tutto.
... tuttavia si dovrebbe essere almeno consapevoli di come potrebbero apparire le cose in modo approssimativo o il tuo prodotto finale potrebbe finire con alcune implementazioni davvero inutili che finiscono per uccidere il concetto altrimenti di grande suono - diciamo che il tuo designer visivo richiede un 40 " schermata per mostrare qualsiasi flusso di lavoro nel mondo reale, oppure non c'è modo di cercare nei registri se non una corrispondenza esatta tra le stringhe limitata a uno dei 20 campi nel registro ecc. ecc. Non esiste un buon modo per impedire che ciò avvenga se non l'esecuzione della propria implementazione - alcuni avranno successo, altri falliranno.