% $Id: luku4.tex,v 1.9 2003/05/03 01:21:11 iorinne Exp $ \section{Web-sivuston käyttöliittymän suunnitteluprosessi} \thispagestyle{plain} Käyttöliittymäsuunnittelu on oleellinen osa tietojärjestelmien ohjelmistotuotantoprosessia; Käyttöliittymä mahdollistaa käyttäjälle sovelluksen hyödyntämisen ylipäänsä, hyvä käyttöliittymä tekee hänen työstään tehokasta ja miellyttävää. Suunnittelun tavoitteena on saada aikaan ratkaisu, joka on kyseisen sovelluksen käyttäjien työtehtävien, "=ympäristön ja käyttäjän henkilökohtaisten ominaisuuuksien kannalta paras mahdollinen. Yleensä käyttöliittymää ei kuitenkaan voida suunnitella henkilökohtaisesti kaikkia sen käyttäjiä varten, joten on löydettävä ratkaisu, joka tukee käyttäjien keskuudessa tärkeimpiä ja yleisimpiä tavoitteita mahdollisimman hyvin. Tämä pätee niin web-sivustojen kuin interaktiivisten sovellustenkin käyttöliittymien suunnitteluun. Tämän tutkielman yhtenä tavoitteena oli pyrkiä edes yleisellä tasolla hahmottelemaan millainen voisi olla web-sivuston käyttöliittymän suunnitteluprosessi, jossa käytettään lähtökohtana tavoitepohjaisen käyttöliittymäsuunnittelun (goal-derived design~\cite[luku 3]{laakso-03}) menetelmiä. Prosessin kulkua ja soveltuvia menetelmiä päätettiin lähteä selvittämään kokeilemalla niitä käytännössä Helsingin yliopiston intranet-sivuston käyttöliittymän suunnittelutyössä. Ideana oli ensin selvittää käyttäjien keskeiset työnkulut ja tavoitteet haastattelujen avulla, minkä jälkeen käyttöliittymäsuunnittelussa keskityttäisiin tukemaan erityisesti näitä tavoitteita. Tässä luvussa raportoidaan tämän suunnittelutyön vaiheet ja kuvataan kussakin vaiheessa sovellettuja menetelmiä. \subsection{Prosessin tavoitteet ja vaiheet} Käyttöliittymäratkaisun suunnittelemisen ei tulisi olla mystinen työvaihe, joka vain tapahtuu, ilman että sen kulkua voidaan tarkasti kuvailla ja toistaa. Sen sijaan suunnitteluprosessin tulisi olla laadukas: hyvien käyttöliittymäratkaisujen suunnittelemiseksi pitäisi riittää, että tarpeeksi tietoa käyttäjien työnkuluista ja tavoitteista saanut ammattitaitoinen käyttöliittymäsuunnittelija tekee työn vaihe vaiheelta prosessin määrittelyssä asetettujen vaatimusten mukaisesti. Laadukkaan prosessin toimintaa voidaan arvioida ja kehittää, ja sen vaatima työmäärä ja saatavat tulokset ovat ennustettavissa. Web-sivustojen tapauksessa suunnitteluprosessin tuloksena tulisi olla sivusto, joka sisältää nimenomaan käyttäjilleen hyödyllistä tietoa ja palveluita (utility), ja joka ei aiheuta heille käytettävyysongelmia (usability). Tässä työssä tehdyn Helsingin yliopiston intranet-sivuston käyttöliittymäprototyypin suunnitteluprosessin vaiheet on esitetty kuvassa~\ref{kuva:oma_prosessi}. Työ alkoi sivuston käyttäjäryhmien selvittämisellä. Koska koko yliopiston sivuston uudelleensuunnittelu olisi ollut liian suuri tehtävä käsiteltäväksi tässä työssä, valittiin kohderyhmäksi yliopistolla työskentelevät tutkijat, joiden arveltiin päivittäisessä työssään tarvitsevan paljon eri web-palveluja ja siten hyötyvän merkittävästi heidän tarpeisiinsa suunnitellusta kokoavasta web-sivustosta. Oletuksena oli, että selvittämällä yhden käyttäjäryhmän tavoitteita ja suunnittelemalla niiden perusteella osa yliopiston sisäisen web-sivuston käyttöliittymästä, saadaan samalla arvokasta tietoa ja kokemusta käyttäjien tavoitteista lähtevän web-käyttöliittymän suunnittelusta myös muiden yliopiston käyttäjäryhmien tarpeisiin. \begin{figure}[!bt] \begin{center} \includegraphics[width=0.8\textwidth]{kuvat/oma_prosessi} \end{center} \caption{Helsingin yliopiston intranet-käyttöliittymäprototyypin suunnitteluprosessin vaiheet.} \label{kuva:oma_prosessi} \end{figure} Kohderyhmän valinnan jälkeen selvitettiin tutkijoiden web-sivustojen käyttöön liittyviä työnkulkuja ja tavoitteita haastattelujen avulla. Haastattelujen tuloksena saadut käyttäjien tavoitteet raportoitiin tavoitepohjaisina käyttötapauksina~\cite{laakso-03}, jotka ryhmiteltiin yhteen sen perusteella, mihin käyttäjien työnkuvan osa-alueeseen ne kuuluivat. Tavoitteiden selvittämisen jälkeen ryhdyttiin suunnittelemaan tutkijoiden käyttöön tarkoitetun intranet-käyttöliittymän prototyyppiä lähtien tarvittavan tietosisällön jäsentämisestä ja edeten navigointijärjestelmien ja sivustoon integroitavien upotettujen sovellusten suunnitteluun. \subsection{Käyttäjien tavoitteiden selvittäminen} Ensisijaisesti interaktiivisten sovellusten suunnitteluun kehitetyssä GUIDe-pro\-jek\-ti\-mal\-lissa sovelluksen käyttöliittymäratkaisu suunnitellaan heti projektin alussa käyttäjien keskeisten työnkulkujen ja niistä johdettujen tavoitepohjaisten käyttötapausten avulla~\cite[s.~7]{laakso-03}. Näin suunniteltuja ratkaisuja voidaan testata mahdollisimman todenmukaisissa käyttötapauksissa ja tarvittaessa tehdä niihin suuriakin muutoksia nopeasti ennen kuin järjestelmän toteutusratkaisuja on kiinnitetty. GUIDe-mallin tapaan työssä otettiin suunnitteluprosessin lähtökohdaksi tavoitepohjainen käyttöliittymäsuunnittelumenetelmä, jonka ensimmäisenä vaiheena on käyttäjien tavoitteiden selvittäminen. Tavoitteiden selvittämien aloitettiin haastattelemalla Helsingin yliopiston tutkijoita toukokuussa 2002. Haastattelujen avulla selvitettiin käyttäjien jokapäiväiseen työskentelyyn liittyviä tavoitteita ja kirjoitettiin niiden perusteella tavoitepohjaisia käyttötapauskuvauksia web-sivuston suunnittelutyötä varten. Alkuperäisten neljän haastattelun tuloksia päätettiin vielä täydentää uudella haastattelukierroksella syys-loka\-kuussa 2002 sen jälkeen, kun sivuston tietosisällön jäsentäminen selvitettyjen käyttötapausten avulla oli osoittautunut vaikeaksi tehtäväksi. Esimerkkinä tavoitepohjaisesta käyttötapauskuvauksesta on kuvassa~\ref{kuva:walzu_käyttötapaus} esitetty fysikaalisten tieteiden laitoksella Kiihdytinlaboratoriossa työskentelevän tutkijan, Walterin tutkimustyöhän liittyvä käyttötapaus. Tavoiteosassa on kuvattu keskeinen päämäärä, jonka käyttäjä pyrkii saavuttamaan. Tilatietoina on lueteltu haastattelun avulla selvitettyyn todelliseen tilanteeseen liittyviä faktatietoja. Näitä tietoja voidaan suoraan käyttää realistisena esimerkkitietona käyttöliittymäratkaisua suunniteltaessa ja arvioitaessa. Muuttamalla tilatietoja saadaan saman käyttötapauksen variaatioita. Tilatietojen varioinnin ei tulisi vaikuttaa suunniteltavaan käyttöliittymäratkaisuun, sillä käyttäjän varsinainen tavoite pysyy muuttumattomana. \begin{figure}[p] \renewcommand{\baselinestretch}{1.0} \large \normalsize %\begin{changemargin}{-3cm}{-2cm} \begin{boxedminipage}[l]{0.9\textwidth} \textbf{Fuusiotutkijoiden tapaaminen ja uuden tiedon saaminen} \begin{description} \item[Tavoite] Walter pyrkii selvittämään timanttikalvojen käyttäytymistä fuusioreaktorin sisällä vallitsevissa olosuhteissa, jotta vähän saastuttava ja tehokas voimanlähde joskus saataisiin kehitettyä teknisesti käyttökelpoiseen muotoon. Päästäkseen eteenpäin tutkimuksessaan ja välttääkseen tutkimasta jo selvitettyjä asioita, hän tarvitsee tietoa muiden saman alan tutkijoiden tekeillä olevasta tutkimuksesta ja alustavista tuloksista. \item[Tilatiedot] \begin{itemize} \item[] \item On marraskuu 2001. \item Walter tekee tutkimusta timanttikalvojen käytöstä fuusioreaktorissa. \item Hän pyrkii tutustumaan alan tutkijoihin, mahdollisuuksien mukaan henkilökohtaisesti, sillä suhteista on apua tutkimusongelmien ratkaisemisessa ja tulevan post~doc "=tutkimusryhmän löytämisessä. \item Työtoveri Emppu Salonen on suositellut PSI-konferenssia oman aiemman kokemuksensa perusteella. \item Seuraava PSI-konferenssi järjestetään Japanissa 27.-31.5.2002. Abstraktien deadline on 3.12.2001 ja ilmoittautumismaksun maksamisen 29.3.2002. \item Kiihdytinlaboratoriosta on lähdössä PSI-konferenssiin ainakin 2 muutakin tutkijaa. \item Vuoden aikana ehtii valmistautua ja osallistua 1-2 konferenssiin. \item Fysiikan laitoksen tutkijat joutuvat useimmiten hankkimaan rahoituksen konferenssimatkoihin itse, joskus laitos päättää maksaa matkan. \item Walter tietää, että useat säätiöt myöntävät tutkijoille apurahoja konferenssimatkoja varten. \end{itemize} \end{description} \end{boxedminipage} %\end{changemargin} \caption{Esimerkki tutkijan tavoitepohjaisesta käyttötapauksesta.} \label{kuva:walzu_käyttötapaus} \renewcommand{\baselinestretch}{1.21} \large \normalsize \end{figure} Periaatteessa tavoitepohjaisen suunnittelumenetelmän avulla pitäisi voida saada selville kaikki tieto, jota käyttäjät sivustolta tarvitsevat. Suuren organisaation sivustolla on kuitenkin niin paljon erilaisia käyttäjiä, joilla on lukuisia erilaisia tavoitteita, että sivuston tietosisällön rakentaminen puhtaalta pöydältä pelkästään muutamassa haastattelussa selvinneiden tavoitteiden toteuttamiseen tähdäten ei ole mahdollista. Eräs ratkaisutapa tähän ongelmaan näyttäisi olevan ottaa tietosisällön pohjaksi sivuston edellisessä versiossa ollut materiaali ja pyrkiä selvittämään, kuka mitäkin sivuston tietoa tarvitsee ja miksi~\cite{coyne-01,newman-00}. Laatimalla osan käyttäjien haastattelujen kysymyksistä kartoittamaan sivuston nykyisen tietosisällön käyttämiseen liittyviä työnkulkuja ja tavoitteita, voidaan päästä käsiksi myös sellaisiin käyttäjien tarpeisiin, joihin haastatteluissa ei välttämättä muuten osuttaisi. Tällaisella tietopohjaisella lähestymistavalla ei sen sijaan voida löytää sellaisia käyttäjien tavoitteita, joita olemassaolevalla sivustolla ei lainkaan tueta. Niinpä haastatteluissa tulee myös pyrkiä selvittämään sellaisia työnkulkuja ja tavoitteita, joiden toteuttamiseen ei nykyisin liity verkkopalvelujen käyttämistä. Tärkeimpien tällaisten tavoitteiden oletettiin tässä työssä tulevan esille jo muutaman käyttäjähaastattelun tuloksena. Tutkijoiden haastattelujen perusteella kirjoitetut tavoitepohjaiset käyttötapauskuvaukset jaettiin tutkimustyön eri osa-alueiden perusteella muutamaan ryhmään, joiden sisältä pyrittiin etsimään mahdollisimman hyvin koko ryhmän tavoitteita edustava käyttötapaus tai muutaman yhteen liittyvän käyttötapauksen ketju. Näitä käyttäjien keskeisiä korkean tason työtehtäviä edustavia käyttötapauksia käytettiin suunnittelun lähtökohtana, jotta käyttöliittymäratkaisusta saataisiin mahdollisimman suoraviivaisesti heidän tavoitteitaan tukeva. \subsection{Tietosisällön valinta ja jäsentäminen} Web-sivustoa suunniteltaessa käyttäjien tavoitteet on selvitettävä etukäteen, ja tuettava niistä ainakin keskeisimpien toteuttamista hyvin, jotta tiedonhaku olisi yksin toimivalle käyttäjälle mahdollisimman helppoa. Web-sivuston käyttäjällä ei useimmiten ole välittömästi saatavilla eri tiedonorganisointitavat hyvin tuntevaa asiantuntijaa, joka voisi neuvoa tiedon etsinnässä. Esimerkiksi kirjastossa asioitaessa saatavilla olevan materiaalin ja käytetyt organisointimenetelmät hyvin tunteva kirjastonhoitaja pyrkii selvittämään apua pyytävän käyttäjän tietotarpeet ja tavoitteen tarkentavien kysymysten avulla (ns. reference interview, \cite[s.~121]{rosenfeld-98}). Web-sivustojen käyttäjä joutuu selviämään tiedonhakutehtävästä itsenäisesti, mikä korostaa tietosisällön käyttäjien tavoitteita vastaavan jäsentämisen tärkeyttä. Helsingin yliopiston web-sivuston tietosisällön valinta- ja jäsentämisvaiheen syötteenä käytettiin käyttötapausten lisäksi yliopiston Portaalityöryhmän laatimia alustavia Helsingin yliopiston sisäisen verkkopalvelukokonaisuuden sisältökokonaisuuksia~\cite[s.~33--37]{portaali-02} sekä haastateltujen tutkijoiden omien laitosten, laboratorioiden ja tutkimusryhmien nykyisten julkisten ja sisäisten web-sivustojen sisältämiä tietoja. Saadut tiedot pyrittiin ryhmittelemään hierarkkiseksi rakenteeksi siten, että polut aloitussivulta käyttäjien keskeisten tavoitteiden toteuttamiseen liittyviin tietoihin tulisivat mahdollisimman lyhyiksi ja niiden löytäminen mahdollisimman intuitiiviseksi. Välineenä käytettiin paperille hahmoteltua tietokokonaisuuksien nimistä koostettua puumaista tietohierarkiaa, jonka avulla simuloitiin valintoja, joita käyttäjät joutuisivat tekemään kussakin käyttötapauskuvausten esittämässä käyttötilanteessa. Tarvittavien tietojen löytämisen intuitiivisuutta pyrittiin parantamaan valitsemalla tietosisältökokonaisuuksille sellaisia nimiä, joita käyttäjät itse niistä haastattelujen perusteella käyttävät. Luokittelua pyrittiin korjaamaan tai kokonaisuuksia nimiä muuttamaan, mikäli valinta kahden tai useamman hierarkian haaran välillä arvioitiin joissakin käyttötapauksissa todennäköisesti olevan käyttäjälle vaikea tehdä. \subsection{Navigointiratkaisujen suunnittelu} Helsingin yliopiston web-sivuston nykyisessä käyttöliittymäratkaisussa on useita navigointiin liittyviä ongelmia, joita suunnitellussa intranet-käyttöliittymässä pyrittiin välttämään. Uuden navigointijärjestelmän suunnittelussa arvioitiin erilaisia web-si\-vus\-toil\-la käytettyjä navigointijärjestelmiä, tunnettuja hierarkkisen tiedon visualisointimenetelmiä ja web-sivustojen suunnittelussa hyviksi havaittuja suunnittelumalleja (user interface design patterns) sen perusteella, miten hyvin ne tukivat selvitettyjen käyttötapausten tiedonetsintätehtäviä. Navigointipuiden avulla tiedettiin voitavan hyvin visualisoida sivuston laajaa hierarkkista tietosisältöä, joten suunnittelun lähtökohdaksi otettiin jonkinlainen navigointipuun käyttöön perustuva ratkaisu. Valittuun navigointiratkaisuun päädyttiin vertailemalla erilaisten navigointipuutyyppien soveltuvuutta tutkijoiden verkkopalvelua varten suunnitellun tietohierarkian visualisointiin ja tiedon etsintään. Suunnittelussa pyrittiin myös ottamaan huomioon navigointiratkaisun soveltuvuus eri käyttäjien personoinnin ja kustoimoinnin seurauksena erilaisten ja muuttuvien tietosisältöjen esittämiseen. \subsection{Upotettujen sovellusten suunnittelu} Perinteisesti web-sivustot muodostuvat pääosin staattisesta teksti- ja kuvasisällöstä, jota päivitetään melko harvoin. Tällaisen staattisen tietosisällön avulla käyttäjä ei kuitenkaan saa tavoitteitaan toteutetuksi, vaikka asiasisältö sinänsä olisikin hyvin suunniteltu. Esimerkiksi yliopiston web-sivustolla olevat ohjeet ilmoittautumisesta läsnäolevaksi opiskelijaksi ovat kyllä hyödyllisiä opiskelijalle, joka ei ilmoittautumismenettelyä vielä tunne, mutta parempi ratkaisu olisi tarjota pelkkien ohjeiden sijaan opiskelijalle mahdollisuus itse ilmoittautumiseen sivustolle upotetun sovelluksen kautta. Upotetun sovellusten avulla voidaan myös liittää sivustoon tiedonhakukäyttöliittymiä erilaisiin varsinaisen sivuston ulkopuolisiin tietovarastoihin, kuten kirjastotietokantoihin tai dokumenttiarkistoihin, jolloin niitä varten ei tarvitse asentaa käyttäjän koneelle erillisiä sovelluksia, vaan ne ovat kertakirjautumisen periaatteella käytettävissä siellä missä intranet-sivustokin on. Haittapuolena upotetuissa sovelluksissa on usein niiden hitaus, epäluotettavuus ja toteutusvälineestä riippuen mahdollisesti käytettävissä olevien käyttöliittymäkomponenttien puutteellisuus verrattuna selaimesta riippumatta toimiviin interaktiivisiin sovelluksiin. Esimerkiksi HTML-lomakkeilla on mahdollista toteuttaa vain melko kömpelöjä käyttöliittymäratkaisuja verrattuna lähes kaikkiin graafisten sovellusten tekoon tarkoitettuihin ohjelmointikieliin. Lisäksi ongelmia aiheuttavat eri selainten toisistaan poikkeavat tavat tulkita HTML-koodia, joka on alunperin tarkoitettu vain tietosisällön, ei graafisen käyttöliittymän kuvailuun. HTML-kielen rajoituksista päästään eroon käyttämällä käyttöliittymän esittämiseen palvelimelta ladattavia sovelluskomponentteja, kuten Java-appletteja. Tällöin on kuitenkin otettava huomioon, että kaikki selaimet eivät osaa käsitellä näitä komponentteja, mikä voi estää käyttäjää käyttämästä kyseistä palvelua. Palvelimelta ladattavan sovelluksen siirtäminen käyttäjän koneella vie myös jonkin verran aikaa käytössä olevasta verkkoyhteydestä ja ja sovelluksen koosta riippuen, jolloin sen käynnistymisaika muodostuu helposti häiritsevän pitkäksi verrattuna paikallisesti asennettuun sovellukseen. Web-sivuston suunnitteluprosessissa on punnittava upotettujen sovellusten hyötyjä ja haittoja sivuston käyttäjien tavoitteiden toteuttamisen kannalta ja päätettävä sen perusteella kuinka paljon ja missä tapauksissa niitä on järkevää hyödyntää. Helsingin yliopiston sisäisessä intranet-verkossa käyttäjien laitteistot ja selainkanta on julkisen web-sivuston käyttäjiin verrattuna yhtenäisempi, joten upotettujen sovellusten suunnittelu ja toteuttaminen siten, että ne toimivat oikein kaikkien niitä tarvitsevien käyttäjien koneissa, on helpompaa. Verkkoyhteydet ovat yliopiston sisällä myös tyypillisesti nopeita, mikä vähentää upotettujen sovellusten lataamiseen kuluvaa aikaa. Tällaisessa ympäristössä palvelimelta ladattavien sovelluskomponenttien ja minimi-HTML~-standardit ylittävien selainominaisuuksien, kuten erilaisten skriptikielien, käyttäminen kehittyneempien web-käyttöliittymien rakentamiseksi on perustellumpaa kuin julkisilla sivustoilla. Suunnitellussa tutkijoiden intranet-sivuston käyttöliittymässä kiinnitettiin huomiota varsinaisen web-sivuston staattisten tietojen ja upotettujen sovellusten yhteiskäyttöön käyttötapausskenaarioden toteuttamisessa. Tavoitteena oli saada aikaan integroitu palvelukokonaisuus, joka tukee mahdollisimman hyvin käyttäjien kokonaisia tavoitepohjaisia käyttötapauksia. Upotettujen sovellusten suunnitteluvaiheessa piirrettiin ja tulostettiin pohjakuvia sivuston käyttöliittymästä navigointipuineen ja niiden päälle piirrettiin käsin hahmotelmia upotettujen sovellusten käyttöliittymistä käyttötapauskuvausten mukaisissa käyttötilanteissa. Käyttöliittymäkuvien piirtämisessä käytettiin mahdollisimman paljon käyttötapauskuvauksiin sisältyvää oikeaa esimerkkidataa, kuten todellisia laboratorioiden, projektien, ja tieteellisten konferenssien nimiä sekä esimerkiksi tutkijoiden käyttämiä viittaustietokantoja. Näin pyrittiin suunnittelemaan käyttöliittymäratkaisu soveltumaan mahdollisimman hyvin todelliseen käyttötarkoitukseensa. \subsection{Käyttöliittymäratkaisun arviointi} Käyttöliittymäsuunnitelman arviointi ja testaus on tärkeä osa suunnitteluprosessia, sillä suunnittelija ei itse välttämättä huomaa mahdollisia ongelmia, kuten käyttäjän kannalta epäintuitiivisia tai turhan monimutkaisia ratkaisuja. Usein suunnittelutyöhön osallistumattoman käyttöliittymäsuunnittelijan on ratkaisujen suunnittelijaa helpompi havaita nämä ongelmat. Lisäksi käyttöliittymäratkaisujen toimivuus olisi vielä hyvä lopuksi testata järjestelmän loppukäyttäjien avulla pidettävissä käytettävyystesteissä. Tällöin voitaisiin vielä havaitsemaan suunnitellun ratkaisun käyttäjille heidän todellisissa käyttötilanteissaan tuottamia ongelmatilanteita, joihin ei asiantuntija-arvioinnissa ole osattu varautua. Tässä tutkielmassa esitettyä käyttöliittymäratkaisua suunniteltaessa on pyritty välttämään luvussa~\ref{luku:ongelmat} esitetyt Helsingin yliopiston nykyisen web-sivuston käyttöliittymän ongelmat. Käytettävyystestaus oli jo projektin suunnitteluvaiheessa rajattu tämän työn ulkopuolelle, sillä sen järjestämisen vaatima työmäärä arvioitiin työn kokoon nähden liian suureksi. Tutkijoiden intranet-protyyppi~-projektin suunnittelussa olisi kuitenkin muilta osin pitänyt kiinnittää työn tulosten arviointiin enemmän huomiota. Käyttöliittymäratkaisusta piirrettyä käyttötapauksittain etenevää kuvasarjaa käsiteltiin yhdessä arviointipalaverissa projektin ulkopuolisen käyttöliittymäsuunnittelijan, Antti Latva-Koiviston kanssa elokuussa 2002, mutta palaverin tulokset jäivät tuolloin melko laihoiksi. Jälkikäteen voidaan sanoa, että käyttöliittymäratkaisun ongelmien löytämiseksi olisi tuolloin pitänyt järjestää huolellisesti suunniteltu asiantuntija-arvionti. Arviointipalaveriin oli valmistauduttu piirtämällä sivuston suunnitellusta käyttöliittymäratkaisusta muutamaa keskeistä käyttötapauspohjaista käyttöskenaariota kuvaavat kuvasarjat, joiden avulla suunniteltua ratkaisua tarkasteltiin. Esille tulleet hyvät ja huonot ratkaisut olisi kuitenkin pitänyt raportoida muutamaa paperille hahmoteltua pikaista muistiinpanoa tarkemmin. Näin arvioinnista olisi jäänyt jokin konkreettinen dokumentti, jonka perusteella ratkaisun ongelmat olisi helpommin voitu myöhemmin korjata ja arvioida ratkaisua uudelleen tehtyjen muutosten osalta. Lisäksi työn tuloksia olisi todennäköisesti saatu parannettua pohtimalla etukäteen ratkaisun mahdollisia ongelmakohtia, joita palaverissa olisi erityisesti pyritty ratkaisemaan.