Hoe je voor te bereiden als functioneel ontwerper?

[Anoniem: 406096]

Vrinden,

Per 1 april kan ik aan de slag als functioneel ontwerper. Ik heb als afgestudeerd filosoof geen IT achtergrond, maar ben zo'n beetje, door zelfstudie, halverwege het eerste Java certificaat (OCA). Ik wil daar gewoon mee doorgaan totdat ik het certificaat heb, om een beetje basiskennis van programmeren en 'IT-denken' te snappen.
Nu ben ik benieuwd of jullie ideeen hebben hoe je je verder zou kunnen voorbereiden voor een functie als FO. Zijn er specifieke certificaten, methodes etc. etc.? Uiteraard krijg ik eea aan trainingen etc. aangeboden (het betreft een soort tweejarig traineeship dus men weet dat men mij eigenlijk alles nog bij moet brengen), maar beter iets te veel dan te weinig voorbereiding. Kortom: wat zou komende maand mijn daginvulling moeten zijn om zo goed mogelijk beslagen ten ijs te komen?

Alvast bedankt voor alle tips!

[DJMaze]

De belangrijkste tip: Zorg dat er een Senior FO en Senior IT in de buurt is!
verder:

• UML leren
• Wireframes
• kijk naar applicaties en websites: waarom staat een knop daar? waarom is het menu zo? is het consistent?

Je gaat namelijk anders zo de fout in.

Want iets simpels als hoe paginering moet functioneren is al een hele opgave, zoals ik heb gezien op woningnet:

Welke pagina's bestaan er tussen 1 en 2 en 3 en 4?
Waarom als ik op pagina 3 zit staat pagina 4 niet naast 3?
De paginering is ontworpen voor 7+ pagina's, maar er zijn er maar 5.

Edit: Persoonlijk zou ik voor een 2-3-2 of 3-3-3 systeem gaan en geen dividers tonen als het niet nodig is.
Het gaat immers niet alleen om functionaliteit maar ook om logica in mijn optiek.

[ Voor 11% gewijzigd door DJMaze op 02-03-2016 21:15 ]

[Laurens-R]

Even niet wetende wat je gaat maken, wat tips:

1. Bepaal hetgeen wat je klant probeert te bereiken; een klant wil geen mooiere website (of erp, crm systeem etc), dat is slecht een middel om meer klanten, omzet etc te bereiken.

2. Graaf je in de bedrijfsprocessen bij een klant en breng deze in kaart, welke processen hebben een relatie met het te ontwikkelen systeem? Een FO persoon moet vaak ook een (soort van) business analyst zijn.

3. Wat voor mensen gaan werken met het systeem? Wat zijn hun rollen? Wat motiveerd hen om elke dag naar hun werk te gaan (hint: het is niet jouw ict oplossing)

4. Raak bekend met XD concepten. Het liefst zou er een dedicated XD specialist op je project moeten zitten (verwar dit niet met een grafisch designer!!!), maar die luxe heb je niet altijd. Dus maak jezelf bekend met wat XD basics, om de achterliggende 'psychologie' bij het gebruik van het te ontwikkelen systeem te doorgronden. (Niet alleen de basale zaken zoals het reduceren van het aantal clicks, maar daarachter ook: Hoe helpt het systeem het doel van de klant te bereiken en hoe draagt de indeling van het systeem zo optimaal mogelijk bij aan het behalen van dat doel? Hoe beinvloed het systeem mensen en processen en hoe kan je een interface zo optimaal mogelijk indelen om deze te ondersteunen?). Wat voor XD assesments kan je doen om dit te meten etc?

Concrete tips:
- zoals eerder genoemd; uml leren.
- leer fatsoenlijke wireframes te maken.
- leer SMART funtctional, non functional requirements etc op te schrijven.
- verdiep je in de basics van xd
- verdiep je in business process analysis

[ Voor 10% gewijzigd door Laurens-R op 02-03-2016 22:11 ]

[Ruud2001]

Ik sluit me aan bij de eerdere opmerking van de overlap met business analyst. Verdiep je in de bedrijfsprocessen van de klant en durf ook altijd de volgende vragen te stellen: "Wat als we niks doen?" en "Hoe vaak komt dit voor?". Antwoorden hierop helpen je om in te schatten hoe het met je businesss case staat.

Verder kenmerkt een goed ontwerper zich door ook na te denken over de niet happy flow. Wat als de datakwaliteit niet op orde is, wat moet er gebeuren bij foutieve invoer of data inconsistency? Wat staat er in de foutmelding, en welke middelen heeft een eindgebruiker of beheerder om de foutsituatie alsnog op te lossen? Denk na over zaken die een functioneel/technisch beheerder van de software nodig heeft: logging, monitoring tools, etc. Bij financiële systemen: audit! Leg vast wie, wat, wanneer gedaan heeft. Etc.

[McKaamos]

Ruud2001 schreef op zaterdag 05 maart 2016 @ 13:27:
Ik sluit me aan bij de eerdere opmerking van de overlap met business analyst. Verdiep je in de bedrijfsprocessen van de klant en durf ook altijd de volgende vragen te stellen: "Wat als we niks doen?" en "Hoe vaak komt dit voor?". Antwoorden hierop helpen je om in te schatten hoe het met je businesss case staat.

Verder kenmerkt een goed ontwerper zich door ook na te denken over de niet happy flow. Wat als de datakwaliteit niet op orde is, wat moet er gebeuren bij foutieve invoer of data inconsistency? Wat staat er in de foutmelding, en welke middelen heeft een eindgebruiker of beheerder om de foutsituatie alsnog op te lossen? Denk na over zaken die een functioneel/technisch beheerder van de software nodig heeft: logging, monitoring tools, etc. Bij financiële systemen: audit! Leg vast wie, wat, wanneer gedaan heeft. Etc.

Dat klinkt als een Software Test Engineer.
Misschien is een papiertje TMAP of ISTQB ook geen gek idee om erbij te halen. Gewoon voor het 'doemdenken' en het inzicht in welke wegen een gebriuker of beheerder kan bewandelen. Of wat er gebeurt als de data niet klopt.

[Croga]

Ik denk dat de belangrijkste vraag hier nog wel is:

Wat ziet je werkgever als "functioneel ontwerp"?

Het is slechts een naampje met een enorm brede interpretatie. En dat zie je hierboven al aan de antwoorden; is het een business analyst? Een test engineer? Een product owner of lid van een IT team? De term "Functioneel ontwerper" zegt, an sich, te weinig om gericht kennis op te gaan doen.

- UML is leuk om te leren, als de rest van het bedrijf het ook gebruikt, anders is het zinloos
- UX design is leuk tenzij er een specifiek UX persoon is binnen het bedrijf
- Business process kennis is altijd goed maar als het een groot bedrijf is moet je wel weten welk deel van het business process je verantwoordelijk voor gaat zijn.
- Exception definities zijn goed tenzij er een test coördinator is die dit doet voor je teams.

Alles bij elkaar staat en valt alles bij wat je werkgever van je verwacht. Als je dat niet weet ben je in het wilde weg aan het studeren, als je dat wel weet heb je onze voorstellen niet meer nodig

[CH4OS]

DJMaze schreef op woensdag 02 maart 2016 @ 20:39:
De belangrijkste tip: Zorg dat er een Senior FO en Senior IT in de buurt is!
verder:

• UML leren
• Wireframes
• kijk naar applicaties en websites: waarom staat een knop daar? waarom is het menu zo? is het consistent?

Je gaat namelijk anders zo de fout in.

Want iets simpels als hoe paginering moet functioneren is al een hele opgave, zoals ik heb gezien op woningnet:
[afbeelding]
Welke pagina's bestaan er tussen 1 en 2 en 3 en 4?
Waarom als ik op pagina 3 zit staat pagina 4 niet naast 3?
De paginering is ontworpen voor 7+ pagina's, maar er zijn er maar 5.

Edit: Persoonlijk zou ik voor een 2-3-2 of 3-3-3 systeem gaan en geen dividers tonen als het niet nodig is.
Het gaat immers niet alleen om functionaliteit maar ook om logica in mijn optiek.

Volgens mij is dit meer een omschrijving voor een UX-medewerker/specialist en heeft dat verder weinig te maken met een functioneel ontwerper, die omschrijft alleen een (web) app wat het functioneel gezien moet doen, niet waar het zit of hoe het eruit komt te zien.

[ Voor 12% gewijzigd door CH4OS op 05-03-2016 13:46 ]

[DJMaze]

In een FO staan de functionaliteiten per pagina.
Bij een nieuws overzicht pagina kan dus ook een paginering staan.
In je wireframe neem je dus de paginering mee: [<] [1] [2] ... [4] [5] [6] ... [9] [10] [>]
Maar je moet jezelf ook de volgende vragen stellen:

• Waarom "..." ipv [3], neemt evenveel ruimte in als
  [<] [1] [2] [3] [4] [5] [6] ... [9] [10] [>]
• Wat als het 9 pagina's zijn?
  Je kan dan immers ook [<] [1] [2] [3] [4] [5] [6] [7] [8] [9] [>]
• Wat als het 7 pagina's zijn?
  Je kan dan immers ook [<] [1] [2] [3] [4] [5] [6] [7] [>]
• Wat als het 1 pagina is?
  Toon je dan: [<] [1] [>]
• Wat als op pagina 1 bent? Toon je dan de zinloze: [<]

En dat is ook allemaal: functionaliteit.

Ander voorbeeld: de login pagina.
Een professional zou bij het zien van van een login pagina de volgende vragen (moeten) stellen:
- Wat als een gebruiker zijn wachtwoord is vergeten?
- Wat als er een error optreed?
En daar moet ook een functionaliteit voor geschreven worden.
Of de error tekst nou rood, roze of pimpelpaars is, dat maakt niet uit.

Ik heb dit zo vaak gemist in het FO en dan dus ook in de uiteindelijke ontwerpen, dat er dingen vervolgens gewoon weer terug naar de tekentafel gingen en ik moest wachten...

[ Voor 22% gewijzigd door DJMaze op 05-03-2016 18:33 ]

[Croga]

DJMaze schreef op zaterdag 05 maart 2016 @ 15:09:
In een FO staan de functionaliteiten per pagina.
Bij een nieuws overzicht pagina kan dus ook een paginering staan.
In je wireframe neem je dus de paginering mee: [<] \[1] \[2] ... \[4] \[5] \[6] ... \[9] \[10] [>]
Maar je moet jezelf ook de volgende vragen stellen:

Nee, dat moet je je dus allemaal níet afvragen. Je moet gewoon een paginering laten bouwen en vervolgens kijken of dat wat gebouwd is voldoet. Daarmee spaar je een enorme berg ontwerp uit die hoogstwaarschijnlijk overbodig is omdat de ontwikkelaars vaak best weten hoe een paginering moet werken.
En als datgene wat gebouwd is dan niet voldoet kun je alsnog 5 minuten besteden om het te verbeteren.

Wat betreft de login en "wat nu als iemand zijn wachtwoord vergeten is", is het een ander verhaal. Daar moet je beschrijven óf je er iets aan wilt doen, maar blijf alsjeblieft ver van wát dan precies.

Het doel van een functioneel ontwerp is constraints neerzetten. Acceptatie criteria. Alles wat je meer doet dan dat is verloren tijd.

[DJMaze]

Goed, dat eerste deel begrijp ik wel, maar het volgende niet:

Croga schreef op zaterdag 05 maart 2016 @ 19:02:
Wat betreft de login en "wat nu als iemand zijn wachtwoord vergeten is", is het een ander verhaal. Daar moet je beschrijven óf je er iets aan wilt doen, maar blijf alsjeblieft ver van wát dan precies.

De "wachtwoord vergeten" is een nieuw functioneel ontwerp element (pagina/overlay).
Je moet in je document daar dan wel naar verwijzen.
Daarin staat dan in je wireframe bijvoorbeeld "e-mailadres" en een knop.
De actie vervolgens dat er iets wordt gemailed naar de gebruiker om zijn wachtwoord te resetten.
Dat "iets" is dan of een nieuw wachtwoord met activatielink, of alleen een actievatielink en mag daarna een nieuw wachtwoord bedenken.
Dat is allemaal workflow en functies.

Als dat er allemaal niet in staat, ook prima. Maar schrijf dan als eerste zin in je FO:

Het systeem wordt gemaakt me de standaard functionaliteiten van Joomla/WordPress/Drupal/CMS (doorhalen wat niet van toepassing is). En de rest staat hieronder....

Dat maakt het een stuk gemakkelijker!

[farlane]

DJMaze schreef op zaterdag 05 maart 2016 @ 15:09:
In een FO staan de functionaliteiten per pagina.

Want een FO gaat over altijd websites?

[DJMaze]

farlane schreef op zaterdag 05 maart 2016 @ 21:42:
Want een FO gaat over altijd websites?

Nee hoor, kan echt vanalles zijn.
Kijk maar eens naar de Agenda paginering in je Agenda software.
Is die per dag, 3 dagen, week, maand of kan je dat zelf instellen?
Begint de week op zondag of begint de week op maandag?

Natuurlijk heeft iedereen dit al van te voren uitgekauwd en hoef je bijna nooit moeilijk te doen.

Ja agenda dag kiezers, daar gaat het nog wel eens fout.
Dan vindt men dat je eerst de dag moet kiezen: ik kies de 31ste
Nu ga ik de maand kiezen: februari
Reset je de dag naar 29 februari?

[ Voor 28% gewijzigd door DJMaze op 05-03-2016 23:42 ]

[CH4OS]

DJMaze schreef op zaterdag 05 maart 2016 @ 15:09:
In een FO staan de functionaliteiten per pagina.

Ik weet dat er ook over nagedacht moet worden over de paginator, maar wat je als eerste voorbeeld gaf (omdat het vooral de looks omschreef, imo), kan net zo goed een bug (in de paginator) zijn, waardoor dat zo wordt weergegeven, dat hoeft echt geen functioneel ontwerper te bedenken. Die zegt gewoon dat er een paginator ergens te vinden is, met knoppen waardoor gebladerd kan worden in de pagina's, als er meer dan 1 pagina is, een FO omschrijft dus niet hoe het eruit komt te zien, alleen dát het er is.

Ander voorbeeld: de login pagina.
Een professional zou bij het zien van van een login pagina de volgende vragen (moeten) stellen:
- Wat als een gebruiker zijn wachtwoord is vergeten?
- Wat als er een error optreed?
En daar moet ook een functionaliteit voor geschreven worden.
Of de error tekst nou rood, roze of pimpelpaars is, dat maakt niet uit.

Ik heb dit zo vaak gemist in het FO en dan dus ook in de uiteindelijke ontwerpen, dat er dingen vervolgens gewoon weer terug naar de tekentafel gingen en ik moest wachten...

Tja, je kan je afvragen of een 'wachtwoord vergeten' functie onderdeel is van de login pagina. Ikzelf zie dat niet zo. Het is onderdeel van de authenticatie module (of class), wat niet zozeer terug te vinden hoeft te zijn op de login pagina. Bij het formulier kun je weliswaar een link opnemen naar de pagina die een password reset / reminder voor zijn rekening neemt, dat zeker, maar verder is er geen relatie met de login pagina. Dit zie je bijvoorbeeld terug in het login mechanisme van bijvoorbeeld Laravel. En dan heb je ook nog de vraag: wat als de gebruiker zijn gebruikersnaam vergeten is, maar wel zijn e-mailadres nog weet? En zo kun je nog wel meer dingen bedenken. Mijn punt is meer, dat de login pagina los staat van de functies die de authenticatie module (of class).

[Crazy D]

DJMaze schreef op zaterdag 05 maart 2016 @ 23:39:
Nee hoor, kan echt vanalles zijn.
Kijk maar eens naar de Agenda paginering in je Agenda software.
Is die per dag, 3 dagen, week, maand of kan je dat zelf instellen?
Begint de week op zondag of begint de week op maandag?

Dat zijn precies functies waar de business wel of niet om vraagt. Als ontwerper bedenk je niet zomaar iets maar om een casus op te lossen. Als de business er om vraagt ga je beschrijven welke weergave modi nog zijn. Zegt de business hier niets over ga je als ontwerper doorvragen want als je een agenda hebt moet je een weergave hebben...

[DJMaze]

Crazy D schreef op zondag 06 maart 2016 @ 13:07:
Zegt de business hier niets over ga je als ontwerper doorvragen want als je een agenda hebt moet je een weergave hebben...

Volgens mij gaat het daarom ook vaak mis in de IT.
En dan praat ik niet alleen over al die overheidsprojecten.

Er staat bijvoorbeeld maar 1 weergave modus in je FO.
Het project is "af" en vervolgens vraagt de business waarom je alleen een agenda per week hebt.
Vervolgens komt het "meer werk" om de hoek kijken.

Dus wat er niet in het FO staat is een probleem voor het hele traject.
Of heb ik het mis en moet je de business er niet mee opzadelen en "extra tijd" inramen?

[CH4OS]

DJMaze schreef op zondag 06 maart 2016 @ 18:36:
Volgens mij gaat het daarom ook vaak mis in de IT.
En dan praat ik niet alleen over al die overheidsprojecten.

Er staat bijvoorbeeld maar 1 weergave modus in je FO.
Het project is "af" en vervolgens vraagt de business waarom je alleen een agenda per week hebt.
Vervolgens komt het "meer werk" om de hoek kijken.

Dus wat er niet in het FO staat is een probleem voor het hele traject.
Of heb ik het mis en moet je de business er niet mee opzadelen en "extra tijd" inramen?

De opdrachtgever dient akkoord te geven op het functioneel ontwerp. Zodra dat er is, wordt er gebouwd. Mochten functies dan toch nog missen, dan is dat niet de schuld van de ontwikkelaar (de klant heeft immers akkoord gegeven op het FO), maar die van de opdrachtgever. Logisch dat het dan meerwerk is, want het is extra werk, wat niet afgesproken is.

Natuurlijk had de ontwikkelaar het kunnen voorkomen (er zijn immers genoeg agenda libraries te vinden op het web), maar aan de andere kant geeft de opdrachtgever niet voor niets een akkoord op het FO.

[Crazy D]

DJMaze schreef op zondag 06 maart 2016 @ 18:36:
Volgens mij gaat het daarom ook vaak mis in de IT.
En dan praat ik niet alleen over al die overheidsprojecten.

Er staat bijvoorbeeld maar 1 weergave modus in je FO.
Het project is "af" en vervolgens vraagt de business waarom je alleen een agenda per week hebt.
Vervolgens komt het "meer werk" om de hoek kijken.

Dus wat er niet in het FO staat is een probleem voor het hele traject.
Of heb ik het mis en moet je de business er niet mee opzadelen en "extra tijd" inramen?

Bij sommige zaken kun je als ontwerper al wel voorzien dat de business wellicht niet voldoende informatie geeft of er vanuit gaat dat sommige zaken "normaal" zijn. De taak van de ontwerper en de analyst is dan weel om door te vragen waarom en hoe, en op het antwoord dat je krijgt dat nog een keer te vragen, maar als uiteindelijk helemaal niemand zegt dat een agenda ook een maand weergave moet kennen, moet je die niet benoemen (maar wel benoemen wat er wel gemaakt gaat worden !).

1 valkuil is dat er veel te weinig is beschreven waardoor je vervolgens inderdaad bergen meerwerk krijgt. Een andere is juist dat er veel te veel wordt beschreven terwijl daar misschien juist helemaal geen vraag naar was!

Daar moet je dus een gemiddelde in zien te vinden en dan hangt het van het soort applicatie af in hoeverre je er op voorhand rekening mee moet houden. Een agenda weergave is niet zo spannend om daar later een variatie op te maken. De agenda items zelf is het op voorhand wel essentieel om te weten of een item altijd op 1 dag valt of dat deze dag-overschrijdend mag zijn. Dat kan later grotere aanpassingen vereisen.