Un mockup può sembrare finito e restare inutilizzabile. Succede quando non esiste una mappa delle pagine, il testo è riempitivo, i componenti cambiano nome fra schermate, gli stati responsive non sono definiti o il file modificabile rimane nell’account del fornitore.
IT-145 valuta il sistema di design, non un sito. Il pilota contiene un Brief-ID astratto, dodici Page-ID, otto Component-ID, sei Asset-ID vuoti, una voce di navigazione in conflitto, un contenuto senza fonte, tre breakpoint neutri, due identità di prova e una revisione da riaprire. Nessun elemento rappresenta una pagina reale.
Ogni decisione percorre input, ipotesi, proposta, annotazione, revisione, approvazione e handoff. Il corretto risultato di un campo privo di contenuto è un blocco. Un designer non deve inventare testo, persona, immagine o requisito per rendere completa una schermata.
Il confine con lo sviluppo è netto. IT-145 può definire struttura, componenti, stati e criteri. IT-146 decide tecnologia, implementazione, integrazioni, ambienti, test, rilascio e rollback. Una fonte che offre entrambi i servizi sostiene soltanto il processo di design valutato qui.
theStacc è l’editore di IT-145, ma non compare nella graduatoria perché le pagine ufficiali consultate non documentano un servizio autonomo di web design comparabile alle otto agenzie incluse. Non esiste quindi un prodotto dell’editore da classificare o un conflitto di posizione da occultare. Nessuna agenzia ha pagato per essere inclusa. Le descrizioni derivano soltanto dalle pagine ufficiali collegate, raggiungibili il 30 agosto 2026. Non abbiamo incaricato, intervistato o provato alcuna agenzia, team, account, brief, wireframe, prototipo, file, componente, revisione, handoff o export. Non riportiamo prezzi. Restano da verificare entità contrattuale, disponibilità, copertura italiana, lingua, specialisti assegnati, subfornitori, revisioni comprese, formati, accessi, custodia, tempi, qualità e condizioni di uscita. Le fonti di prima parte sostengono soltanto il perimetro dichiarato dal rispettivo fornitore. Non provano superiorità, risultati o idoneità per una specifica organizzazione odontoiatrica. Il pilota usa Brief-ID, Page-ID, Component-ID e Asset-ID astratti, testi vuoti, layout neutri e identità di prova. Non contiene studi, dentisti, pazienti, siti, casi, prezzi, test, posizionamenti, lead, ricavi, persone, revisori o proprietari reali o inventati. Non valuta testimonianze, generazione di recensioni o comunicazioni con pazienti. Non formula affermazioni cliniche, diagnostiche, terapeutiche, di sicurezza, legali, privacy, conformità o relative a esiti. IT-141, IT-142, IT-143 e IT-144 possiedono i workstream di marketing. IT-146 possiede codice, integrazioni, ambienti, test, rilascio e rollback. IT-145 termina a ricerca progettuale, architettura, UX/UI, contenuti, asset, revisioni e handoff di design. Mancano una revisione competente del perimetro odontoiatrico, una revisione linguistica italiana e un responsabile di manutenzione. La pagina rimane needs_human_review e non è autorizzata alla pubblicazione automatica.
La risposta breve
Digital Silk apre la selezione perché documenta discovery, ricerca, architettura informativa, wireframe, UX e revisioni prima del design visivo. Ramotion e OuterBox seguono per workshop, sitemap, sistemi di design, prototipi e accessibilità nel processo. Bop Design, SmartSites, Lounge Lizard, DD.NYC e Webstacks rappresentano altri modelli. Tutti richiedono lo stesso brief astratto e un export modificabile.
- Digital Silk: organizzazioni che vogliono verificare discovery, planning, information architecture, contenuti, wireframe, UX e sign-off come stadi distinti
- Ramotion: team che vogliono provare workshop, ricerca, sitemap, information architecture, copy direction, visual e sistema di design
- OuterBox: organizzazioni che vogliono verificare discovery, information architecture, wireframe, prototipi, visual, accessibilità e design system
- Bop Design: team che vogliono confrontare discovery, concetti iniziali, sitemap, design, contenuti, stakeholder e approvazioni
- SmartSites: organizzazioni che vogliono provare ricerca, piano delle pagine, struttura, feedback, iterazioni e responsive prima dello sviluppo
- Lounge Lizard: team che vogliono verificare UX research, UI, struttura dei contenuti, mobile-first e accessibilità progettuale
- DD.NYC: organizzazioni che vogliono una prova circoscritta su direzione visuale, UI/UX, responsive e interfaccia con accessibilità
- Webstacks: team che vogliono verificare web design, sistemi di design, branding, illustrazione e motion come librerie coordinate
Il registro delle decisioni di design
Il Brief-ID raccoglie obiettivo progettuale, inventario, pubblico astratto, messaggi ammessi, contenuti disponibili, esclusioni, vincoli, canali di revisione e criterio di consegna. Nel pilota non viene definito un pubblico di pazienti. Si usano soltanto ruoli generici e attività prive di dati sensibili.
La discovery produce domande e decisioni, non decorazione. Ogni input conserva fonte, responsabile astratto, stato e limite. Un requisito non confermato resta aperto. Il designer può segnalarne l’impatto su architettura o componenti, ma non lo trasforma in una funzionalità o in un testo inventato.
L’inventario collega Page-ID, stato, obiettivo, contenuto disponibile, dipendenze e proprietario del workstream. Una pagina proposta senza scopo o contenuto viene rifiutata. Le pagine di marketing rimangono collegate a IT-141 fino a IT-144 e non vengono create per riempire una sitemap.
L’architettura informativa distingue sezioni, pagine, gerarchia e percorsi. Il pilota introduce due voci che portano allo stesso obiettivo e richiede una decisione di consolidamento o differenziazione. Il diagramma conserva versione, motivazione, collegamenti e domande aperte.
La sitemap è una vista dell’architettura, non l’architettura stessa. Ogni nodo mantiene Page-ID, etichetta provvisoria, relazione, stato e contenuto richiesto. Spostare un nodo deve aggiornare wireframe, navigazione, contenuti e dipendenze, senza cancellare la decisione precedente.
Il content handoff precede la rifinitura visiva. Ogni blocco di testo conserva Content-ID, fonte, stato, limite, pagina, componente e revisione. IT-145 inserisce un campo deliberatamente vuoto. L’agenzia deve progettare lo stato mancante e impedire che un testo plausibile diventi definitivo.
I wireframe definiscono ordine, gerarchia, regioni, priorità e stati senza confondere tipografia finale con struttura. Ogni annotazione indica Page-ID, Component-ID, input, comportamento atteso e domanda aperta. Un rettangolo senza significato non è una specifica consegnabile.
I prototipi verificano flussi, non codice. Il pilota usa collegamenti astratti fra schermate e controlla percorsi, stati e ritorni. Nessun comportamento viene dichiarato implementato. La prova serve a decidere se architettura e interfaccia sono comprensibili prima del passaggio a IT-146.
Il sistema visivo conserva token, stili, componenti, varianti e regole di uso. Colore, tipografia, spaziatura, icone e media rimangono collegati alle decisioni approvate. Un valore isolato in una schermata deve diventare eccezione documentata o rientrare nel sistema.
Ogni Component-ID descrive nome, scopo, contenuto ammesso, varianti, stati, dimensioni, comportamento responsive e annotazioni. Header, navigazione, card, form, callout e footer possono essere rappresentati in modo astratto. IT-145 non decide markup, framework o API.
Il responsive design richiede stati espliciti. Il campione usa tre viewport neutre e controlla riordino, priorità, densità, navigazione e media. Non basta ridurre il desktop. Ogni variazione deve preservare gerarchia e contenuto, con eccezioni annotate per lo sviluppo.
L’accessibilità viene trattata come processo di design, non come certificazione. Contrasto, gerarchia, focus previsto, nomi, alternative, ordine e stati devono essere discussi e annotati. IT-145 non dichiara conformità. IT-146 dovrà implementare e verificare il comportamento reale.
I form rimangono strutture di design. Campi, gruppi, istruzioni, errori, conferme e ordine vengono descritti senza dati o invii. Nessun modulo reale viene costruito e nessuna informazione viene raccolta. Integrazioni, validazione e gestione dei dati appartengono a IT-146.
Gli asset hanno un registro separato. Asset-ID, file sorgente, formato, variante, destinazione, stato, autorizzazione interna e scadenza restano visibili. Nel pilota i contenitori sono vuoti. Nessuna fotografia, illustrazione, icona proprietaria, logo o persona viene inventata.
La revisione segue stadi dichiarati: brief, architettura, wireframe, direzione visiva, pagine campione, sistema e handoff. Ogni commento conserva oggetto, versione, ruolo astratto, decisione e stato. Un messaggio in chat non approva tutte le schermate dipendenti.
L’approvazione si applica a una versione esatta. Modificare contenuto, struttura, componente o asset riapre i controlli interessati. Il pilota cambia un Component-ID dopo l’approvazione e verifica che pagine campione, sistema e handoff tornino in revisione.
La custodia operativa richiede account e file trasferibili. Repository, piattaforma di design, cartelle, librerie, prototipi, fonti, esportazioni e cronologia devono restare accessibili all’organizzazione. Un link di sola visualizzazione non sostituisce i file modificabili e le dipendenze.
Il passaggio a sviluppo contiene inventario di pagine, componenti, varianti, token, asset, contenuti, annotazioni, stati responsive, decisioni e domande aperte. Ogni elemento ha un criterio di accettazione. IT-146 può rifiutare una specifica ambigua senza cambiare il design di nascosto.
Il change log collega richiesta, oggetto, versione, conseguenze, approvazione e workstream dipendenti. Un cambio dopo l’handoff deve indicare se aggiorna design, contenuti, sviluppo o più registri. Nessuna revisione diventa gratuita, inclusa o completata per supposizione.
L’export viene provato prima della revoca. Brief, sitemap, wireframe, prototipo, libreria, componenti, token, asset, contenuti, commenti, decisioni e backlog devono aprirsi in un secondo account o sistema. Soltanto dopo si rimuovono le identità neutre e si controllano collegamenti residui.
Prove di adeguatezza al settore da richiedere
- Il Brief-ID dichiara input, contenuti disponibili, esclusioni e domande aperte.
- Ogni Page-ID collega architettura, wireframe, contenuto e dipendenze.
- Ogni Component-ID conserva scopo, varianti, stati, responsive e annotazioni.
- I campi senza fonte rimangono vuoti e visibilmente bloccati.
- Le revisioni si riferiscono a una versione e riaprono i controlli dipendenti.
- L’accessibilità viene annotata come processo senza certificazioni inventate.
- Lo sviluppo riceve specifiche e criteri, non decisioni tecniche presunte.
- File modificabili, asset, librerie, commenti e backlog aprono in un secondo sistema.
Come abbiamo valutato i fornitori
La graduatoria misura soltanto la vicinanza fra processo ufficialmente documentato e pilota di design. Digital Silk è prima perché la pagina descrive discovery, ricerca, information architecture, wireframe, UX, review e sign-off prima della progettazione per mobile e desktop. La stessa fonte include sviluppo e test, che IT-145 non valuta.
Ramotion e OuterBox seguono perché documentano workshop, ricerca, sitemap, information architecture, copy direction, wireframe, prototipi, sistemi di design e accessibilità nel processo. Qualunque attività di sviluppo visibile sulle fonti rimane fuori dal confronto.
Bop Design e SmartSites descrivono discovery, sitemap o blueprint, design, contenuti, stakeholder, feedback e approvazioni. Lounge Lizard espone UX research, UI, responsive e accessibilità. DD.NYC documenta UI/UX, responsive design e un servizio di accessibilità. Webstacks documenta web design e design systems con branding, illustrazione e motion.
theStacc non viene classificata perché le pagine ufficiali consultate non sostengono un servizio autonomo comparabile. Questa esclusione evita di trasformare una capacità non documentata in un prodotto del publisher. Tutte le otto agenzie ricevono lo stesso brief astratto e la stessa prova di handoff.
| Criterio | Peso | Che cosa ha contato |
|---|---|---|
| Discovery e inventario | Priorità alta | Input, contenuti, esclusioni, Page-ID e domande aperte restano tracciabili. |
| Architettura e content handoff | Priorità alta | Gerarchia, sitemap, dipendenze e campi bloccati precedono il visual. |
| Wireframe, UX e prototipi | Priorità alta | Flussi, annotazioni, priorità e stati vengono decisi senza simulare codice. |
| UI, componenti e responsive | Priorità alta | Token, varianti, viewport e regole restano riutilizzabili e verificabili. |
| Revisioni e accessibilità | Priorità alta | Versioni, decisioni e controlli progettuali non diventano certificazioni. |
| Custodia, handoff ed export | Priorità alta | File modificabili, librerie, asset, commenti e backlog restano portabili. |
Ogni fornitore doveva soddisfare gli stessi requisiti minimi prima che la sua posizione venisse presa in considerazione.
- Una pagina ufficiale doveva descrivere web design, UX/UI o sistemi di design come servizio.
- Il perimetro documentato doveva includere almeno discovery, architettura, wireframe, UX/UI, responsive, design system o revisioni.
- Sviluppo, integrazioni, ambienti, QA, rilascio e rollback restano fuori anche quando la fonte li offre.
- Prezzi, siti, casi, risultati, team, copertura italiana e revisioni incluse non sono stati presunti.
- Il pilota usa soltanto brief, pagine, componenti, asset e decisioni astratti.
- theStacc non è inclusa perché manca una pagina ufficiale di servizio comparabile.
L’elenco dei fornitori analizzato
Le posizioni derivano dalla metodologia pubblicata e dalla data di chiusura delle fonti, non sono una garanzia di risultato. Ogni scheda indica la migliore adeguatezza e il limite che con maggiore probabilità cambia una decisione d’acquisto.
Digital Silk
Punti di forza documentati
- Discovery e ricerca documentate.
- Information architecture è uno stadio esplicito.
- Wireframe e UX vengono rivisti prima del visual.
- Content strategy e sign-off sono visibili.
Limiti da verificare
- Sviluppo e lancio esclusi.
- Revisioni effettive da confermare.
- Italia e team non verificati.
- File ed export richiedono prova.
Digital Silk apre la selezione perché la pagina ufficiale descrive discovery e ricerca, planning e information architecture, content strategy, wireframe e UX design, review, sign-off e progettazione per mobile e desktop. La fonte include anche sviluppo, testing e lancio, che IT-145 esclude. Non prova Italia, odontoiatria, team, revisioni comprese, file, proprietà, export, qualità o risultati.
Consegnate un Brief-ID, dodici Page-ID e un inventario incompleto. La discovery deve distinguere input, ipotesi e decisioni. Il campo senza fonte rimane bloccato e nessun contenuto viene creato per rendere piena la schermata.
Inserite un conflitto nella information architecture. Chiedete due proposte con conseguenze su sitemap, wireframe e contenuti, poi una decisione versionata. Il planning non può saltare direttamente al visual.
Modificate un wireframe dopo il sign-off. Il servizio deve riaprire review, UX, contenuti e pagine dipendenti. Sviluppo, QA e launch non vengono eseguiti o conteggiati nel pilota.
Richiedete file modificabili, librerie, asset, commenti, approvazioni, handoff ed export. Aprite tutto in un secondo account. Il primo posto descrive la sequenza documentata, non una prestazione osservata o una preferenza.
Fonti sui fornitori: Digital Silk, servizi web design ufficiali, consultati il 30.08.2026
Ramotion
Punti di forza documentati
- Workshop e discovery documentati.
- Sitemap e information architecture sono visibili.
- UX, visual e responsive compaiono.
- Web design system è dichiarato.
Limiti da verificare
- Sviluppo non valutato.
- Copy finale da confermare.
- Italia e revisioni non provate.
- Custodia ed export restano aperti.
Ramotion è seconda perché la pagina ufficiale descrive workshop e discovery, ricerca, brand guidelines, sitemap, information architecture e copywriting, UX, visual design, responsive layouts e web design systems. La fonte include anche development planning e sviluppo, che IT-145 non attribuisce al design. Non prova Italia, odontoiatria, team, revisioni, proprietà, export, qualità o risultati.
Fornite input astratti su obiettivi, tono e contenuti disponibili. Il workshop deve produrre decisioni e domande aperte, non inventare un pubblico o un posizionamento. Ogni scelta conserva origine e versione.
Create una sitemap con un nodo duplicato e un contenuto mancante. Information architecture e copy direction devono risolvere o bloccare i casi prima del visual. Nessun testo riempitivo diventa approvato.
Chiedete un design system con token, Component-ID, varianti e responsive. Cambiate un token dopo l’approvazione e verificate che schermate e handoff dipendenti tornino in revisione. Lo sviluppo resta fuori.
Richiedete file sorgente, libreria, commenti, prototipo, asset, decisioni, export e revoca. Il secondo posto riflette ampiezza progettuale pubblicata, non disponibilità o qualità osservata.
Fonti sui fornitori: Ramotion, servizi web design ufficiali, consultati il 30.08.2026
OuterBox
Punti di forza documentati
- Discovery e strategy documentate.
- Information architecture e wireframe sono visibili.
- Prototipi cliccabili compaiono.
- Accessibilità e design system entrano nel processo.
Limiti da verificare
- Ogni sviluppo è escluso.
- Nessuna conformità attribuita.
- Italia e revisioni da confermare.
- Export dei file resta aperto.
OuterBox figura terza perché la pagina ufficiale descrive discovery e strategy, information architecture, clickable prototypes, wireframe, visual design, fondamenti di accessibilità e design system documentato. La fonte presenta design e development insieme; IT-145 esclude front-end, back-end, CMS, integrazioni, QA e launch. Non prova Italia, odontoiatria, team, revisioni, file, export, qualità o risultati.
Consegnate Page-ID, obiettivi astratti e tre domande aperte. La discovery deve trasformarli in un piano con dipendenze, senza decidere tecnologia o integrazioni. Ogni input non confermato resta visibile.
Create un flusso con un passaggio ridondante. Information architecture, wireframe e prototipo devono mostrarne le alternative e la decisione. Nessuna interazione viene dichiarata implementata.
Annotate gerarchia, navigazione, contrasto e focus previsto come controlli di processo, senza dichiarare conformità. Il design system collega Component-ID, token e varianti allo sviluppo futuro.
Escludete sviluppo, CMS, API, QA e lancio. Richiedete file, librerie, commenti, asset, handoff ed export. Il terzo posto descrive un processo pubblico, non un sito consegnato.
Fonti sui fornitori: OuterBox, servizi web design ufficiali, consultati il 30.08.2026
Bop Design
Punti di forza documentati
- Discovery documentata.
- Sitemap e messaging sono stadi visibili.
- Design e contenuti compaiono nel processo.
- Feedback e approvazione hanno ruoli distinti.
Limiti da verificare
- Sviluppo e WordPress esclusi.
- SEO resta interfaccia a IT-141.
- Italia e revisioni non verificate.
- File ed export da provare.
Bop Design è quarta perché la pagina ufficiale presenta un processo con discovery, obiettivi, pubblico, concorrenti, concetti iniziali, messaging, sitemap, design, content e SEO. Descrive inoltre stakeholder che forniscono feedback e una persona autorizzata ad approvare. Sviluppo e WordPress restano fuori da IT-145. La fonte non prova Italia, odontoiatria, revisioni, file, export, qualità o risultati.
Create un Brief-ID con input incompleti e ruoli astratti. La discovery deve mostrare ciò che manca prima di costruire concetti o sitemap. Nessun confronto reale o contenuto viene inventato.
Fornite due proposte di sitemap e una voce senza scopo. Chiedete una decisione tracciata e il relativo impatto su messaging, wireframe e contenuti. La pagina senza scopo deve essere respinta.
Distinguete chi commenta da chi approva. Modificate poi un Page-ID e verificate che gli stakeholder interessati e il design system riaprano la revisione. Content e SEO rimangono interfacce verso IT-141.
Escludete sviluppo e CMS. Richiedete file modificabili, asset, brand guidelines, commenti, approvazioni, handoff ed export. Il posto quattro descrive il processo documentato, non l’esecuzione tecnica.
Fonti sui fornitori: Bop Design, servizi B2B web design ufficiali, consultati il 30.08.2026
SmartSites
Punti di forza documentati
- Ricerca e questionario documentati.
- Website plan e struttura richiedono approvazione.
- Feedback e iterazioni sono visibili.
- Responsive design è dichiarato.
Limiti da verificare
- Sviluppo e test esclusi.
- Revisioni incluse da confermare.
- Italia e custodia non provate.
- Export dei file resta aperto.
SmartSites è quinta perché la pagina ufficiale descrive ricerca su keyword e concorrenti, comprensione del pubblico, approvazione del website plan con pagine e struttura, feedback, iterazioni, revisioni e responsive design. La fonte include development, testing e launch, che IT-145 esclude. Non prova Italia, odontoiatria, team, revisioni realmente incluse, proprietà, export, qualità o risultati.
Consegnate un questionario astratto con due campi vuoti. Il piano deve registrare pagine, struttura e domande aperte senza inventare pubblico, messaggi o requisiti. La ricerca rimane un input da verificare, non un fatto sul pilota.
Create un blueprint con dodici Page-ID e una dipendenza non risolta. L’approvazione deve riferirsi a quella versione. Qualunque variazione di struttura riapre wireframe e contenuti collegati.
Chiedete responsive states per tre viewport neutre e revisioni versionate. Nessun codice, sicurezza, velocità o testing viene attribuito al design. Queste attività passano a IT-146.
Richiedete file modificabili, commenti, asset, revision history, handoff ed export. Il quinto posto riflette la trasparenza del processo pubblico, non l’inclusione effettiva di revisioni illimitate.
Fonti sui fornitori: SmartSites, servizi web design ufficiali, consultati il 30.08.2026
Lounge Lizard
Punti di forza documentati
- UX research documentata.
- UI e site architecture sono visibili.
- Responsive mobile-first compare.
- Accessibilità è citata nel perimetro.
Limiti da verificare
- Sviluppo e CMS esclusi.
- Nessuna conformità attribuita.
- Italia e revisioni non provate.
- File ed export restano aperti.
Lounge Lizard è sesta perché la pagina ufficiale descrive UX research, UI design, site architecture, content structure, mobile-first responsive design e accessibilità fra gli obiettivi del servizio. La fonte offre anche sviluppo e CMS, che IT-145 non valuta. Non prova Italia, odontoiatria, team, discovery dettagliata, revisioni, file, proprietà, export, qualità o risultati.
Fornite percorsi astratti e contenuti vuoti. La UX research deve produrre domande e criteri, non persone o siti inventati. La UI rimane collegata a Page-ID e Component-ID con decisioni versionate.
Create stati mobile, tablet e desktop per navigazione e componenti. Verificate riordino, gerarchia e densità. La parola responsive sulla fonte non dimostra che ogni stato o breakpoint sia incluso.
Annotate accessibilità, contenuto e struttura come requisiti di design senza dichiarare conformità. Codice, CMS, performance e test rimangono attività di IT-146.
Richiedete file, librerie, asset, commenti, revisioni, handoff ed export. Il sesto posto descrive le aree pubblicate, non completezza o qualità della consegna.
Fonti sui fornitori: Lounge Lizard, servizi web design ufficiali, consultati il 30.08.2026
DD.NYC
Punti di forza documentati
- Web design documentato.
- UI/UX compare nel portafoglio.
- Responsive design è esplicito.
- Servizio di accessibilità è elencato.
Limiti da verificare
- Processo dettagliato non visibile sulla pagina.
- Sviluppo e WordPress esclusi.
- Italia e revisioni non provate.
- File ed export da confermare.
DD.NYC è settima perché la pagina ufficiale presenta web design, UI/UX, responsive design e ottimizzazione per dispositivi, mentre il sito elenca anche Website Accessibility Services. La stessa offerta include WordPress e development, che IT-145 esclude. La fonte non documenta sulla pagina selezionata un processo dettagliato di architettura, revisioni, file o handoff e non prova Italia, odontoiatria, qualità o risultati.
Usate un Brief-ID limitato a visual, UI/UX e responsive. Chiedete all’agenzia di esplicitare discovery, architettura e review nella proposta, perché la pagina ufficiale scelta non ne documenta la stessa profondità dei primi candidati.
Create Component-ID con tre viewport e stati astratti. Ogni proposta conserva variante, annotazione e approvazione. Ottimizzazione per dispositivi non viene tradotta in codice o test reali.
Collegate l’accessibilità a controlli di design e domande aperte senza dichiarare conformità. WordPress, sviluppo e ogni implementazione passano a IT-146.
Richiedete formati modificabili, librerie, asset, revisioni, commenti, handoff ed export. Il settimo posto riflette la minore profondità processuale visibile, non un giudizio sulla qualità creativa.
Fonti sui fornitori: DD.NYC, servizio web design ufficiale, consultato il 30.08.2026
Webstacks
Punti di forza documentati
- Web design documentato.
- Design systems sono centrali nella pagina.
- Branding e illustration sono visibili.
- Motion design compare nel perimetro.
Limiti da verificare
- Discovery e IA da confermare.
- Sviluppo e QA esclusi.
- Revisioni e file non documentati.
- Italia ed export restano aperti.
Webstacks è ottava perché la pagina ufficiale delle design capabilities documenta web design, design systems, branding, illustration e motion design. Il sito presenta separatamente front-end, back-end, CMS e technical QA, che IT-145 non attribuisce al design. La pagina scelta non documenta con uguale dettaglio discovery, architettura, revisioni o handoff. Non prova Italia, odontoiatria, team, file, export, qualità o risultati.
Consegnate otto Component-ID astratti e una libreria vuota. Chiedete di distinguere web design, design system, branding, illustrazione e motion, con dipendenze e stati espliciti. Nessun asset viene inventato.
Cambiate un token dopo l’approvazione. Il sistema deve mostrare componenti e pagine dipendenti, riaprire la review e preservare la versione precedente. Coerenza e scalabilità restano criteri di design, non risultati.
Escludete front-end, back-end, CMS, integrazioni e technical QA. IT-146 riceve Component-ID, token, stati e annotazioni, poi decide implementazione e test.
Richiedete discovery, architettura, revisioni, file modificabili, commenti, handoff ed export nella proposta. L’ottavo posto riflette ciò che la pagina ufficiale documenta, non una valutazione della capacità reale.
Fonti sui fornitori: Webstacks, design capabilities ufficiali, consultate il 30.08.2026
Confronta il flusso di lavoro sulla tua attività
Esamina i servizi gestiti, i controlli di approvazione, le destinazioni di pubblicazione e i limiti dichiarati di theStacc prima di scegliere.
Otto processi sullo stesso brief astratto
La tabella collega soltanto il perimetro visibile sulle pagine ufficiali a una parte del pilota. Non attribuisce sviluppo, qualità, prezzi, disponibilità, copertura italiana, siti o risultati.
| Fornitore | Modello di erogazione | Ambito documentato | Ideale per | Limite principale |
|---|---|---|---|---|
| Digital Silk | Processo strategico | discovery, IA, content, wireframe, UX, sign-off | stadi e revisioni | sviluppo escluso |
| Ramotion | Design e sistema | workshop, sitemap, IA, copy, visual, system | architettura e libreria | export da provare |
| OuterBox | UX e prototipi | discovery, IA, wireframe, prototype, accessibility | flussi annotati | nessuna conformità |
| Bop Design | B2B design process | discovery, concepts, sitemap, design, content | stakeholder e contenuti | WordPress escluso |
| SmartSites | Blueprint e iterazioni | research, plan, structure, feedback, responsive | approvazione struttura | revisioni da confermare |
| Lounge Lizard | UX/UI responsive | UX research, UI, content structure, accessibility | tre viewport | CMS escluso |
| DD.NYC | Visual e UI/UX | web design, UI/UX, responsive, accessibility service | prova circoscritta | processo poco dettagliato |
| Webstacks | Design capabilities | web design, systems, branding, illustration, motion | libreria componenti | IA e revisioni aperte |
Il pilota di design prima del passaggio a sviluppo
Il pacchetto contiene un Brief-ID, dodici Page-ID, otto Component-ID, sei Asset-ID vuoti, una voce di navigazione in conflitto, un contenuto senza fonte, tre viewport neutre, due identità di prova e una revisione da riaprire. Nessun sito viene progettato o costruito.
Ogni fase definisce input, stato, versione, ruolo, criterio, prova e controcaso. Il pilota non sceglie una direzione estetica. Confronta disciplina su architettura, contenuti, componenti, revisioni, accessibilità progettuale, custodia, handoff ed export.
1. Congelare brief e inventario
Assegnate Brief-ID, Page-ID, Component-ID e Asset-ID. Ogni elemento conserva stato, input, dipendenza e domanda aperta. I contenuti e gli asset mancanti restano vuoti.
Classificate dodici pagine come mantenere, ripensare, consolidare, escludere o da decidere, senza usare siti reali. Una pagina senza obiettivo o contenuto non entra automaticamente nella sitemap.
Congelate la baseline. Nuovi requisiti diventano richieste versionate con conseguenze su architettura, componenti, contenuti e handoff.
- Brief-ID.
- Dodici Page-ID.
- Otto Component-ID.
- Sei Asset-ID.
- Campi vuoti bloccati.
- Baseline congelata.
2. Decidere architettura e contenuti
Create una sitemap astratta con due nodi in conflitto. Chiedete consolidamento, differenziazione o rifiuto con motivazione e dipendenze. La versione precedente rimane nel log.
Collegate ogni Page-ID a Content-ID, fonte e stato. Inserite un blocco senza fonte e verificate che wireframe e visual non lo riempiano con testo plausibile.
Aggiornate navigazione, wireframe e dipendenze dopo la decisione. Una etichetta spostata non chiude il lavoro finché i registri collegati non sono coerenti.
- Sitemap versionata.
- Conflitto aperto.
- Decisione motivata.
- Content-ID collegati.
- Blocco preservato.
- Dipendenze aggiornate.
3. Provare wireframe, UI e responsive
Create wireframe annotati per pagine campione. Ogni regione conserva Component-ID, contenuto previsto, stato e domanda. Nessun rettangolo rimane privo di significato.
Costruite varianti di componenti e tre viewport neutre. Verificate gerarchia, riordino, navigazione e densità. IT-145 non produce codice o comportamento reale.
Annotate contrasto, focus previsto, alternative e ordine come controlli di processo. Non dichiarate conformità. Le verifiche implementative restano a IT-146.
- Wireframe annotati.
- Componenti nominati.
- Varianti definite.
- Tre viewport.
- Controlli accessibilità.
- Nessuna certificazione.
4. Riaprire la revisione e preparare l’handoff
Approvate una versione esatta, poi modificate un Component-ID. Pagine campione, libreria e annotazioni dipendenti devono tornare in revisione. Il log conserva decisione e conseguenze.
Preparate inventario per IT-146 con pagine, componenti, token, asset, contenuti, responsive, annotazioni, stati e domande aperte. Nessuna tecnologia o integrazione viene presunta.
Chiedete allo sviluppo di rifiutare una specifica ambigua. Il design deve chiarirla e produrre una nuova versione, non lasciare che il codice decida silenziosamente.
- Versione approvata.
- Cambio registrato.
- Controlli riaperti.
- Inventario completo.
- Tecnologia non presunta.
- Ambiguità respinta.
5. Aprire l’export e revocare
Esportate brief, sitemap, wireframe, prototipo, libreria, componenti, token, asset, contenuti, commenti, decisioni e backlog. I file devono rimanere modificabili.
Aprite tutto in un secondo account o sistema. Un nuovo operatore deve riconoscere versione approvata, elementi bloccati e prossime azioni senza contattare l’agenzia precedente.
Revocate le identità neutre dopo la prova. Controllate link, librerie, font, asset e integrazioni residue. Ogni elemento non verificabile rimane aperto.
- File modificabili.
- Libreria inclusa.
- Decisioni preservate.
- Secondo sistema aperto.
- Identità revocate.
- Residui registrati.
Errori che rendono inutile un confronto SEO
- Disegnare prima dell’inventario. Page-ID, contenuti, dipendenze e domande aperte devono precedere le schermate.
- Usare testo riempitivo come contenuto. Un campo privo di fonte resta bloccato e non diventa definitivo per comodità visuale.
- Confondere sitemap e architettura. La mappa mostra nodi; decisioni, motivazioni e dipendenze restano nel registro.
- Lasciare componenti senza identità. Varianti, stati, responsive e cambi diventano impossibili da propagare.
- Approvare una direzione e non la versione. Ogni modifica a contenuto, struttura o UI riapre i controlli pertinenti.
- Dichiarare accessibilità dal mockup. Il design annota requisiti; sviluppo e verifica reale appartengono a IT-146.
- Consegnare solo immagini finali. File modificabili, librerie, asset e commenti servono alla manutenzione.
- Lasciare che lo sviluppo risolva ambiguità. Una specifica incompleta deve tornare al design con una nuova decisione.
- Mescolare design e marketing. IT-141 fino a IT-144 possiedono fonti, canali, contenuti e risultati di marketing.
- Revocare prima dell’export. File, librerie e decisioni devono aprirsi altrove prima di rimuovere gli accessi.
Domande frequenti
Quali agenzie di web design dovrebbero valutare per primi i dentisti?
Digital Silk apre questa selezione perché documenta discovery, ricerca, architettura informativa, wireframe, UX e revisioni prima del visual. Ramotion e OuterBox seguono con workshop, sitemap, sistemi di design, prototipi e accessibilità nel processo. L’ordine descrive il perimetro ufficiale, non qualità. Ogni agenzia deve superare lo stesso brief astratto, il change test e l’export modificabile.
Che cosa comprende un servizio di web design?
Nel perimetro di IT-145 rientrano discovery, inventario, architettura informativa, sitemap, content handoff, wireframe, prototipi, UX/UI, sistema visivo, componenti, responsive, controlli di accessibilità, revisioni, asset, handoff ed export. Codice, CMS, integrazioni, ambienti, test, rilascio e rollback appartengono a IT-146 anche quando la stessa agenzia offre entrambi i servizi.
Come si confrontano agenzie senza inventare un sito?
Usate Brief-ID, Page-ID, Component-ID e Asset-ID astratti, testi vuoti, layout neutri, una navigazione in conflitto, tre viewport e identità di prova. Nessuna pagina reale viene progettata. Confrontate come l’agenzia registra input, decisioni, versioni, revisioni, dipendenze, accessibilità progettuale, handoff ed export. Il test misura processo e portabilità, non estetica o risultati.
Che cosa deve contenere la discovery?
La discovery dovrebbe raccogliere obiettivi progettuali, inventario, contenuti disponibili, esclusioni, vincoli, stakeholder astratti, domande aperte e criteri di consegna. Ogni input conserva fonte e stato. Un requisito non confermato resta aperto. La discovery non autorizza a inventare pubblico, messaggi, funzionalità o contenuti per rendere più completa una proposta.
Come si verifica l’architettura informativa?
Collegate ogni nodo a Page-ID, obiettivo, contenuto, relazione e stato. Introducete due voci sovrapposte e chiedete consolidamento, differenziazione o rifiuto con motivazione. Aggiornate sitemap, navigazione, wireframe e dipendenze. La versione precedente resta nel log. Una mappa ordinata non basta se decisioni e contenuti rimangono ambigui.
Come si gestisce un contenuto mancante?
Assegnate Content-ID, pagina, componente, fonte richiesta e stato bloccato. Progettate lo spazio e l’errore senza scrivere testo plausibile. Quando arriva una fonte adeguata, create una nuova versione e riaprite i controlli dipendenti. Un placeholder eliminato o un paragrafo generico non risolve la lacuna e non autorizza l’approvazione.
Che cosa deve mostrare un wireframe?
Ogni wireframe dovrebbe mostrare ordine, gerarchia, regioni, Component-ID, contenuto previsto, comportamento e domande aperte. Le annotazioni spiegano il motivo della struttura e le dipendenze. Un rettangolo senza identità non è una specifica. Il wireframe verifica il flusso prima della rifinitura visuale e non viene presentato come codice o pagina implementata.
Come si controlla un sistema di design?
Inventariate token, stili, Component-ID, varianti, stati, responsive e regole di uso. Collegate ogni componente a pagine campione e decisioni. Cambiate un token dopo l’approvazione e verificate che le dipendenze tornino in revisione. Un sistema utile conserva coerenza e modificabilità senza affidarsi alla memoria del designer o a valori isolati.
Come si prova il responsive design?
Usate almeno tre viewport neutre e controllate riordino, gerarchia, navigazione, densità, media e varianti dei componenti. Non limitatevi a ridurre la schermata desktop. Ogni eccezione viene annotata per IT-146. Il pilota valuta specifiche e decisioni, non implementazione, prestazioni o comportamento su dispositivi reali.
Come si tratta l’accessibilità nel design?
Annotate contrasto, gerarchia, focus previsto, nomi, alternative, ordine, stati ed errori come requisiti di progetto. Non dichiarate conformità da un mockup. IT-146 dovrà implementare e verificare il comportamento reale. Il pilota controlla che decisioni e domande aperte restino visibili e che nessun requisito venga silenziosamente ignorato.
Che cosa rende valida una revisione?
La revisione deve riferirsi a un oggetto e a una versione esatta, con ruolo astratto, commento, decisione e stato. Una approvazione generale non copre modifiche future. Se cambiano contenuto, architettura, componente o asset, si riaprono i controlli interessati e si avvisano i workstream dipendenti. La cronologia precedente non viene cancellata.
Chi dovrebbe custodire file e librerie?
L’organizzazione dovrebbe mantenere accesso istituzionale a piattaforma di design, repository, librerie, prototipi, fonti, asset, commenti e cronologia. Il fornitore usa identità individuali e privilegio minimo. Un link di sola visualizzazione non sostituisce file modificabili e dipendenze. Prima dell’uscita provate export, recupero e revoca in un secondo account.
Che cosa deve ricevere IT-146?
Lo sviluppo dovrebbe ricevere inventario di pagine, Component-ID, varianti, token, asset, contenuti, annotazioni, stati responsive, decisioni, domande aperte e criteri di accettazione. Non riceve tecnologia o integrazioni presunte. Se una specifica è ambigua, IT-146 la rifiuta e il design produce una nuova versione invece di lasciare che il codice decida silenziosamente.
Che cosa separa IT-145 da IT-141 fino a IT-144?
IT-145 possiede architettura, wireframe, UX/UI, componenti, responsive e asset di design. IT-141 gestisce SEO organico, IT-142 presenza locale, IT-143 operazioni sociali e IT-144 regia digitale. I workstream di marketing forniscono contenuti e dipendenze, ma non approvano automaticamente layout o componenti. Registri, account, prove ed export rimangono separati.
Che cosa separa IT-145 da IT-146?
IT-145 definisce struttura, componenti, varianti, stati, contenuti, responsive, annotazioni e criteri. IT-146 decide codice, framework, CMS, integrazioni, ambienti, test, rilascio e rollback. Un prototipo non è una implementazione. Il passaggio avviene tramite un inventario versionato, e lo sviluppo può respingere specifiche ambigue senza modificare il design di nascosto.
Che cosa deve contenere il pacchetto di uscita?
Esportate brief, inventario, sitemap, wireframe, prototipo, libreria, componenti, token, asset, contenuti, commenti, decisioni, revisioni e backlog. Aprite tutto in un secondo account o sistema prima della revoca. Un nuovo operatore deve riconoscere versione approvata, elementi bloccati, dipendenze e prossime azioni senza contattare l’agenzia precedente.
Perché theStacc non compare nella graduatoria?
theStacc pubblica IT-145, ma le pagine ufficiali consultate non documentano un servizio autonomo di web design comparabile. Includerla avrebbe trasformato una capacità non provata in un prodotto e creato un conflitto artificiale. L’esclusione viene dichiarata prima della graduatoria. Le otto agenzie incluse dispongono invece di pagine di servizio ufficiali e verificabili.
Perché IT-145 rimane in revisione umana?
Le descrizioni provengono da fonti ufficiali, ma nessuna agenzia, team, brief, sitemap, wireframe, componente, revisione, file, handoff o export è stato provato. Domanda esatta e risultati di ricerca italiani non sono verificati. Mancano revisione competente, revisione linguistica e responsabile di manutenzione. Le verifiche tecniche non sostituiscono queste responsabilità. Lo stato resta needs_human_review.
Fonti e politica editoriale
Consulta le fonti collegate insieme alla metodologia e alla nota dell’editore di questo articolo. Verifica prezzi, funzionalità e condizioni attuali con ogni fornitore; una citazione da sola non dimostra che sia stato svolto un test pratico.
- [01]Digital Silk, servizi web design ufficiali
- [02]Ramotion, servizi web design ufficiali
- [03]OuterBox, servizi web design ufficiali
- [04]Bop Design, servizi B2B web design ufficiali
- [05]SmartSites, servizi web design ufficiali
- [06]Lounge Lizard, servizi web design ufficiali
- [07]DD.NYC, servizio web design ufficiale
- [08]Webstacks, design capabilities ufficiali
Provate l’export modificabile prima di passare a sviluppo
Un pilota utile blocca un contenuto senza fonte, risolve una voce di navigazione in conflitto, annota wireframe e responsive, riapre la revisione dopo un cambio componente, rifiuta una specifica ambigua, revoca due identità neutre e apre librerie, file e backlog in un secondo sistema. IT-145 richiede ancora revisione competente, revisione linguistica italiana e un responsabile di manutenzione prima della pubblicazione.