Work Queue

Pattern operativo per mostrare ciò che richiede un intervento, ciò che attende l’altra parte e ciò che deve essere controllato, usando soltanto azioni e stati reali del Workspace.

Quando usarla

Usa una work queue quando una superficie deve rispondere subito a “che cosa devo fare adesso?”. Ogni elemento deve derivare da un’azione realmente disponibile o da un’attesa verificabile.

Non usarla come lista di attività recenti, riepilogo di tutti i lavori o audit log. Gli eventi spiegano che cosa è successo; la work queue spiega che cosa serve fare o controllare ora.

Informazioni di ogni item

La gerarchia parte dall’azione, prosegue con il contesto e rende espliciti stato e persona che deve intervenire.

Titolo
Descrive l’azione o la situazione in linguaggio umano.
Contesto
Nomina il lavoro e aggiunge solo il dettaglio necessario per distinguerlo.
Stato
Usa una label comprensibile e coerente con lo stato reale.
Responsabile
Dichiara chi deve intervenire: l’utente, l’Azienda o il Cliente.
Azione
Apre direttamente l’elemento o la sezione in cui si può continuare.

Categorie operative

La home Azienda usa tre gruppi esclusivi. La home Cliente mostra invece soltanto “Da fare”, perché include esclusivamente azioni che il Cliente può svolgere ora: non forzare questi gruppi su ruoli o dati che non li supportano.

Richiede te
Solo attività che l’utente Azienda può svolgere adesso.
Attende cliente
Solo elementi fermi finché il Cliente non compie l’azione prevista.
Da verificare
Elementi che richiedono un controllo Azienda, come una dichiarazione di pagamento ricevuta.

La categoria descrive la responsabilità operativa. La priorità dell’item segnala invece attenzione o un blocco reale: sono due informazioni diverse e non devono essere dedotte l’una dall’altra.

Esempi canonici

Gli esempi riprendono situazioni presenti nelle work queue del Workspace. Le CTA sono specimen e non eseguono azioni.

Richiede un’azione

L’utente può aprire il contesto e intervenire subito.

Richiede attenzione

Conferma il riepilogo iniziale

Ristrutturazione cucina · L’Azienda ha pubblicato il riepilogo iniziale da controllare.

Stato
Conferma richiesta
Deve intervenire:
Tu

Attende l’altra parte

L’Azienda vede che l’invito è partito e che ora deve agire il Cliente.

Attendi l’accettazione del cliente

Bagno principale · L’invito è stato inviato e il Cliente deve accettarlo.

Stato
Invito inviato
Deve intervenire:
Cliente

Da verificare

La revisione riguarda ciò che il Cliente ha dichiarato, non una verifica automatica di Qoovex.

Richiede attenzione

Controlla la dichiarazione di pagamento

Ristrutturazione cucina · Acconto materiali: il Cliente ha inviato una dichiarazione da rivedere.

Stato
Revisione richiesta
Deve intervenire:
Azienda

Empty state

Conferma l’assenza di attività e indica che resta possibile consultare i lavori.

Al momento non è richiesto nessun tuo intervento. Puoi consultare i tuoi lavori.

Gerarchia delle azioni

Mantieni una CTA breve e specifica per item, allineata al deep link reale: “Apri proposta”, “Apri pagamento” o “Apri riepilogo”. Un item in attesa può offrire un collegamento per consultare il contesto, ma non deve simulare un’azione disponibile all’utente corrente.

Gli elementi chiusi o non più azionabili non competono con quelli aperti. Se restano consultabili, spostali nello storico o nella superficie di dettaglio appropriata.

Responsive e accessibilità

La coda deve conservare ordine, significato e azioni anche senza colore, hover o layout a più colonne.

  • Rendi la coda una lista e ogni gruppo una sezione con heading associato.
  • Mantieni titolo, contesto, stato e responsabile disponibili come testo: il colore non basta.
  • Usa un link per la CTA quando apre un’altra route o un’ancora e assicurati che il focus sia visibile.
  • Su viewport stretti impila contenuto e azione; non troncare label, nomi del lavoro o focus ring.
  • Mantieni l’ordine DOM uguale all’ordine di lettura: contenuto prima, azione dopo.

Errori da evitare

Una work queue non introduce regole: rende leggibili responsabilità e azioni già determinate dal prodotto.

  • Creare task da uno stato generico senza verificare che esista un’azione reale.
  • Inserire lo stesso elemento in più gruppi o confondere categoria operativa e priorità visuale.
  • Mostrare enum, ID, scadenze inventate, payload o nomi di proprietà backend.
  • Usare CTA generiche come “Gestisci” quando è possibile nominare l’oggetto da aprire.
  • Presentare Qoovex come certificatore, arbitro, garante o sistema che esegue pagamenti.