Uno dei widget del Guiwiki di Poste Italiane
Stamattina ho sorriso leggendo l’articolo di Peter Gremett chiamato Using Wikis to Document UI Specifications nel quale l’autore elenca i benefici che ne verrebbero ad una grande azienda se utilizzasse un sistema di wiki per documentare gli standard relativi alle interfacce utente (o user interface che dir si voglia).
Ho sorriso perché è una cosa che con il mio gruppo di lavoro abbiamo fatto lo scorso anno in Poste Italiane pubblicando un wiki chiamato “Guiwiki” nel quale sono riportati gli standard grafici (codici colore, tipo e dimensione dei font, formattazione tabelle….) da seguire nel momento in cui si vuole sviluppare un applicazione per la intranet aziendale.
Il Guiwiki riporta tutti gli standard definiti e mette a disposizione gli strumenti di collaboration tipici dei wiki per mettere a confronto sviluppatori e gruppo di lavoro della Comunicazione Interna che si occupa di definire gli standard delle interfacce grafiche.
Ogni volta che vi è un dubbio o ci si accorge che non è stato definito uno standard grafico per una determinata funzionalità, grazie agli strumenti di collaboration, ci si confronta ed alla fine si definisce lo standard aggiornando contestualmente il manuale.
In una grande azienda come Poste Italiane, che sviluppa moltissime applicazioni per uso interno ogni anno, rivolgendosi spesso a società esterne e sviluppatori non a conoscenza dei nostri standard, l’adozione di questo strumento ha portato molti benefici come la sensibile riduzione degli interventi di correzione di interfacce grafiche realizzate fuori standard e la conseguente riduzione di tempi e costo di sviluppo.
L’articolo di Peter Gremett riporta quelli che sono i principali benefinci provenienti dall’utilizzo di un wiki per documentare gli standard delle interfacce grafiche.
Collaboration
Collaboration is the single best advantage of a wiki spec over a traditional one. The supposition of a wiki is that there are many authors and contributors to the document, and therefore, you have the right environment for collaboration. This is a huge advantage for product specifications. As the interaction designer you don’t have to sit in a cube by yourself and define everything on your own. It’s fine not knowing all the answers and you can rely on your team to help fill in the blanks.
Team members can add clarifications, details, or make edits to content. Oftentimes, the details and clarifications build upon one another to complete the document. For example, if the designer has specified the layout and behavior for a button, the tech writer can add in the rollover text without disturbing the designer or the flow of the project process. To follow the example further, the tech writer can then add the help content to the wiki, allowing the engineer to upload the information onto a server and post the URL. The transparency and collaboration are quite amazing. Team members are able to get the information they need to perform their jobs and help the project along.
Speed
Speed is a major benefit of wiki specs. This is also why it’s a good match for agile projects. Speed comes in two forms: writing and consumption. It’s easy to add content because of the WYSWIG interface. As you begin writing content, it can be instantly viewed by team members. I have found that the sooner you post sketches and thoughts the better. It gets the whole team collaborating and they can offer feedback immediately.
Flexibility
A wiki spec is extremely flexible. This characteristic allows you to morph its structure and organization as the project evolves, reflecting the nature of agile processes. The team is able to keep up with the changes that occur in an agile project because all edits can be instantly viewed. Additionally, if anyone wants to be informed of the most recent wiki changes, an email notification system can be set up by any team member.
Reversible
In the event that a change was accidental or a major disagreement arises, the wiki spec can be reverted to its previous version. This does not happen very often, but when it does, it’s a real life saver.
Mi sento allineato con le sue considerazioni ma vorrei aggiungere anche il fattore Engagement perchè avere a che fare con uno strumento che funziona e che fa finalmente collaborare le persone riducendo il lavoro di chi (il mio gruppo di lavoro) deve valutare se un applicazione è in linea o meno con gli standard grafici e di chi sviluppa l’applicazione mette buonumore, voglia di lavorare e fare bene.
Articoli (RSS)