Technieken voor concepting, analyse, planning en design Sonja Rouwhorst Instituut voor interactieve media Hogeschool van Amsterdam Datum: 21 januari 2008 Versie: 1 Status: definitief
Inhoudsopgave Inleiding... 4 Architectuur... 5 Doel... 5 Doelgroep... 6 Voorbeelden... 6 Conceptmap / mindmap... 8 Doel... 8 Doelgroep... 8 Voorbeelden... 8 Contentmatrix... 11 Doel... 11 Doelgroep... 11 Voorbeelden... 11 Eisenpakket MoSCoW... 13 Doel... 13 Doelgroep... 14 Voorbeelden... 14 ERD Databasemodel... 16 Doel... 16 Doelgroep... 16 Voorbeelden... 16 Gantt chart... 18 Doel... 18 Doelgroep... 18 Voorbeelden... 18 Moodboard... 20 Doel... 20 Doelgroep... 20 Voorbeelden... 20 Persona... 22 Doel... 22 Doelgroep... 22 Voorbeelden... 22 Scenario / use-case... 26 Doel... 26 Doelgroep... 26 Voorbeelden... 26 Schermontwerp... 28 Doel... 28 Doelgroep... 28 Voorbeelden... 29 Sitemap... 32 Doel... 32 Doelgroep... 33 Voorbeelden... 33 Storyboard... 35 Doel... 35 Doelgroep... 35 Voorbeelden... 35 Stroomdiagram... 38 Doel... 38 Doelgroep... 38 Voorbeelden... 38 UML... 43 Doel... 43 Doelgroep... 43 Voorbeelden... 44 2 van 52
Wireframe... 46 Doel... 46 Doelgroep... 46 Voorbeelden... 47 Lijst met figuren... 50 Bronnen... 52 3 van 52
Inleiding Binnen interactieve media wordt gebruik gemaakt van een groot aantal technieken om de communicatie tussen personen of partijen te faciliteren. Een techniek kan ingezet worden om inspiratie op te doen, om helderheid te creëren, om afspraken vast te leggen, om mogelijkheden te verkennen of om feedback te krijgen. De technieken zijn te gebruiken bij verschillende fases, namelijk bij conceptontwikkeling, analyse, ontwerp, realisatie of management. Het is zeker geen compleet overzicht, maar vooral een mooie verzameling voorbeelden. Uit de voorbeelden zal blijken dat er niet één juiste manier is om een techniek te gebruiken. De vragen die je je constant zou moeten afvragen zijn: Wat wil ik duidelijk maken? o Gaat het over het concept, de planning, de interactie, het grafisch ontwerp, de functionaliteit, de hardware of nog anders? o Tot welk detailniveau moet ik gaan? o Voor wie maak ik het? Voor de opdrachtgever, de projectmanager, key-users, investeerders, programmeurs, ontwerpers etc. Wat wil ik bereiken? o Inspiratie opdoen, o Helderheid creëren, o Afspraken vastleggen, o Mogelijkheden verkennen o Feedback krijgen De technieken zijn gesorteerd op alfabetische volgorde. Van elke techniek wordt het volgende besproken: Doel Wat is de doelstelling van de techniek Doelgroep Voor wie is de techniek geschikt. Kan de techniek ingezet worden om met gebruikers te communiceren, of juist met developers bijvoorbeeld. Voorbeelden Een techniek kan vaak op verschillende manieren ingezet worden. Het detailniveau kan wisselen afhankelijk van de situatie bijvoorbeeld. De doelstelling kan ook behoorlijk verschillen. Zo kan een stroomdiagram bijvoorbeeld gebruikt worden om bedrijfsprocessen in kaart te brengen, of het kan bijvoorbeeld de interactie binnen een applicatie beschrijven. 4 van 52
Architectuur Figuur 1 - architectuur Architectuur is een term die vooral gebruikt wordt bij de bouw van huizen en gebouwen. In dit geval wordt een ander soort architectuur bedoeld. De architectuur is een model met een hoog abstractieniveau. In tegenstelling tot een ontwerp, wat erg specifiek is. De architectuur kan de basis vormen voor meerdere uitwerkingen en is bedoeld om uitgangspunten duidelijk te maken. Er kan onderscheid gemaakt worden tussen 1. Software architectuur De structuur van de code voor een applicatie 2. Hardware architectuur De structuur van de hardware. 3. Applicatie architectuur De relatie tussen verschillende applicaties Doel Uitgangspunten voor het ontwerp en de bouw (realisatie) overbrengen. 5 van 52
Doelgroep De architectuur is de basis voor het ontwerp en de bouw en daardoor van belang voor alle ontwerpers en developers. Voorbeelden Figuur 2 - software architectuur - model view controller Figuur 3 - software architectuur scheiding markup, presentatie en gedrag 6 van 52
Figuur 4 - hardware architectuur client server architectuur Figuur 5 - applicatiearchitectuur met servicebus 7 van 52
Conceptmap / mindmap Figuur 6 - abstracte en simpele conceptmap Doel Een conceptmap kan een team helpen om ideeën te genereren of in kaart te brengen. Een conceptmap kan daarnaast helpen het concept duidelijk over te brengen aan opdrachtgevers, investeerders en belanghebbenden. Doelgroep Conceptontwikkelaars maken conceptmaps om te een idee over te brengen aan opdrachtgevers, investeerders en andere belanghebbenden. Voorbeelden Hieronder staan een aantal voorbeelden. 8 van 52
Figuur 7 - conceptmap waarin relaties tussen concepten zijn aangegeven 9 van 52
Figuur 8 - erg complexe conceptmap waarvan je je moet afvragen of het nuttig is 10 van 52
Contentmatrix Figuur 9 - contentmatrix Doel Bij websites met grote hoeveelheden content, is het van belang deze content in kaart te brengen. Een contentmatrix kan gebruikt worden om na te gaan of er geen content vergeten wordt. Verder is een contentmatrix een handige basis voor het maken van planningen. Bij de kolommen in een contentmatrix kun je denken aan: Titel Url Korte beschrijving Soort content Formaat Categorie / subcategorie Toegankelijkheid Eigenaar / beheerder Update frequency Meta data Doelgroep Projectmanagers gebruiken contentmatrices bij het maken van planningen voor een project. Wanneer een bestaande site wordt aangepast, kan een contentmatrix ook gebruikt worden om aan te geven welke content wordt overgezet en waar deze terecht gaat komen. Verder kan een contentmatrix gebruikt worden voor communicatie met de toekomstige content managers. Voorbeelden 11 van 52
Figuur 10 - contentmatrix op hoog niveau Figuur 11 - contentmatrix op detail niveau 12 van 52
Eisenpakket MoSCoW Ref. Requirement description Priority I.1 Maintain patient databases and provide ability to easily generate historical patient Must-have reports. I.2 Allow patient database search based on: Must-have I.2.1 Patient name Must-have I.2.2 Patient account number Must-have I.2.3 Patient SSN Must-have I.3 Allow the user to search previous patient results for specific tests and easily view historical results of that test. Shouldhave I.4 Allow the user to graph patient results by test to identify possible trends Must-have I.5 Allow historical results for multiple tests to be graphed on one normalized graph. Couldhave I.6 Allow the user to easily access archived patient records. Must-have I.7 Allow the user to review a specific patient's results without paging through the entire list of patient results. Couldhave I.8 Allow for patient searches by a variety of means: Name, Social Security Number, Client, Accession #, or Requisition #. Waiting-list Figuur 12 - eisenpakket Doel Een eisenpakket is een opsomming van eisen waaraan het te realiseren product moet gaan voldoen. Het eisenpakket wordt in de loop van een project vastgesteld en aan het einde van een project gebruikt om te controleren of aan de eisen is voldaan. De formulering van een eis is daarbij erg belangrijk, aangezien deze niet voor meerdere interpretaties vatbaar mag zijn. Vaak wordt onderscheid gemaakt tussen Functionele eisen: Deze eisen beschrijven wat een gebruiker kan zien en kan doen. Niet-functionele eisen, zoals: o Performance eisen o Interface en usability eisen o Eisen over onderhoud en beheer o Technische eisen, hardware, software, interactie met andere systemen e.d. o Eisen over beveiliging, veiligheid en betrouwbaarheid Het is een goed gebruik om bij elke eis de prioriteit vast te stellen. Een manier om prioriteiten aan te geven is door gebruik te maken van MoSCoW. MoSCoW (zonder de o's) is een acroniem voor M: Must-have: essentieel, zonder aan deze eis te voldoen kan het product niet gebruikt worden. S: Should-have: belangrijke eis, waarvoor op de korte termijn een work-around gevonden kan worden als deze niet gerealiseerd zou worden. C: Could-have: eisen die makkelijker weggelaten kunnen worden W: Wan't to have, but won't have this time: eisen die later gerealiseerd kunnen gaan worden 13 van 52
Bij het opstellen van eisen is het verstandig na te gaan of de eis aan de volgende criteria voldoet: Enkelvoudig De eis beschrijft slechts één ding Consistent De eis is niet strijdig met andere eisen Haalbaar De eis is te realiseren binnen de uitgangspunten van het project Niet ambigu De eis is slechts voor één interpretatie vatbaar. Het taalgebruik bevat geen technisch jargon, subjectieve termen, afkortingen e.d. Verifieerbaar Er kan nagegaan worden of aan de eis wordt voldaan door één van de volgende methoden: inspectie, analyse, demonstratie of testen. Doelgroep Bij het opstellen van eisen en het aangeven van prioriteiten worden key-users betrokken. Een eisenpakket wordt over het algemeen gebruikt door projectmanagers om meer zekerheid te krijgen over een project. Aan het einde van een bouwfase zullen testers de eisen gebruiken om te controleren of hieraan voldaan is. Voorbeelden Figuur 13 - eisenpakket met mogelijkheid om voortgang te zien 14 van 52
Figuur 14 - eisenpakket met veranderende eisen 15 van 52
ERD Databasemodel Figuur 15 - ERD (Entity Relationship Diagram) Bovenstaand model geeft de structuur van een database waarin gegevens over de verkoop van boeken wordt opgeslagen. De database bestaat uit 6 tabellen (sale, sale_title_xref, author, title, publisher, category en obituary). Van elke tabel is aangegeven welke gegevens erin komen te staan en wat voor formaat die gegevens hebben. Tussen author en title zie je een lijn staan die zich vertakt. Hiermee wordt aangegeven dat een auteur meerdere boeken kan op zijn naam kan hebben staan. Doel De meest gebruikte techniek voor het beschrijven van de structuur van een database is het ERD Entity Relationship Diagram. Deze techniek wordt gebruikt voor het ontwerp van een database. Een ERD beschrijft de entiteiten (tabellen) en de relatie tussen verschillende tabellen. Doelgroep Een ERD wordt vrijwel alleen gebruikt door developers binnen een projectteam. Voorbeelden Er zijn veel verschillende manieren om ERD's te maken. De manieren lijken veel op elkaar maar kunnen zeker verschillen. Hieronder zie je een paar voorbeelden. 16 van 52
Figuur 16 - ERD voor een portfolio database Figuur 17 - andere tekentechniek voor een ERD 17 van 52
Gantt chart Figuur 18 - gantt chart of strokenplanning In bovenstaande figuur zie je taken en wanneer deze taken zijn ingepland. De rode streep geeft aan wat de huidige datum is. De grijze balken geven aan hoeveel tijd er is voor het afronden van de taak. Met blauw is aangegeven wat de voortgang is. Doel Een gantt chart wordt gebruikt voor het maken van planningen. Een gantt chart bevat een overzicht van de werkzaamheden / taken en een schatting van de tijd die nodig is om een taak af te ronden. Ook wordt aangegeven wanneer een taak begint. Doelgroep Een gantt chart zal gemaakt worden door projectmanagers en gebruikt worden door iedereen in het projectteam. Voorbeelden 18 van 52
Figuur 19 - simpele gantt chart waarin mijlpalen staan vermeld Figuur 20 - gantt chart waarin afhankelijken tussen taken zijn opgenomen 19 van 52
Moodboard Figuur 21 - mood board op de deur van een koelkast Doel Een mood board kan een ontwerper helpen om de sfeer van een product of doelgroep te verkennen en inspiratie op te doen. Daarnaast kan het helpen om met opdrachtgevers te communiceren over 'vage' onderwerpen als sfeer, uitstraling en emotie. Een mood board kan plaatjes, woorden, kleuren, typografie en dergelijke bevatten. Tegenwoordig worden mood boards steeds vaker digitaal gemaakt in plaats van op een 'echt' bord. Doelgroep Mood boards worden voornamelijk gebruikt door conceptonwikkelaars en grafisch ontwerpers. Voorbeelden Hieronder zie je enkele voorbeelden van mood boards. 20 van 52
Figuur 22 - digitaal mood board bestaande uit screenshot van websites Figuur 23 - 'net' mood board die gebruikt kan worden voor overleg met een opdrachtgever 21 van 52
Persona Figuur 24 - persona Doel Personae zorgen ervoor dat bij ontwerpactiviteiten de gebruiker centraal staat. In sommige projecten is het mogelijk om key-users mee te laten draaien in het project. Andere keren is dat niet mogelijk en kunnen personae zorgen voor inzicht in de verschillende soorten gebruikers. Een persona representeert een deel van de gebruikersgroep. Mogelijke manieren om de gebruikersgroep op te delen, zijn leeftijd, geslacht, inkomen, opleidingsniveau en zo zijn er nog talrijke andere mogelijkheden. Voordat een persona kan worden opgesteld, vindt er eerst onderzoek plaats naar toekomstige gebruikers, door middel van bijvoorbeeld observaties, interviews, focus groepen en enquêtes. De informatie uit het onderzoek helpt bij het segmenteren van de gebruikersgroep op basis van motivatie, gedrag, behoeften en het soort beleving dat die gebruikersgroep zoekt. Vervolgens kan voor elke segmentatie een persona ontwikkeld worden. Doelgroep Personae worden vooral gebruikt door conceptontwikkelaars en ontwerpers. Ze zijn tevens een goed hulpmiddel om met belanghebbenden te communiceren over gebruikers. Voorbeelden Hieronder staan voorbeelden van personae uitgewerkt in verschillende detailniveau's. Het laatste voorbeeld is een soort invultemplate voor een heel uitgebreide persona. 22 van 52
Figuur 25 - versimpelde personae die gebruikt worden bij een presentatie Figuur 26 - persona in meer detail 23 van 52
24 van 52
Figuur 27 - invultemplate voor een uitgebreid persona 25 van 52
Scenario / use-case It's Friday afternoon and Joe is flying to Sydney. He doesn't have enough money for a taxi to the airport, and he's running late. He goes to the local ATM and identifies himself. He specifies that he wants $100 from his savings account. He'd like the money in $20 notes so that he can give the taxi driver the correct change. He doesn't want a printed receipt, as he doesn't bother keeping track of transactions in this account. Figuur 28 - scenario Doel Een scenario beschrijft de interactie tussen een gebruiker en een applicatie. Scenario's zijn vaak de logische vervolgstap na het maken van personae. Scenario's kunnen laten zien hoe verschillende personae een applicatie kunnen gebruiken. Hierboven zie je een voorbeeld van een scenario zoals die in de beginfase van een project gemaakt zou worden. Naarmate het project vordert kunnen scenario's een gedetailleerder en technischer karakter krijgen. Meestal wordt dan gesproken over use-cases. Bij use-cases wordt gewerkt met actoren in plaats van personae. Elke actor staat voor een bepaalde gebruikersgroep met dezelfde rechten en mogelijkheden om bijvoorbeeld onderscheid te maken tussen bezoekers, members, beheerders etc. Doelgroep Een scenario kan gebruikt worden om een concept te verduidelijken en wordt vooral in de conceptfase van een project gebruikt. Een use-case wordt gebruikt om in detail de interactie te beschrijven. Usecases worden met name gebruikt door ontwerpers en developers. Voorbeelden Figuur 29 - deel van een scenario met wireframes ter illustratie 26 van 52
Figuur 30 - use-case Use Case Actors Assumptions Steps Variations (optional) Use case identifier and reference number and modification history Each use case should have a unique name suggesting its purpose. The name should express what happens when the use case is performed. It is recommended that the name be an active phrase, e.g. Place Order. It is convenient to include a reference number to indicate how it relates to other use cases. The name field should also contain the creation and modification history of the use case preceded by the keyword history. List of actors involved in use case Lists the actors involved in the use case. An actor can be a person (a specific type of user for example) or another system. Conditions that must be true for use case to terminate successfully Lists all the assumptions necessary for the goal of the use case to be achieved successfully. Each assumption should be stated as in a declarative manner, as a statement that evaluates to true or false. If an assumption is false then it is unspecified what the use case will do. The fewer assumptions that a use case has then the more robust it is. Interactions between actors and system that are necessary to achieve goal The sequence of interactions necessary to successfully meet the goal. The interactions between the system and actors are structured into one or more steps which are expressed in natural language. A step has the form <sequence number><interaction> Conditional statements can be used to express alternate paths through the use case. Repetition and concurrency can also be expressed. Any variations in the steps of a use case Further detail about a step may be given by listing any variations on the manner or mode in which it may happen. <step reference> < list of variations separated by or> Figuur 31 - use-case template 27 van 52
Schermontwerp Figuur 32 - schermontwerp Doel Schermontwerpen laten zien hoe de applicatie eruit komt te zien. Hierbij gaat het om layout, typografie, kleurgebruik en vormen. De basis van een applicatie wordt meestal gevormd door een aantal vaste templates waar ieder scherm uiteindelijk op gebaseerd wordt. In veel gevallen is het handig om daarnaast een stencil te maken van veel voorkomende schermelementen, zoals titels, buttons en iconen. Voor de teksten in een schermontwerp wordt vaak 'lorem ipsum' gebruikt. Enerzijds gebeurt dit om te voorkomen dat over de content gediscussieerd wordt in plaats van over het ontwerp. Anderzijds om te voorkomen dat de gesprekspartner het idee heeft dat de applicatie al 'af' is. Daarnaast worden schermontwerpen gebruikt om de interactiemogelijkheden van een scherm te beschrijven. Op gegeven moment moet op veldniveau vastgelegd worden wat voor soort veld het is (checkbox, tekstveld, drop-down box etc.), wat het label is, of het een verplicht veld is, of er een default waarde in staat en zo meer. Doelgroep Schermontwerpen worden gemaakt voor developers, zodat duidelijk is wat er gemaakt moet worden. Ook kunnen schermontwerpen gebruikt worden om met key-users te overleggen wat de mogelijkheden op detailniveau zijn. 28 van 52
Voorbeelden Figuur 33 - schermontwerp met de nadruk op visuals Figuur 34 - abstract schermontwerp om layout op pixelniveau vast te leggen 29 van 52
Figuur 35 - stencil met veel voorkomende schermelementen 30 van 52
Figuur 36 - schermontwerp met uitwerking van interactie op veldniveau 31 van 52
Sitemap Figuur 37 - sitemap voor een dynamische website Doel Een sitemap toont hoe de content van een website gestructureerd is en hoe navigatie mogelijk wordt gemaakt tussen deze pagina's. Let op: de sitemaps die in dit onderdeel besproken worden, zijn geen sitemaps zoals die op de website komen te staan. De sitemaps hieronder worden gebruikt tijdens het ontwerpproces en helpen bepalen hoe de content opgedeeld wordt. De complexiteit van de structuur is afhankelijk van je doelgroep 32 van 52
Doelgroep Sitemaps worden gebruikt door zowel ontwerpers als developers. Ze kunnen ook een handig hulpmiddel zijn bij het plannen van het ontwerp- of bouwproces. Voorbeelden Figuur 38 - sitemap op abstract niveau Figuur 39 - sitemap op onconventionele manier weergegeven 33 van 52
Figuur 40 - sitemap voor een complexe website 34 van 52
Storyboard Figuur 41 - storyboard Doel Een storyboard vertelt een verhaal, bijvoorbeeld een scenario op een visuele manier. Eventueel wordt uitleg in tekst gegeven. De techniek van storyboards komt uit de film en reclame wereld. Storyboards zijn heel handig voor het uitwerken van video's en animatie's. Een storyboard kan ook aangeven hoe een product of applicatie gebruikt kan worden. De visuals kunnen tekeningen of foto's zijn. Het is ook mogelijk om screenshots of wireframes te gebruiken in storyboards. Doelgroep Storyboards zijn een uitstekende manier om te communiceren met key-users, opdrachtgevers en andere belanghebbenden. Voorbeelden 35 van 52
Figuur 42 - storyboard met screenshots Figuur 43 - storyboard met foto's 36 van 52
Figuur 44 - storyboard van een reclame 37 van 52
Stroomdiagram Figuur 45 - stroomdiagram voor navigatie tussen schermen Doel Een stroomdiagram is een verzamelnaam voor een heleboel diagrammen. Je kunt denken aan schermverloopdiagrammen, sitemaps, workflow diagrammen, activiteitendiagrammen, circuit diagrammen enz. Ze hebben gemeenschappelijk dat er een volgordelijkheid wordt getoond. Stroomdiagrammen kunnen ook goed gebruikt worden om interactie tussen personen en systemen te tonen. In dat geval wordt vaak gebruik gemaakt van de zogenaamde swimming-lane tekentechniek. Hieronder zie je voorbeelden. Doelgroep Stroomdiagrammen kunnen gebruikt worden om (bedrijfs)processen of workflow in kaart te brengen. In dat geval zijn ze een goed communicatiemiddel met key-users. Vaak zijn stroomdiagrammen redelijk technisch en worden ze vooral ingezet door ontwerpers en developers. Voorbeelden 38 van 52
Figuur 46 - stroomdiagram met backdrop om stappen te groeperen Figuur 47 - stroomdiagram in swimming-lane formaat 39 van 52
Figuur 48 - stroomdiagram met beslispunten in swimming-lane formaat Figuur 49 - circuit diagram 40 van 52
Figuur 50 - stroomdiagram interactie tussen gebruiker en emailprogramma 41 van 52
Figuur 51 - stroomdiagram met pagina's, beslispunten en acties van de gebruiker 42 van 52
UML Figuur 52 - uml activity diagram Doel UML is een afkorting voor Unified (gestandaardiseerd) Modelling Language. Het is een visuele taal die gebruikt kan worden voor allerlei soorten doeleinden en vooral door developers wordt gebruikt. Een voordeel van UML is dat er softwarepakketten zijn die op basis van een ontwerp in UML een groot deel van de programmacode automatisch genereert. UML is vooral geschikt wanneer een objectgeoriënteerde taal wordt gebruikt. UML beschrijft een aantal types diagrammen met elk een eigen doel. De meest gebruikte diagrammen zijn: Class diagram Een objectgeorienteerde taal deelt de code op in classes. Een class diagram geeft aan welke classes er zijn en hoe ze van elkaar gebruik maken Activity diagram Een activity diagram is een stroomdiagram om bedrijfsprocessen en interactie te modelleren Sequence diagram Een sequence diagram is een stroomdiagram in swimming-lane formaat waarmee de interactie tussen gebruikers en systemen kan worden getoond Use case diagram Een use case diagram geeft een overzicht van use cases per type gebruiker Doelgroep UML wordt vooral gebruikt door developers. 43 van 52
Voorbeelden Figuur 53 - uml class diagram Figuur 54 - uml sequence diagram 44 van 52
Figuur 55 - uml use case diagram 45 van 52
Wireframe Figuur 56 - wireframe met annotaties over content Doel Een wireframe is een schermontwerp waamee functionaliteit, content en structuur getoond kan worden. In een wireframe worden grafische details zoveel mogelijk weggelaten. Het is mogelijk om typografie of kleuren te gebruiken, maar dit gebeurt uitsluitend om functionaliteit of structuur uit te leggen. Doelgroep Wireframes worden vooral gebruikt door interaction designers. 46 van 52
Voorbeelden Figuur 57 - wireframe met annotaties over functionaliteit en content 47 van 52
Figuur 58 - wireframe met kleuren voor uitleg structuur 48 van 52
Figuur 59 - wireframe voor pagina met verschillende verschijningsvormen 49 van 52
Lijst met figuren Figuur 1 - architectuur... 5 Figuur 2 - software architectuur - model view controller... 6 Figuur 3 - software architectuur scheiding markup, presentatie en gedrag... 6 Figuur 4 - hardware architectuur client server architectuur... 7 Figuur 5 - applicatiearchitectuur met servicebus... 7 Figuur 6 - abstracte en simpele conceptmap... 8 Figuur 7 - conceptmap waarin relaties tussen concepten zijn aangegeven... 9 Figuur 8 - erg complexe conceptmap waarvan je je moet afvragen of het nuttig is... 10 Figuur 9 - contentmatrix... 11 Figuur 10 - contentmatrix op hoog niveau... 12 Figuur 11 - contentmatrix op detail niveau... 12 Figuur 12 - eisenpakket... 13 Figuur 13 - eisenpakket met mogelijkheid om voortgang te zien... 14 Figuur 14 - eisenpakket met veranderende eisen... 15 Figuur 15 - ERD (Entity Relationship Diagram)... 16 Figuur 16 - ERD voor een portfolio database... 17 Figuur 17 - andere tekentechniek voor een ERD... 17 Figuur 18 - gantt chart of strokenplanning... 18 Figuur 19 - simpele gantt chart waarin mijlpalen staan vermeld... 19 Figuur 20 - gantt chart waarin afhankelijken tussen taken zijn opgenomen... 19 Figuur 21 - mood board op de deur van een koelkast... 20 Figuur 22 - digitaal mood board bestaande uit screenshot van websites... 21 Figuur 23 - 'net' mood board die gebruikt kan worden voor overleg met een opdrachtgever... 21 Figuur 24 - persona... 22 Figuur 25 - versimpelde personae die gebruikt worden bij een presentatie... 23 Figuur 26 - persona in meer detail... 23 Figuur 27 - invultemplate voor een uitgebreid persona... 25 Figuur 28 - scenario... 26 Figuur 29 - deel van een scenario met wireframes ter illustratie... 26 Figuur 30 - use-case... 27 Figuur 31 - use-case template... 27 Figuur 32 - schermontwerp... 28 Figuur 33 - schermontwerp met de nadruk op visuals... 29 Figuur 34 - abstract schermontwerp om layout op pixelniveau vast te leggen... 29 Figuur 35 - stencil met veel voorkomende schermelementen... 30 Figuur 36 - schermontwerp met uitwerking van interactie op veldniveau... 31 Figuur 37 - sitemap voor een dynamische website... 32 Figuur 38 - sitemap op abstract niveau... 33 Figuur 39 - sitemap op onconventionele manier weergegeven... 33 Figuur 40 - sitemap voor een complexe website... 34 Figuur 41 - storyboard... 35 Figuur 42 - storyboard met screenshots... 36 Figuur 43 - storyboard met foto's... 36 Figuur 44 - storyboard van een reclame... 37 Figuur 45 - stroomdiagram voor navigatie tussen schermen... 38 Figuur 46 - stroomdiagram met backdrop om stappen te groeperen... 39 Figuur 47 - stroomdiagram in swimming-lane formaat... 39 Figuur 48 - stroomdiagram met beslispunten in swimming-lane formaat... 40 Figuur 49 - circuit diagram... 40 Figuur 50 - stroomdiagram interactie tussen gebruiker en emailprogramma... 41 Figuur 51 - stroomdiagram met pagina's, beslispunten en acties van de gebruiker... 42 Figuur 52 - uml activity diagram... 43 Figuur 53 - uml class diagram... 44 Figuur 54 - uml sequence diagram... 44 Figuur 55 - uml use case diagram... 45 Figuur 56 - wireframe met annotaties over content... 46 Figuur 57 - wireframe met annotaties over functionaliteit en content... 47 50 van 52
Figuur 58 - wireframe met kleuren voor uitleg structuur... 48 Figuur 59 - wireframe voor pagina met verschillende verschijningsvormen... 49 51 van 52
Bronnen Brown, Dan. Communicating Design. Berkeley: New Riders, 2007. Saffer, Dan. Designing for Interaction. Berkeley: New Riders, 2007. Arnowitz, Jonathan, Michael Arent, Nevin Berger. Effective Prototyping for Software Makers. San Fransisco: Morgan Kaufmann, 2007. 52 van 52