Responsive design, development en content in één flexibele aanpak

Hoe ontwerp en ontwikkel je een website, intranet of extranet voor zowel desktop als mobiel, tablet, TV en andere devices? Een hot topic, ook hier op Frankwatching. De traditionele ‘waterval’-aanpak is wat ons betreft verre van ideaal. In dit artikel stellen wij daarom een nieuwe aanpak voor: het ‘sustainable‘-model.

Onze ervaring is dat de traditionele ‘waterval’-aanpak te lang duurt, te duur is, niet efficiënt genoeg werkt én te weinig grip geeft op het eindresultaat als je voor responsive webdesign gaat. Maar alternatieve aanpakken passen niet altijd bij ons als professionals en zijn vaak te beperkt, bijvoorbeeld omdat ze strategie achterwege laten. Daar komt bij dat iedereen wel ‘content first’ zégt, maar niemand het daadwerkelijk dóet. Dat kan en moet anders. We introduceren dan ook één agile aanpak voor strategie, responsive design, development én contentproductie: het ‘sustainable’-model.

Ontwerpen en ontwikkelen voor mobiele toepassingen

Eerder deze maand schreef Anne-Roos Hassing ‘Van mobile first naar content first’. Een interessant artikel, waarin ze de vraag stelt: “Wat is de juiste manier om te ontwerpen voor mobiel?” Vervolgens gaat ze in op heel interessante onderzoeksresultaten van Google en benoemt ze technische en functionele aspecten “zoals locatiebepaling of cameratoepassing”.

Anne-Roos benoemt ook enkele stappen voor een aanpak om voor mobiel te ontwerpen:

1. Content is het uitgangspunt en alle content is via elk device toegankelijk.
2. Prioriteren van content/functie naar devices op basis van gebruikerstaken.
3. Optimaliseer voor de verschillende gebruikersmomenten per device.

(Of alle content altijd op alle devices toegankelijk moet zijn, is de vraag; over ‘responsive content’ schreven we al eerder op Frankwatching én op .Net Magazine. Punt 2 zijn we het van harte mee eens: ook over hoe je van toptaken een succesvolle site (of intranet) maakt, publiceerden we al eens.)

Hoewel deze 3 stappen zeker hout snijden, vinden wij ze wat al te high-level. Wij misten bovendien wat eigenlijk het antwoord op die vraag zou moeten zijn: hoe ontwerp en ontwikkel je nu voor mobiele toepassingen? Waarbij onze aandacht in eerste instantie niet uitgaat naar apps, maar juist naar het web.

Traditionele aanpak voor webdesign en development…

De afgelopen 10 à 15 jaar hebben de meeste van onze vakgenoten websites, intranetten en extranetten ontworpen en ontwikkeld volgens grofweg deze stappen:

• Doelgroeponderzoek
• Online strategie/contentstrategie
• Informatiearchitectuur en interactieontwerp
• Grafisch ontwerp/webdesign
• Frontend- en backenddevelopment

Die aanpak bleek prima te voldoen en leverde, binnen een overzichtelijke periode en tegen (meestal) acceptabele kosten, een heel goed werkbaar eindproduct op. Waarbij contentproductie doorgaans in een parallel traject plaatsvond, in ons geval soms alleen door onze opdrachtgever zelf, maar vaak ook in samenwerking met onze collega’s.

 

… duurt te lang, is te duur en niet effectief als je responsive gaat

Toen we aan de vooravond van ons eerste responsive project stonden, hadden we al snel in de gaten dat die oude watervalmethode niet goed was. Want normaal gesproken ontwikkel je voor een desktopsite een interactieontwerp van bijvoorbeeld 15 templates in Axure of een vergelijkbare tool, en vervolgens maak je voor diezelfde 15 templates grafisch design in Photoshop. Daar ben je dan bijvoorbeeld 4 weken zoet mee, inclusief correctierondes, enzovoort.

Maar nu moet je nu niet alleen voor desktop, maar ook voor mobiel en tablet ontwerpen. Dan maak je dus ineens 3 x 15 = 45 templates in Axure en 3 x 15 = 45 designs in Photoshop. En dan hebben we het nog niet eens over verschillende typen mobiel en tablet, om van TV of gameconsole nog maar te zwijgen.

Bovendien blijf je in Axure en Photoshop aan het knutselen in statische bestanden, waar je vervolgens je ‘normale’ vertaling naar HTML/CSS van moet maken, voor mobiel, tablet én desktop. Op deze manier rijzen doorlooptijd (niet 4 tot 6, maar 6 tot 8 weken) én kosten van de traditionele watervalmethode (denk alleen maar eens aan de meer-uren) natuurlijk de pan uit. Terwijl de efficiëntie van het proces en (dus) de kwaliteit van het eindproduct (effectiviteit) vervolgens te wensen over laten. Je loopt op z’n minst dat risico.

Alternatieve aanpak voor responsive webdesign

Gelukkig zijn er heel veel slimme mensen in de wereld van design en development. Er wordt dan ook veel gezegd en geschreven over hoe je responsive dan zou moeten aanpakken. We lichten 2 voorbeelden waar wij brood in zagen, uit, van de verschillende aanpakken en workflows die we de afgelopen tijd tegenkwamen:

• Ontwerpen in de browser
• Maak het watervalproces responsive

Ontwerpen in de browser

Stephen Hay is spreker, schrijver en eigenaar van Zero Interface. Hij beschrijft zijn flexibele aanpak, ontwerpen in de browser, en spreekt daarover regelmatig op conferenties, bijvoorbeeld op Mobilism 2012.

In een aantal stappen verweeft Stephen het ontwerpen van wireframes en composities met front-end develoment:

1. Creëer wireframes in HTML en CSS
2. Vul wireframes met echte content
3. Maak een breekpuntindicatie
4. Schets, brainstorm en verwerk dit naar een conceptcomposities voor elk breekpunt.
5. Smeed de composities samen met wireframe naar een prototype in HTML (flexibel).
6. Betrek de klant en presenteer screenshots (!) van dit prototype.
7. Gebruik het prototype na goedkeuring als testmiddel.
8. Als alles naar behoren werkt, hergebruik je de meeste code in de ontwikkeling.

Deze aanpak heeft verschillende voor- en nadelen:

• Voordelen
  Er is weinig tijd nodig om composities uit te werken met bijvoorbeeld Photoshop. De meeste tijd gebruik je om code te kloppen, code die tijdens de implementatie voortdurend hergebruikt kan worden. Wijzigingen worden direct doorgevoerd voor alle schermformaten — je werkt immers in de browser. En vorderingen kun je eenvoudig presenteren, waardoor je opdrachtgever én je team betrokken blijven.
• Nadelen
  Ontwerpen in de browser brengt ook nadelen met zich mee. Niet iedereen kan de vertaalslag maken van code naar visuele composities en andersom.
  Sarah Parmenter, spreker, user interface designer en eigenaar van You Know Who wijdde hier een artikelaan. Zij zegt:

  My creative brain switches at the point when I open my HTML/CSS editor (Espresso), and starts thinking in terms of structure and how to achieve the look of my design using as much native CSS as possible. If I don’t have my design to follow, the whole process breaks down for me.

  Maar de aanpak van Stephen Hay mist ook de onderzoeks- en strategische componenten. En is daarmee dus eigenlijk incompleet.

Maak het watervalproces responsive

In mei schreef Travis Sheppard een uitstekend artikel op ReadWriteWeb over hoe je met relatief kleine aanpassingen aan het watervalproces, toch kunt ontwerpen en ontwikkelen voor meerdere schermgrootten. Hij benoemt 5 stappen:

1. Plannen (interactie)
2. Ontwerpen (design)
3. Bouwen
4. Testen
5. Wassen, spoelen en herhalen

Sheppard gaat dus uit van wat er is — de watervalmethode — en hij scherpt het proces aan op basis van de eisen die responsive webdesign stelt. Bijvoorbeeld: “Wireframes must represent different screen sizes, and therefore layouts must be fluid.” En net als Hay, zegt Sheppard: “Wireframes need to become prototyping tools rather than blueprints, and some development and testing is needed to ensure they’re fully functional across the display spectrum.”

• Voordelen
  Sheppards herhaling in het proces is volgens ons heel goed. Want hiermee incorporeert hij feitelijk interactie- en grafisch ontwerp in een agile of scrumaanpak, terwijl die methode traditioneel alleen voor technische development wordt gebruik.
• Nadelen
  Ook Sheppard slaat doelgroeponderzoek en (online- of content-)strategie over. Een misser. En als we dan toch scrum bezig zijn: we missen in zijn aanpak de planning en productie van tekst, beeld, video en infographics… dus contentcreatie.

Iedereen zégt ‘content first’, maar niemand dóet het

Met het inbedden van contentcreatie in een vernieuwde aanpak voor design en development van responsive sites, intranetten en extranetten, doe je wat talloze designers, developers en contentstrategen wel zeggen, maar eigenlijk niet doen: content namelijk een beslissende factor maken in wat je ontwerpt en ontwikkelt. Jeffrey Zeldman zei het al:

“Design in the absence of content is not design”

De discussie over responsive webdesign wordt gedomineerd door designers en developers. En hoewel we het meeste van wat zij zeggen beamen — van de goeden in elk geval, zoals Brad Frost, Jeremy Keith, en Josh Clark: thumbs up — vinden we hun dominantie niet goed. Waarom? Omdat er lang niet genoeg gezegd en geschreven wordt over waar content écht over gaat — daar schreven we op Frankwatching al verschillende keren over — namelijk niet over dimensies, verhouding tot functionaliteit, enzovoort, over betekenis, boodschap en het bouwen van relaties met echte mensen.

Daarom pleiten we ervoor om contentproductie in dezelfde aanpak mee te nemen, en niet losstaand, parallel te doen.

Eén aanpak voor een ‘sustainable’ website of intranet

Met onze collega’s hebben we een nieuwe aanpak uitgewerkt die we de afgelopen tijd al verschillende keren in de praktijk hebben gebracht. En die we de komende maanden allicht nog finetunen op basis van de ervaring die we ermee opdoen om er vervolgens zeker op terug te komen hier op Frankwatching. We noemen die aanpak voorlopig ‘sustainable’, omdat we verwachten dat hij voldoende weg blijft van schermgrootten, devicetypen, enzovoort, en (zo) future-friendly genoeg is om ‘houdbare’ ofwel sustainable websites, intranetten en extranetten op te leveren.

Vertrekpunt voor onze sustainable aanpak is wat Jesse James Garrett, medeoprichter en president van Adaptive Path, beschrijft in zijn boek ‘The elements of user experience. User-centered design for the web‘, namelijk de 5 ‘planes’:

1. Strategie
2. Scope
3. Structuur
4. Skelet
5. Surface

We hebben deze ‘planes’ benaderd als fasen, als stappen in onze aanpak. En we lichten deze 5 stappen hierna op hoofdlijnen toe.

1. Strategie
   Een goede site of intranet staat of valt met een scherp geformuleerde strategie. We onderzoeken de behoeften van de doelgroep, de (beleids)plannen van de organisatie en de trends in de omgeving van de organisatie én de doelgroep (het ecosysteem). De bevindingen leggen we, nadat we die stevig doorzaken met management en stakeholders, vast in een online strategie. Onderdeel van de online strategie, maar soms ook een afzonderlijke deliverable, is een contentstrategie: met welke content beantwoorden we wanneer aan welke behoefte van de doelgroep op welk platform? Hier komen persona’s, customer journeys en user stories om de hoek kijken.
2. Scope
   In de scopefase bepalen we de reikwijdte van het eindresultaat (dus niet van het project). We leggen dus functionele eisen en wensen vast, en stemmen ook de contentvereisten af met opdrachtgever en doelgroep. Zo bepalen we niet alleen wat er functioneel en technisch moet komen, maar ook welke inhoud — tekst, beeld, video — daarbij hoort.
3. Structuur
   Vervolgens geven we concreter vorm aan de website of het intranet. We werken een informatiearchitectuur uit (navigatiestructuur en taxonomie) en bepalen wat we noemen ‘content outlines’: welke content moet waar komen, wat is de boodschap, in hoeveel woorden/beelden, enzovoort. Daarna maken we een compositieontwerp. Hierin geven we aan welke content en functies waar moeten komen. En bepalen daarbij meteen hoe die blokken zich tot elkaar moeten verhouden op kleinere en grotere schermen (contentchoreografie). En tot slot gaat art director Flooraan de slag om de grafische stijl te bepalen. Dat doet hij op hoofdlijnen, wat in de praktijk betekent dat hij op basis van de huisstijl schetsen maakt van een homepagina en enkele subpagina’s. Idealiter doen we dit (ook) voor enkele schermformaten.(Overigens deden we onlangs een experiment met een team van 5 — art director, interactive designer, developer, contentspecialist en opdrachtgever — met als doel in een sprint van één dag een homepagina en een ‘gewone’ contentpagina te ontwerpen en ontwikkelen, en er content voor te produceren. De interactive designer richtte zich enkel op wireframes en front end, en de art director concentreerde zich volledig op grafische stijl. En opvallend genoeg bleek na die ene, korte sprint, dat de ontwikkelde CSS al zo’n stevig basis bood dat we de rol van de art director in volgende sprints terug zouden kunnen brengen tot die van adviseur.)
4. Skelet
   Vervolgens dient de skeletfase in wezen als voorbereiding op de eerste sprint (en is daarmee eigenlijk sprint 0 uit de bekende scrumaanpak). We maken een database-/informatieontwerp, een gedetailleerd interactieontwerp en gedetailleerd design van de verschillende componenten die we in sprint 1 willen ontwikkelen. En — heel belangrijk! — we ontwikkelen de content voor diezelfde sprint 1. Dat betekent tekstschrijven, fotografie en/of fotoredactie, zo nodig scriptschrijven, filmen en monteren, enzovoort. Waarom vóór de sprint? Als je contentproductie namelijk werkelijk tegelijk met interactieontwerp, design en front-end development doet, zitten ergens een keer mensen op elkaar te wachten. En omdat we ‘content first’ écht menen, maken we de content ook echt first.
5. Surface/sprints
   Hier wijken we vervolgens sterk af van wat Garrett beschrijft in zijn boek. Want Garretts methode was en is natuurlijk ontwikkeld als watervalaanpak. En daar willen we nu net vanaf. Dus wij noemen ‘surface’ liever ‘sprints’. En daarmee bedoelen we dus niet louter developmentsprints, maar sprints waarin we content produceren of finetunen, details van interactieontwerp en grafisch ontwerp (verder) uitwerken, en vervolgens front end en back end programmeren. Waarbij voor front end geldt dat we al gauw voldoende hebben aan de CSS en dus geen designer meer nodig hebben.

En daarna wassen, spoelen en herhalen in de volgende sprints.

Conclusie

Onze aanpak heeft verschillende voordelen ten opzichte van de traditionele watervalmethode waarbij je alleen een desktopvariant van een site of intranet ontwikkelt. De belangrijkste daarvan is natuurlijk dat je een responsive resultaat hebt dat onafhankelijk is van device en schermgrootte.

Maar zo’n een responsive site kun je ook volgens de watervalmethode ontwikkelen, hoor ik je denken. En dat klopt. Maar je zag in de plaatjes hierboven waarschijnlijk dat zo’n traject zo maar liefst 40% langer duurt. Terwijl je in zo’n langdurig proces volgens ons onvoldoende grip hebt op het eindresultaat.

In onze aanpak (zie hiernaast) houden we weliswaar dezelfde doorlooptijd voor onderzoek en strategie, maar dan gaan we juist sneller met compositieontwerp en art direction. En door in één sprint zowel contentproductie als interactieontwerp én bouw op te nemen, kunnen we sneller in de lucht met een responsive resultaat, dan met een traditionele aanpak voor louter desktop. Om natuurlijk aansluitend de overige content en functionaliteit te ontwikkelen, waaraan je opnieuw kunt schaven en bijsturen op basis van je bevindingen uit sprint 1, met een beter eindresultaat tot gevolg.

We zijn benieuwd naar wat je hiervan vindt. Waar schort het in onze aanpak misschien nog aan of zien we dingen over het hoofd? En heb je misschien andere ervaringen op dit vlak die je wilt delen? We zijn heel nieuwsgierig naar je reactie.