Presentatie door Roy Scholten op Drupaljam 2013 in Rotterdam. Over het belang van een solide design proces voor een succesvol project.

1. Responsive design
Een rekbaar begrip
Drupaljam 2013, Rotterdam
Roy Scholten
@royscholten
Tuesday, July 2, 13
Hoi

2. Tuesday, July 2, 13
Hier werk ik.

3. Status
Tuesday, July 2, 13
Dit is geen theming talk. Ik ben geen front-ender. Don’t code

4. http://datenform.de/graphic-arrays.html
Tuesday, July 2, 13
Een van de sterkere visualisaties van het gegeven dat het echt niet meer constructief is om in
‘pages’ te denken.

5. “De wireframes.
Ze zijn niet goed
genoeg”
Tuesday, July 2, 13
Toen ik eind vorig jaar begon bij WK was dit voor mij het meest opvallende geluid.
Als de ene partij het interactie/design concept uitwerkt en de volgende partij het uitwerkt,
dan is de documentatie die uitgewisseld wordt en die paar meetings het enige wat er aan
gedeeld begrip is over de doelstellingen van het project, de wensen van de klant etc.
Guilty as charged. Daarom ben ik nu vanuit de technische hoek bezig om vanuit de positie
van ‘we can build it’ ook een bijdrage te leveren

6. http://www.flickr.com/photos/boypiyaphon/8014784654
Tuesday, July 2, 13
- Definitiefase: stel vast wat je wil bereiken
- Ontwerpfase: vind uit en leg vast hoe je dat het best kunt bereiken
- Build: voer het bedachte plan uit
Niks mis mee. Zeker niet als de doorlooptijd voor het geheel niet al te lang is
Maar als de klus groter is en de aanpak er niet in voorziet dat je:
- Voeling houdt met de aard van het probleem dat je op wil lossen
- Kunt bijsturen, aanpassen of redelijk schadevrij terug-naar-af kunt gaan
("Wrong forest!", "shut up, we're making progress!")
Dan loop je grote kans veel tijd en geld te spenderen aan iets dat uiteindelijk de plank flink
mis slaat. En dat wil je voorkomen.
Waterfall als term is ook maar verzonnen door mensen die het iets anders wilden doen.

7. Business goals
Technology
User goals
Tuesday, July 2, 13
Dit is mijn opdracht als UX designer. Help de organisatie concrete meetbare doelen te
formuleren. Zoek uit hoe de klant haar klanten hier over denken en wat ze er van verwachten.
Houd rekening met technische (on)mogelijkheden

8. Proces
Tuesday, July 2, 13
Statisch wireframes, designs in photoshop alleen voldoen niet meer.
Meer agile! Lean! reduceer waste en focus op zsm Business value te leveren.
Welk proces zet je in om uit te vinden of die sweet spot er is en waar die dan zit?
How do you get to that understanding?
That's where the design process comes in. Because design is how it works.

9. Design proces
Tuesday, July 2, 13
Want design gaat over hoe het werkt
Je ziet hier waarom de eerste fase vaak ook wel de discovery phase genoemd wordt.
Door het design proces toe te passen

10. P.I.S.A
‣ Probleemstelling
‣ Inventaris
‣ Selectie
‣ Arbitrage
Tuesday, July 2, 13
Ik zat op Kunstacademie hier in Rotterdam.
Vak dat heette letterlijk: conceptontwikkeling
Methode: P.I.S.A
Elke behalve laatste stap duurde twee weken.
6 weken druk met ‘scheuren’ of ‘stapelen’.
Vond het super lastig. 1 keer goed gescoord met een enorme uitvergroting van een vlek
currysaus…

11. Van niks tot getest
prototype in vijf
dagen
Tuesday, July 2, 13
Maar ik zie die stappen in dat PISA proces overal in terug komen.
Veel artikelen en boeken met het label ‘Lean’ in de titel raken ook aan deze aanpak.
Want weet je nog: we willen zo snel en zo slim mogelijk een concept ontwikkelen en kunnen
valideren.
Case study time! Ik heb onlangs met Natuurpunt (de belgische tegenhanger van
Natuurmonumenten) deze oefening gedaan. In 5 bijeenkomsten zijn we van word
documenten met high-level wensenlijst naar een getest prototype gegaan.
Je doet dit samen met de klant. Als designer wil je niet de wizard zijn die alles uit zijn hoge
hoed tovert maar je wil die discovery faciliteren.

12. Probleemstelling
Dag 1:
Business goals
Gebruikersdoelen:
persona, scenarios, epics
(& regel usability test deelnemers!)
Tuesday, July 2, 13
Wat wil de org bereiken? Lijst met business goals, prioritized
Wat komen de bezoekers halen? Wat moeten ze allemaal uitvoeren om dat gedaan te krijgen?
En regel usability test deelnemers!

13. Tuesday, July 2, 13
Zoals gezegd, samen met de klant. Dat zorgt voor betrokkenheid en maakt het minder nodig
om de resultaten nog weer eens in een verslag zus en een rapport zo uit te moeten werken.

14. Inventaris
Day 2:
Mindmap de content scope
Schets de schermen die
nodig zijn in het scenario
Tuesday, July 2, 13

15. Tuesday, July 2, 13
Plot zoveel mogelijk van wat je evt. te vertellen hebt.
Het is een inventaris, geen sitemap.
Je wil het hele terrein in beeld krijgen zodat je daarna de belangrijkste paden daar doorheen
kunt formuleren

16. Tuesday, July 2, 13
En dat is dan ook wat je daarna gaat doen
Heel high-level zagen we in dit geval 2 patronen:
- Mensen komen voor een suggestie waar van de natuur te gaan genieten (route, wandeling,
excursie, vakantie)
- Mensen komen met een specifieke hoe/wat natuur-vraag. Vaak met betrekking op de eigen
tuin.

17. Tuesday, July 2, 13
Ok, dan gaan we die twee paden wat beter in beeld proberen te krijgen
Je neemt de elementen uit die content map en zet ze wat gestructureerder bij elkaar.
Nu kun je benoemen welke stappen (= schermen) je nodig hebt om een bezoeker haar ding
te laten doen op de site.

18. Tuesday, July 2, 13
Voor elk van die schermen probeer je dan in snelle schetsoefening een aantal varianten te
bedenken.
40 tot 60 seconden per idee. Focus is op genereren van materiaal, we zitten in de inventaris
fase, remember

19. Selectie
Dag 3:
Review alle ideën met de
stakeholders
Beslis wat uit te werken
in het prototype
Tuesday, July 2, 13

20. Arbitrage, I
Dag 4:
Bouw het prototype
Met zoveel mogelijk
echte content
Tuesday, July 2, 13

21. Tuesday, July 2, 13

22. Arbitrage, II
Dag 5:
Usability test
Tuesday, July 2, 13
5 participants

23. Deliverables
Tuesday, July 2, 13
Deliverables, toch wel een van de ergste termen in de business vindt u niet?

24. Tuesday, July 2, 13
- Maak zo snel mogelijk ruwe versies van het gewenste eindresultaat
- Dit maakt het tastbaar en testbaar. Dit levert veel betere feedback op dan meningen over
een stuk documentatie

25. Tastbaar & testbaar
Tuesday, July 2, 13
In plaats van allerlei documentatie te genereren, maak het ding zelf zo snel mogelijk
tastbaar, testbaar.
Dit is echt super krachtig. Geeft klant iets om enthousiast over te worden, kan makkelijk
intern doorgepresenteerd worden.
Geef je designers/frontenders ergens FTP toegang en laat ze mapjes met prototypes
uploaden. Geen version control, gewoon lekker hakken op “productie”. Houd het licht en
wendbaar.

26. Style tiles
Tuesday, July 2, 13

27. Style guide
Tuesday, July 2, 13
Niet alleen de diversiteit aan kanalen, schermformaten, maar ook simpelweg de
*hoeveelheid* content die ontsloten moet worden maakt het onmogelijk om voor alle
varianten een optimaal ontwerp
Ook het visueel ontwerp, de brand en de opbouw van de verschillende soorten pagina’s moet
voor het grootste deel opgevangen worden met “business rules”

28. Photoshop?
Tuesday, July 2, 13
Een veel terugkerend geluid op Frontend United in London was deze quote, oorspronkelijk
van Jason Santa Maria.
Het is niet productief om heel dogmatisch alleen maar te willen designen in de browser, om
altijd agile te willen werken etc. Je moet de tools gebruiken die het meest geschikt zijn om
het actuele vraagstuk mee op te lossen. Dat kan ook Photoshop zijn
Blijft verstandig om uiteindelijk te kunnen beslissen op basis van iets dat in de natuurlijke
habitat gezien en beoordeeld kan worden

29. Tools
Tuesday, July 2, 13

30. Tuesday, July 2, 13
Pen en papier.
- Schetsen is belangrijk. Beste manier om tot een goed idee te komen is door veel ideeen te
hebben. Meerdere opties verkennen is essentieel (I in PISA)
- Een van de meest productieve manieren van hardop denken
- Stelt je in staat om snel meerdere opties te verkennen
- Beeld maakt sneller concreet, minder ruimte voor verschillende interpretaties van hetzelfde
materiaal

31. http://mindnode.com//
Mindnode
Tuesday, July 2, 13
Mindmap applicaties zijn handig voor het snel uitzetten van vooral de high-level informatie-
architectuur.
In Mindnode kun je images in een item plaatsen. En links naar andere bestanden opnemen.
Bijvoorbeel de spreadsheet met gedetailleerde informatie over het content type dat op die
plek in de hierarchie gebruikt wordt.
Dit stelt je in staat snel te switchen tussen big picture en close-up detail info

32. Markdown
# Hello world
- Een lijstje
- Met *items*
## Gaaf man
Nou, eg wel **vet** cool
http://daringfireball.net/projects/markdown/
Tuesday, July 2, 13
Markdown. Nogal een succesverhaal onder geeks.
De meest lichtvoetige manier om gestructureerde content aan te maken.
Plain text is portable, compatible & flexible nietwaar.
Markdown voegt net genoeg structuur toe om ook machines iets te kunnen vertellen over de
structuur (semantics) van de inhoud.
Zonder het mensellijk oog in de weg te zitten

33. Pandoc
$ pandoc -s example.md -o
example.html -c style.css -B
header.html -A footer.html
http://johnmacfarlane.net/pandoc/
Tuesday, July 2, 13
Je kunt zelf je templates voor het html skelet definieren dat gebruikt wordt om de inhoud van
je markdown bestandje in te zetten.

34. Bootstrap?
Foundation?
Custom?
Drupal?
Tuesday, July 2, 13
Sure, SASS is tof etc.
Naarmate je prototype uitgebreider en complexer wordt en steeds dichter de beoogde
eindstaat bereikt wil je toch graag wat van dat werk over kunnen nemen voor de echte
implementatie.
Ben dit nog aan het uitzoeken met de front-enders. Ik hoor graag hoe jullie hier nu mee
omgaan.
Ook je prototypes uitwerken in Drupal zal alleen voor echt grote projecten zinnig zijn.
Voordeel is dan wel dat je meteen ook technisch je proof of concept hebt. Dat vindt de
business wel fijn om te weten, dat het technisch ook allemaal kan.
Maar vergeet niet dat het juist essentieel is om niet te verknocht te raken aan je prototype.
Net als schetsen op papier moet het geen pijn doen om het weg te gooien en opnieuw te
beginnen.

35. http://www.justinmind.com/
Tuesday, July 2, 13
Maar als je als designer (nog niet) overweg kunt met html en je hebt niet de beschikking over
een frontender die je kan helpen. Dan is het heus geen schande om nog eens een lekker
potje te wireframen. Als je de boel maar aan elkaar hangt en klikbaar maakt.
Omnigraffle en Axure zijn bekende apps. Ik kon nooit overweg met OmniGraffle, Axure werkt
goed maar kent u Prototyper van Justinmind al?
Beetje de Drupal onder de wireframing apps. Zeer krachtig, niet zo makkelijk.
Nieuwste versie van deze week introduceert responsive prototypes.

36. UX, IxD, IA…
Tuesday, July 2, 13
Designers bemoeien zich graag met alles.
User experience,

37. “A quick brown
fox jumps
over the lazy dog”
http://datenform.de/graphic-arrays.html
Tuesday, July 2, 13
Welk houvast heb je dan nog wel?
De content zelf.

38. Content modeling
http://alistapart.com/article/content-modelling-a-master-skill
Tuesday, July 2, 13
Dit is waarin Drupal uitblinkt nietwaar?
Content types, Fields, Views, meerdere display modes voor een content type. Display suite,
references, taxonomy
Hier is waar je je klanten kunt helpen zich op een constructieve manier voor te bereiden op
die gefragmenteerde werkelijkheid
En daarom is het dus zo belangrijk om met echte content te werken als je prototyped.

39. http://rosenfeldmedia.com/books/content-everywhere/
Content
everywhere
Sara Wachter-Boettcher
Tuesday, July 2, 13
Maar vooral, dat dit vraagstuk je ingang kan zijn om op concept en communicatie niveau de
klant te gaan helpen haar content klaar te maken voor de multi-channel wereld.
Mocht je er dus als primair technische partij over denken mee te gaan doen in de design fase,
begin met een goede informatie architect!

40. Dank u!
@royscholten
roy.scholten@wunderkraut.com
Tuesday, July 2, 13

41. Tuesday, July 2, 13

42. Links
‣ http://johnmacfarlane.net/pandoc/
‣ http://daringfireball.net/projects/markdown/
‣ http://www.justinmind.com/
‣ http://www.gadgetopia.com
‣ http://www.lullabot.com/blog/articles/deblobbing-your-
chunks-building-flexible-content-model
‣
Tuesday, July 2, 13

43. Tuesday, July 2, 13