Siin postituses saate täpsemad näpunäited rühmatöödega alustamiseks. Annan siin ülevaate mõningatest meetoditest, mida ma ise olen erinevates projektides disaini faasis kasutanud. Ma tahan kohe alguses rõhutada, et disaini all ei mõtle me mitte seda, milline õpikeskkond “välja näeb”. Kasutajaliidese kujundus on ainult väike osa disainist. Tegelikkuses peaks disainiprotsess keskenduma hoopis teistele küsimustele: millist probleemi soovitakse lahendada, kes on sihtgrupp, kuidas loodavat lahendust kasutama hakatakse, millistest osadest loodav lahendus koosneb jne.
Probleem või tulevikuvisioon?
Oma rühmatöö jaoks sobiva idee leidmiseks on kaks võimalust. Üheks võimaluseks on leida mingi probleemsituatsioon õppetöös, mida aitaks lahendada mingi uue e-õppe või sotsiaalmeedia vahendi kasutuselevõtt või olemasolevate vahendite kasutamine uudsel viisil. Üheks võimaliku probleemi näiteks on see, kuidas anda avatud kursusel õppijatele privaatset tagasisidet.
Teine võimalus on teema valikul lähtuda mitte olemasolevast probleemist, vaid soovitavast tulevikuvisioonist. Millisena te kujutate ette õpikeskkondade kasutamist koolis, ülikoolis või elukestvas õppes 5 aasta pärast? 10 aasta pärast? Aeg-ajalt on väga edukaks kujunenud just sellised tooted, mis loovad täiesti uue tootekategooria, mille järele inimesed varem vajadust ei tundnud. Ühe sellise näitena võib välja tuua näiteks iPadi.
Personad
Kui esialgne idee on olemas, siis tuleks täpsustada loodava lahenduse sihtgruppi. Üheks disainimeetodiks, mida sihtgrupi määramisel kasutatakse, on personad — tulevaste tüüpkasutajate kirjeldused. Enamasti ei ole need tehtud mitte ühe konkreetse inimese kohta, vaid on koostatud terve grupi sarnaste vajadustega kasutajate põhjal. Tüüpiline persona sisaldab väljamõeldud isiku nime ja pilti, tema lühikirjeldust ning eesmärke seoses rakendusega. Personadel on mitu liiki. Igal rakendusel on üks peamine persona, kellele lisanduvad täiendavad personad. Üks persona eriliik on negatiivne persona — inimene, kellele rakendus ei ole suunatud. Personadele saab tugineda kõigis aruteludes kogu arendusprotsessi vältel.
Personad peaksid põhinema eelneval uuringul — kasutajate jälgimine nende töökeskkonnas (või muus keskkonnas, kuhu rakendus disainitakse), intervjuud kasutajatega jne. Oma projektidest oleme me kõige põhjalikumad personad koostanud LeContract projektis. Alljärgnevalt on lisatud näide selle projekti peamisest personast. Selle ja ülejäänud personade kirjeldused on LeContract ajaveebis.
[scribd id=32512916 key=key-2im70cbwif9rg17huw7s mode=list]
Selliste põhjalike personade koostamine ja läbi mõtlemine ei ole piiratud ajaressursside korral alati võimalik. Seetõttu olen ma sageli personade tüübid ja eesmärgid ideekaardil läbi mõelnud, kuid põhjaliku kirjeldusega persona lehti pole koostanud. Selle asemel olen ma lisanud paarilauselise persona lühikirjelduse stsenaariumisse, kus vastav persona süsteemi kasutab.
Stsenaariumid
Teiseks kontseptuaalse disaini meetodiks on stsenaariumide-põhine disain. Stsenaariumid on lühikesed lood sellest, kuidas tüüpkasutajad rakendust oma igapäevatöös kasutavad. Me olen seda meetodit kasutanud mitmetes oma tarkvaraprojektides. Tüüpiliselt kirjutame me 4…6 stsenaariumit, millest esimene kirjeldab esmatutvust rakendusega ning ülejäänud keskenduvad rakenduse peamistel funktsionaalsustel. Iga stsenaariumi lõpus on küsimused stsenaariumi kohta. Sageli algab stsenaarium kasutaja lühikirjeldusega. See on eriti oluline sel puhul, kui korralikke personasid tehtud ei ole. Kui korralikud personad on tehtud, siis on need samad personades kirjeldatud kasutajad ka stsenaariumides.
Mõned näidisstsenaariumid meie projektidest:
Need projektid on toodud ajalises järjestuses, nii et esimesed on teile tuntumad, aga viimaste stsenaariume pean ma paremini õnnestunuks.
Stsenaariumid toimivad väga hea kommunikatsioonivahendina arendajate ja teiste osapoolte vahel. Meie olukorras on selleks teiseks osapooleks sageli õpetajad ja tellijate-rahastajate esindajad. Stsenaariumid on nende jaoks lihtsad inimkeelsed tekstid, millesse nad saavad vabalt muudatusi teha. Kui näidata neile UML diagramme või muid tehnilisemaid tarkvaramodelleerimisvahendeid, siis poleks võimalik saada nii sisukat tagasisidet. Samuti sobivad stsenaariumid ka paljude muude lahenduste kirjeldamiseks väljapool tarkvaramaailma.
Mis saab edasi?
Järgmise nädala lõpus tuleb teine kontseptuaalse disaini meetodeid käsitlev postitus, milles selgitame, kuidas stsenaariumide juurest edasi liikuda.
Ootame järgmiseks reedeks esimesi stsenaariumeid koos küsimustega, et me jõuaks need enne laupäevast kontaktpäeva läbi vaadata ning tagasisidet anda.
