Hoe maak je een simpel functioneel ontwerp

[zrski]

Ik ben momenteel voor een website een functioneel ontwerp aan het maken. Bestaan er simpele methodes om functioneel ontwerp in elkaar te draaien of te testen.

 

Ik probeer iedere keer te denken:

Ik ben de gebruiker, ik ga dit gebruiken... Welke stappen doorloop ik?

 

Zijn er beproefde simpele checklist om het eindresultaat tegenaan te houden?

[Persoon]

Laat je (schoon)moeder het proberen ;D Als die het begrijpt dan zit je goed ::)

[zrski]

Mijn oma of schoonmoeder zal het wel mooi vinden, maar is het ook dekkend voor een software ontwikkelaar? Met andere woorden, is er een techniek om gaten in je functioneel ontwerp te ontdekken?

 

(ik begin met steeds meer te realiseren dat dit mogelijk een domme vraag is :D)

[Persoon]

Allereerst bestaan domme vragen niet, dus dat valt wel mee. Mijn antwoord was gewoon een beetje melig ;D

 

Het functioneel ontwerp bestaat niet. Wat voor de één goed bruikbaar is, zal de andere niet begrijpen. Mix dat met de verschillende (besturings)systemen, technische eisen en gebruikte beeldschermen en je krijgt verschillende eindresultaten.

 

Waar ik op zou letten is de doelgroep. Dus niet het pad van jezelf volgen, maar van de doepgroep. Waarom komen ze op je site, wat voor informatie verwachten ze en waar zouden ze gaan zoeken? Als je dat pad goed in beeld heb, dan komt er een functionele site uit. Athans... voor die doelgroep, want andere mensen zullen het wederom niet begrijpen.

 

Hieruit kan ik afleiden dat het niet mogelijk is om er een standaard checklist van te maken. In Nederland willen we altijd alles in hokjes stoppen, maar soms kan dat niet. Ook in dit geval zal het moeilijk worden.

 

Een leuk voorbeeld. Op de Haagse Hogeschool kreeg ik les van een man die tegen het gebruik van frames was. Want daar kon je weleens via een zoekmachine inkomen en daardoor zag je de halve pagina alleen. Of je print alleen de inhoud van het frame, enz. De docent die ons de programmeertaal leerde wilde alles in... jawel... frames hebben, want dat is makkelijker. Functioneel ontwerp, uit wel oogpunt? De gebruiker, de ontwerper, de programmeur? Welke doelgroep?

 

Persoon

[R.I.P. - Benm]

Fuctioneel ontwerp is natuurlijk een vak op zich, en het ultime FO valt niet te maken. Wat vaak een handige aanpak is denken in schermen. Je schetst de beginpagina, en werkt dan vanaf daar door alle knoppen, velden en schermen heen.

 

Zaken als wel/geen frames etc. maken eerder uit van een technisch ontwerp, en zijn geen zaken om je bij een FO druk over te maken lijkt me.

 

[zrski]

Ik heb ook maar besloten om de techniek helemaal terzijde te laten, gewoon ontworpen zoals ik het zou willen hebben.

 

Eens kijken of daar iets van gemaakt kan worden :)

[Alef Arendsen]

Tjsa, kom ik weer met m'n software-ontwikkelingsperspectief ;D. Functionele en technische ontwerpen voeren wij altijd uit met behulp van UML en een of ander ontwerp proces erbovenop. Dit is echter niet altijd geschikt voor een website.

 

Dit soort systemen gaan uit van usecases. Een voorbeeld van een usecase: registreren. Nog een usecase: koop een product. Heb je een website die alleen in informatie-behoefte voorziet, dan ben je natuurlijk gauw uitgepraat, de enige usecase is: 'vraag informatie op'.

 

Eén mogelijkheid is om na het construeren van al deze usecases (rudimentaire acties dus eigenlijk) is om deze uit te schrijven naar zogenaamde scenario's. Wat doet een gebruik precies om zijn aankoop een website te doen. Dit kan heel grof: selecteer product --> vul betalingsgegevens is --> aankoop verricht. Het kan echter ook nog veel gedetailleerder (klik hier, klik daar, klik zus, vul creditcard nummer in (<4cijfers>.<4cijfers>.<4cijfers> als pattern vermelden), vul creditcard holder in (), etcetera...

 

De combinatie tussen usecases en (in meer of mindere mate gedetailleerde) scenario's vind ik altijd een prima uitgangspunt om vanuit te gaan bouwen. De site designer kan vanuit deze gegevens bekijken welke pagina's hij nodig heeft en de scenario's verder uitwerken. Ingeval er een systeem achter moet dan kan de ontwikkelaar met die usecases ook aan de gang...

 

De usecases geven je wel wat inzicht in welke functionaliteiten je aanbiedt en kunnen je dus misschien een klein beetje helpen bij het kijken of je niks over het hoofd hebt gezien...

 

Resources:

 

http://www.rational.com/uml/index.jsp

http://www.omg.org/uml/

http://www.uml.org/

 

[Celletje1974]

Heb je een website die alleen in informatie-behoefte voorziet, dan ben je natuurlijk gauw uitgepraat, de enige usecase is: 'vraag informatie op'.

 

Mooi antwoord Aleph! Dit was ook een punt waar ik nog een beetje mee aan het stoeien ben... Maar je kunt toch wel meerdere usecases bedenken voor een informerende site?

 

Ik denk aan:

- bezoeker zoekt informatie voor oriëntatie

- bezoeker zoekt nieuwste informatie

- bezoeker zoekt antwoord op concrete vraag

 

of zit ik dan alweer in het scenario gebied?

[Alef Arendsen]

of zit ik dan alweer in het scenario gebied?

Ik moet eerlijk zeggen dat ik me hier niet echt een mening over kan vormen, heb usecases dan ook nog nooit losgelaten op informerende websites... Zou wel eens interessant kunnen zijn...

 

sorry dus, geen ervaring ;-)

[Annedien Hoen]

User experience design, information architecture, usability, GUI ergonomics, interaction design... je zou haast denken dat het maken van een functioneel ontwerp een 'geleerd' klusje is ;D

 

Beproefd en simpel, Zrski gaat voor het maximale!

 

Ik geloof dat je bekend bent met mindmapping, dus hoe ik het zou aanpakken zou misschien ook voor jou kunnen werken. (Ik zou n.l een aantal mindmaps gaan maken)

Een standaard recept is er niet echt. Er zijn wel guru's zoals (even diep ademhalen, ik ga het zeggen...) Jacob Nielsen (bluh! dat was moeilijk!!! voor een internetcreatief!) maar die vind ik te kort door de bocht, en dan heb je ook nog de internet-martin-gausen die vinden dat ze alles weten van websites maar veel te veel in de theorie rondhuppelen...enzovoorts. Ik denk dat zelf grondig onderzoek doen en de materie leren kennen nu iets meer tijd kost, maar uiteindelijk je hele concept véél beter maakt!

 

Mindmap pointers:

 

1. In kaart brengen van de dimensies die een rol spelen in het ontwikkelen van je site

B.v:

-belangen (jouw partij, de koper, de tussenpersoon, de reseller)

-tijd (doorlooptijd van aanvragen, verversen van advertenties, updaten van de database, aandacht van bezoekers vasthouden, laadtijd, levertijd, komkommertijd)

-interactie (op welke punten, op wat voor manier, anonimiteit opgeven, aanvragen, dingen opvragen, community, e-mail, klachtenafhandeling, service)

-identity (uitstraling van de site, communicatie, taalgebruik, visuals)

-omvang (hoe groot zijn de 'chunks' informatie, hoe vinden mensen hun informatie, hoeveel informatie moet er ontsloten worden, geef je een groot menu met veel opties of een kleiner menu met veel doorkliks, hoe gemakkelijk is het om te verdwalen, wat voor indruk moet het geven (groot en graven, of overzichtelijk?)

 

In kaart brengen van de randvoorwaarden

b.v

-hosting (mirrorsites, backups, accountability, traffic)

-partijen (welke partijen moeten van de partij zijn, wiens medewerking nodig)

-middelen (hoeveel geld, tijd, know-how inkopen om X-resultaat te bereiken, revenuevoorwaarden)

 

In kaart brengen van de klant

-koopgedrag

-interessegebied

-bestedingsbedrag

-attention span (80% van de bezoekers van e-commerce sites haken af en laten hun karretje midden in je e-winkel achter)

-op zoek naar... (informatie, objecten, aanbiedingen, prijzen, overzichten)

 

Enfin, het is op zich niet bedoeld om uitputtend te zijn-

maar ik denk dat als je het hebt over 'functioneel ontwerp' er geen easy way out is als je dit écht goed wil aanpakken. Als je al die dingen hebt bedacht is een FO (in de vorm van b.v. een flowchart, mockup ontwerp of prototype) zet, ben ik er van overtuigd dat die goed in elkaar zit en niet rammelt ;D

 

Ik denk dat jij wel weet hoe moeilijk het is iets simpels te maken :P

 

Succes!

Annedien

 

 

http://www-106.ibm.com/developerworks/web/

[Alef Arendsen]

Ha Annedien, goed dat je deze thread met je reactie even activeert, want ik kwam laatst het aangehangen documentje tegen over Goal-Directed Design (GDD) wat blijkbaar door veel interaction designers gebruikt wordt en RUP (Rational Unified Process), een beproefde methode voor software ontwikkeling (hoewel ik van RUP niet zo gecharmeerd ben, gezien de mate waarin het rigide is).

 

Als ik zoek op Google op goal-directed design krijg ik nog wel wat andere interessante links terug, misschien leuk...

 

Een van die links:

http://www.campagne.com/gdd_print.html

RUP__Goal-Directed_Design.doc

[jwzdocent]

Een voorbeeld:

 

 

 

2 Huidige situatie

 

IToen hebben een nieuwe locatie in Utrecht, de helpdesk is niet bereikbaar de werkplekken zijn niet geintregeerd de lokaties zijn niet aan elkaar gekoppeld.

De ingelogde gebruikers worden ook niet geregistreerd en welke documenten ze gebruiken.

Het netwerk is niet snel en stabiel genoeg, de computers hebben de commando “Run” nog in het startmenu.

 

3 Nieuw situatie

3.1 Gebruikerseisen

IToen willen dat:

- De netwerken van de drie andere locaties koppelen aan elkaar.

- De helpdesk bereikbaar maken voor alle drie locaties.

- De werkplekken geintregeerd worden in het bestaande netwerk.

- Snelle data overdracht lijnen implementeren.

- Toegang tot gedeelde bestanden voor het personeel.

- De Run afschermen uit het startmenu zodat deze niet toegankelijk is voor de gebruikers.

 

3.2 Kernbehoefte

De kernbehoefte van de opdrachtgever die ik uit conclusies heb getrokken is: Een gekoppelde snelle stabiele netwerk met een centrale gebruiker ondersteuning waarin gebruikers zonder problemen kunnen werken.

 

3.3 Keuze

Er zijn een paar keuzes gemaakt gebruikt kunnen worden als oplossingen deze zijn:

 

Koppelen van de netwerken:

- Een site on site netwerk verbinding maken met de drie locaties.

 

Helpdesk bereikbaar maken:

- Een forward zone toevoegen op de servers van alle drie de locaties.

 

Integreren van werkplekken:

- De computers toevoegen in een netwerk “folder” waarin de gebruikers ook in staan.

 

Data overdracht:

- Internet abonnement upgraden naar een business abonnement.

 

 

Registreren van ingelogde gebruikers:

- Een instellingsbeleid instellen.

 

File access:

- Netwerk schijven aanmaken.

 

De “Run” commando afschermen

- Door een instellingsbeleid kan deze worden afgeschermd.

 

3.4 Oplossing

Na nader besluit zijn er een paar oplossing boven water gekomen deze zijn:

 

Om de drie aparte netwerken te koppelen: word er een site to site netwerk toegevoegd.

 

Om de helpdesk bereikbaar te maken is er besloten dat er een forward zone toegevoegd zal worden op de drie locaties zodat deze verbinding kunnen maken met de helpdesk server.

 

Voor het integreren is er besloten: De computers toevoegen in een netwerk “folder” waarin de gebruikers ook in staan zodat de computers een netwerk adres ontvangen van de server.

 

Voor de snelle data overdracht: word de huidige netwerk abonnement verhoogt.

 

Voor het registreren van ingelogde gebruikers: Word met een instellingsbeleid geconfigureerd.

 

File access : er zullen netwerk schijven aangemaakt worden en deze zullen ook gedeeld worden met elkaar, door middel van beleidsinstellingen zal er bepaald worden wie wat kan zien en bewerken.

 

Het afschermen van de “Run” commando zal gedaan worden met een instellingsbeleid.

 

4 Afhankelijkheden

De helpdesk is afhankelijk van support medewerkers, als gebruikers tickets aanmaken maar er zijn geen medewerkers beschikbaar die dit kunnen oppakken dan blijven de tickets maar stapelen.

De directie is afhankelijk van het upgraden van het huidige netwerk abonnement naar een zakelijke.

 

 

5 Knelpunten

Netwerk verbinding kan uitvallen.

- Als er werkzaamheden worden uitgevoerd kan de netwerk uitvallen.

Netwerk uitgeschakeld

- Netwerk kan uitvallen omdat het word omgezet naar een snellere verbinding.

Geen medewerkers

- Geen medewerkers beschikbaar voor de helpdesk

 

6 Organisatorische consequenties

Als het niewe systeem geplaatst en geïnstalleerd is zal IToen voor deze locatie netwerk beheerders moeten inhuren om het nieuwe systeem te onderhouden.

7 Opleiding gebruikers

De gebruikers zullen een kleine cursus krijgen zodat men weet gebruik te maken van de netwerk schijven en hoe je een ticket aanmaakt op de helpdesk.

 

8 Beveiliging

Het nieuwe systeem zal beveiligd worden met een firewall en een anti virus pakket.

 

[Hans van den Bergh]

Beste jwzdocent,

 

Allereerst welkom op HL, echter vraag ik mij af of je deze, zeer technisch ogende vraag, wel in het juiste forum stelt. Het topic waarin je reageert, is al 12 jaar oud en Higherlevel is een forum waar de focus 100% op ondernemerschap ligt.

 

 

[Norbert Bakker]

@jzwdocent, allereerst welkom op Higherlevel!

 

Inhoudelijk: weet je dat je hebt gereageerd op een préhistorische vraag van 12 jaar en 3 maanden oud????

 

Allereerst welkom op HL, echter vraag ik mij af of je deze, zeer technisch ogende vraag, wel in het juiste forum stelt. Higherlevel is een forum waar de focus op ondernemerschap ligt.

Waar zie jij een vraag in deze reactie, Hans? Lees ik er overheen wellicht?

[Hans van den Bergh]

Waar zie jij een vraag in deze reactie, Hans? Lees ik er overheen wellicht?

Herstel: 'vraag' moet zijn: 'bericht' :)

 

 

 

[Norbert Bakker]

Herstel: 'vraag' moet zijn: 'bericht' :)

 

Het is zo te lezen geen vraag of bericht , maar een antwoord op de vraag van TS in de vorm van een voorbeeld?

 

 

[Highio]

Twaalf jaar na dato...

 

Groet,

 

Highio

[Norbert Bakker]

Twaalf jaar na dato...

Dat hadden zowel Hans als ik in onze eerste reactie al geconstateerd ja ;)

 

Maar driemaal is wat mij betreft scheepsrecht, ik zet er een slot op