Kleimodel in ontwikkeling (bron: BMW)

Je zou er bijna in willen gaan zitten, zo echt lijken ze: de volledig uit klei opgetrokken prototypes van auto’s, die in de automotive industrie worden gemaakt voordat modellen in productie worden genomen. De oeroude en kostbare ontwerpmethode staat nog steeds als een huis. Pas als de auto tot op een kwart millimeter nauwkeurig is gemodelleerd en afgewerkt met folies om de klei echt te doen lijken, als na vele iteraties helemaal duidelijk is hoe de auto eruit komt te zien, dan pas kunnen de executives hun goedkeuring geven en kan de productie beginnen, eerder niet. Er moet om de auto heen gelopen kunnen worden. Hij moet er echt uit zien, een 2D tekening kan niet op die manier worden beoordeeld. Het is interessant om een vergelijking met onze sector te maken.

Voor ons heeft het middel ‘prototyping‘ zich al lang en breed bewezen. Wij laten graag zien aan klanten hoe ons ontwerpidee werkt. En dat doen we op veel manieren: van een serie schetsen, tot wireframes, tot klikbare, (eventueel) vormgegeven, aan elkaar gelinkte pagina’s die in een browser bekeken kunnen worden. We maken zelfs prototypes voor de iPhone die op het toestel zelf bekeken en ‘beleefd’ kunnen worden. Toch zien we in ons werkgebied nog veel te vaak anders. Met alle mogelijke gevolgen van dien: processen waar geen einde aan komt, enorme overschrijdingen van budgetten en slechte ontwerpen.

Waar gaat het mis? Volgens Bill Buxton, auteur van Sketching User Experiences is bij de ontwikkeling van softwareproducten de oorzaak vaak gelegen in het feit dat de ontwerpfase wordt overgeslagen en meteen wordt begonnen met het bouwen van de applicatie. Hij zegt:

“It is just as inappropriate to have an engineer manage the design process as it is to have a designer who graduated from art college be responsible for the product’s engineering.
[...] The bulk of our industry is organized around two all-too common myths: 1. That we know what we want to at the start of a project, and 2. That we know enough to start building it.”

En daar wringt dus de schoen. Aan het begin van het proces is bijna nooit duidelijk wat er gemaakt gaat worden. Bij het ontwerpen van auto’s wordt al 2,5 ton uitgegeven aan het maken van één kleien model, en dat alleen maar aan de vorm van de auto. Dat zijn enorme bedragen, en toch is het niks vergeleken bij de kosten die gemaakt zouden worden als niet voor deze methode was gekozen. Waarin maakt het werken met prototypes dan precies het verschil?

Waarom prototypen?

De belangrijkste eigenschap van prototypes is dat ze ideeën concreet maken. Prototyping is een manier van communiceren. Het zorgt ervoor dat ontwerpers nadenken over de manier waarop het concept moet werken. Het geeft antwoord op vragen die ontstaan tijdens het ontwerpproces. Prototypes zijn goedkoop, snel te maken en aan te passen en naast het beantwoorden van vragen, genereren ze ook nieuwe ideeën. Toegepast in een iteratief proces, dat wil zeggen, in een zichzelf herhalend proces van ontwerpen, gebruiken en analyseren, groeit een ontwerp en wordt steeds duidelijker wat het moet doen, voordat het daadwerkelijk gebouwd wordt.

Prototyping is voor ons als ontwerpers onmisbaar om verder te geraken in een ontwerpproces. We geven elkaar feedback aan de hand van de prototypes die we maken. Het mooie van een interactief document boven statische wireframes is dat veel beter een beeld gekregen kan worden van de structuur en werking van wat we maken. Er kan door een klikbaar prototype heen worden gelopen (zoals om het kleien model van de auto heen kan worden gelopen). De interactie die plaatsvindt komt dicht in de buurt bij de ervaring van het uiteindelijke product. En dit kan worden getest, waardoor gemaakte keuzes kunnen worden bevestigd of herzien.

Het is uiteindelijk de klant die beslist. Hoe beter de werking en beleving van zijn product aan hem kan worden gedemonstreerd, hoe blijer hij uiteindelijk zal zijn. Vanwege de helderheid van de functionaliteit in het prototype weet hij wat zijn product zal gaan doen, wat er gebouwd gaat worden en hoeveel hem dat in grote lijnen gaat kosten.

Benieuwd wat voor prototypes wij maken? Een paar voorbeelden:

Skills online: Een e-learning portal voor het leren van vaardigheden voor opleidingen verpleegkunde op MBO- en HBO-niveau. Met het prototype (gemaakt in Adobe Fireworks) konden we een ingewikkeld navigatieprincipe demonstreren. Bekijk het prototype

Santander Nederland: Eén van de grootste verstrekkers van leningen in Nederland. We gebruikten dit prototype (in Adobe Fireworks gemaakt door Acato) om een gebruikerstest uit te voeren. Bekijk het prototype

Check uit: In samenwerking met Fabrique werkten we aan een jongerenportaal voor het Amsterdams Uitburo. Het prototype (Adobe Fireworks) geeft een goede indruk van de bewegende onderdelen en de interactiviteit. Bekijk het prototype

Gemeente Breda: Samen met Wortell hebben we aan verschillende serviceprocessen binnen de gemeente Breda gewerkt. De pagina’s binnen het prototype (gemaakt met Axure) zien er heel realistisch (net echt) uit. Bekijk het prototype

Binnenkort meer over prototyping. Dan zal Matthijs ingaan op de verschillende soorten software waarmee we onze prototypes maken.

Hieronder een voorbeeld.

Het grootste voordeel van userfly is dat het een goedkope en eenvoudige manier is om inzicht te krijgen in wat website-bezoekers zoal doen. Het vergt echter wel wat tijd om alle opnamen te bekijken en interpreteren.

Het grootste nadeel vind ik dat je alleen ziet wat een bezoeker doet, maar je mist daarbij de achterliggende gedachten, de mogelijkheid om vragen te stellen (en doorvragen) en de non-verbale communicatie.

Ik vraag me ook af hoe het zit met privacy; je zou kunnen meekijken hoe iemand zijn credit-cardgegevens aan het invullen is, bijvoorbeeld. Als je iets wilt testen dat niet ‘openbaar’ is (zoals een demo of bijvoorbeeld een intranet) heb je dat probleem in ieder geval niet. Hierin zit volgens mij ook de meeste toegevoegde waarde van userfly. Bijvoorbeeld door de userfly code toe te voegen aan een ‘live’ demo/prototype en je doelgroep (via e-mail, twitter, forumpost, etc.) te vragen een simpele, eenduidige taak uit te voeren. Als ze daarnaast ook nog wat feedback terugsturen kun je, door dit te combineren met de opnamen, al een aardig beeld krijgen. Je zou zelfs de feedbackmogelijkheid (en additionele vragen) al kunnen inbouwen in het prototype zelf.

Een gratis account geeft je de mogelijkheid om per maand 10 opnamen te bekijken, voor meer zul je moeten gaan betalen en dan kun je ook terecht bij concurrent clixpy.com

Contextmapping

Contextmapping is een methodiek voor het uitvoeren van contextueel onderzoek met gebruikers, waarin kennis wordt verworven over de gebruikerscontext van producten.
Zowel gebruikers als stakeholders nemen actief deel aan het ontwerpproces, zodat het ontwerp en gebruik van een product goed bij elkaar aansluiten. Behalve bij productontwerp is deze methodiek natuurlijk ook erg interessant bij het uitvoeren van service design trajecten. Uitgangspunten bij contextmapping zijn onder andere dat gebruikers de experts van de belevingen zijn, en dat context van productgebruik zo divers is dat een map nodig is.

Liz Sanders illustreerde dit door te vertellen over haar ervaringen bij architectenbureau NBBJ bij het ontwerpen van een ziekenhuiscampus voor veteranen. Sanders benoemde de overgang van ontwerpen voor o.a. communicatie, ruimte, interieur en informatie naar het ontwerpen van o.a. ervaringen, emotie, interactie en transformatie. Ook onderscheidt zij vormen van ontwerpvisualisaties voor verkopen en vertellen aan de klant (3D, fly-throughs), en visualisaties voor maken met als doel stappen nemen in het ontwerpproces (persona’s, experience models). Enkele voorbeelden van co-creatie methodes:

Visioning workshop

Scoping binnen een project van klant en gebruikers door woorden en beelden op een collage-achtige wijze in een grote cirkel te plakken. Ideeën binnen de bullseye zijn het belangrijkste.

Experience timelines

Een chronologische visualisatie van gebeurtenissen. Bijvoorbeeld zusters die de ervaring van een patiënt gedurende een bepaald tijdsverloop in beeld brengen.

2D participatory modeling

Voormalig patiënten bedenken de layout van de patiëntenkamer door gebruik van geschaalde 2D modellen. Met visualisaties van emoties en uitgebreide toolkits voorzien van klittenband.

3D participatory modeling

Hypothetische scenario’s uitspelen of maken van geschaalde 3D ontwerpen. Zo liet men verpleegsters de inrichting van een patiëntenkamer bedenken met poppenmeubels en meer abstracte onderdelen. Verpleegsters richten de kamers binnen 8 minuten in en vertelden hun verhaal aan de hand van de poppen in de kamers.

Lessons learned die Liz Sanders noemde zijn onder andere het belang van een cultuur waarbij ontwerpers open staan voor de inbreng van gebruikers en klant, en een bijpassende mindset. Nodig het ontwerpteam uit bij de co-creatie sessies, en geef ze het liefst een rol zoals aantekeningen maken of video opnemen. Betrek ze ook bij de voorbereiding. Het communiceren van resultaten als ontwerpers niet aanwezig zijn kan door een samenvatting te geven op een manier met impact, bijvoorbeeld video, en alleen met resultaten die op dat moment relevant zijn voor het team.

Na Liz Sanders vertelde Jacob Buur van het SPIRE research centre over ethnografische provocatie, een van de 7 onderzoeksgebieden van SPIRE. Jacob vertelde over de veldstudies die werden uitgevoerd bij het herontwerp van de ‘wastewater treatment plants’. Grootste obstakel bij het herontwerp was het verschil in inzicht hoe het werk verricht moest worden en hoe nieuwe oplossingen binnen bestaande werkculturen kon worden ingepast. Controleurs wilden liever buiten rondlopen dan de controle applicaties binnen in een controlekamer te bedienen.

Froukje Sleeswijk Visser heeft als eerste PhD. in contextmapping kort haar doctoral werk uitgelegd, waarbij in haar thesis 7 best practices worden benoemd. Tenslotte kwamen in de pecha kucha presentaties nog veel interessante voorbeelden van contextmapping voorbij. 10 oud-studenten vertelden over hun afstudeerproject en huidige professie in relatie met contextmapping.

Meer

Wil je meer lezen over context mapping, dan kan dat bij het ID-StudioLab.

Zie ook de doctoraal thesis van Froukje Sleeswijk Visser: ‘Bringing the everyday life of people into design
Aanvullend een impressie van De Waag van het TU symposium met een aantal handige do’s en don’ts bij contextmapping.

Update: This article is also available on the Adobe Developer Connection. The article is edited and therefore a better version of what you read here. Of course you are welcome to continue reading this page, result is the same!

Update: We are working with the patched version of Fireworks CS4 for a few weeks now and most of the problems are fixed. I removed the negative comments in this article on the bugs in CS4.

So, you are a designer. A concept-, interaction- or visual designer and you use Adobe Fireworks for sketching, wireframing, visual design and of course prototyping. Great choice. I have been working with this program for many years.  I think it is the most efficient tool for creating anything based on pixels and consisting of more than one screen. In this post I use Fireworks CS3, but you won’t have any problems creating something simular using CS4.

Lately we are working on quite some iPhone applications. We always aim to see the design we make on the device it is made for as soon as possible. For web design this is easy. Use the “preview in browser” function in FW. But for iPhone it is a bit harder. We created 320*480 png’s and synced these “photos” with the iPhone so we could get a bit of a feel of how it looks on the handheld. But we wanted more.

The idea

This is what you want:

• Click through the screens the way you normally do with a FW mock up.
• Make use of the full screen (no Safari buttons).
• Export directly from Fireworks without the need of changing CSS or HTML afterward.
• Opening the app from the home screen.
• Disable zoom.
• Be able to send links to every iphone without even be an official iPhone developer.

This is what you don’t want:

• Learn Objective C or depend on someone who can.
• Take many actions before you can actually see the screens on the device.
• Wait for a new screen to load every time you click a button.

This is what you might wish, but is a bit harder:

(we are working on it)

• Animations, within a screen or from screen to screen.
• Using real form elements (that trigger the default iPhone UI elements).

Demo

Time to try it out to get the idea. We made a little demo, this is what you do:

1. Be sure you are a fast network, Wifi or 3G with your iPhone
2. Open this link in Safari on your iPhone: http://www.unitid.nl/iprototype/demo (I usually mail links to myself and open them on the phone)
3. Follow the instructions.

This demo is made in Fireworks, with the help of PHP and jQuery. We tried using Axure, IUI and webapps.net as well, but did not succeed this far creating something that was really easy to make.

How does it work?

Just very quickly, I explain more in detail later on:

1. Download this zip file containing some folders with PHP files and jQuery.
2. Create the screens with FW like you normally do. Start with a 320*480 canvas and call the first page “index” (no capitals please!).
3. Use hotspots (instead of slices) for creating links to the different pages.
4. Export the mockup to HTML and images like you normally do to test the mockup in a browser.
5. Everything OK? Now export the file to Dreamweaver Library (.lbi) to
   the folder named “Library”.
6. Upload everything to a server that can execute PHP.
7. Get your iphone and visit http://www.yourwebsite.com/..path..to..iprototype/iprototype.

But how does it really work?

Technically speaking.  (if you are not interested, skip to “creating the mockup with FW“)

1. When you open the URL on the iphone, jQuery will check the height of the screen, so it knows if you already have added the link to your homescreen.
2. If not (screenheight is under 480px) it alerts you to add the link to your homescreen
3. If you enter the site from the homescreen, the height of your window is 480px. So jQuery gets the content of the mockup using PHP.
4. All .lbi files are loaded and changed a bit by PHP to correct path to images, remove unnecessary tags and change the links so jQuery can work with it. Also some DIV tags are wrapped around the images and the ID attribute is set to the name of the file.
5. jQuery hides all DIV’s found in the generated HTML, but makes the screen (page) named “index” visible.
6. Clicking the image maps (hotspots) on this image shows the DIV the URL links to.

Take a look at the source code of the files for even more details (I figured most of you are designers not interested so much in code, like myself most of the time)

Do it yourself

Download the files

Files in the zip

Download this zip and extract it to your hard-disk. All of these files have to be uploaded to a server, so make sure you can find them in your FTP client or put them directly on the server.  About the files in the folder “iPrototype”:

• index.html; the file the browser opens. The file contains some metatags, CSS, javascript and a call to the php file.
• The folder “includes”: A folder with some files needed for the prototype to work.
  • js/jquery.js: the javascript libary
  • icon.png: The icon that is put on the iPhone homescreen (you can change this)
  • functions.php: A file to read and modify the exported files from Fireworks.
• The folder “Library”: This is where you export your files to from Fireworks. (you can use these files to test, but you should delete these before exporting your own prototype)

Create the Fireworks PNG

If you are new to Fireworks, there are many tutorials to be found on the web. I won’t go into detail about how to use the program, but will point out a few important things for making prototyping for the iPhone work.

A great way to start is getting the iPhone UI elements from Metaspark (thanks for this guys!). Open Fireworks and create a new file setting the canvas to 320 by 480 pixels and name the first page “index”. This is important because otherwise you’ll get a black screen opening the first page on your iPhone.

Pages and hotspots

Fireworks makes use of pages. Every page can have its own graphics, buttons and settings. To be able to click through the screen, you need more than one page and link these pages together using hot-spots. This easiest way to create a hot-spot is to right click the element you want to be a button and select “insert hot-spot”. In the properties panel you enter the page name you want the button to link to. You can enter this manually or use the pull-down menu. If you create a link to a page that does not exist, you will see a black (or whatever background color you set) screen and you’ll have to reload the prototype. Make sure all links are correct. You can export the prototype as “HTML and images” to check everything in your favorite browser.

Creating the hotspots

Exporting to .lbi

Click “file>export” in Fireworks. Find the “Library” folder. Export the file as Dreamweaver Library Items. Dreamweaver library items are small pieces of HTML code that you normally insert into webpages and will update automatically, but forget about that. Other settings:  Don’t bother entering a “file name” as the files will be named after your pages, “Slices: None”, Check “Put images in subfolder (images)”, uncheck “Current frame only”. Hit “Export”.

Upload and view it on your iPhone

The message you get when opening in Safari

All files in the iPrototype folder should be on a server that can execute PHP. I normally use FTP in Dreamweaver to do this. Take your iPhone and navigate to the address, ending with /iprototype. Follow the instructions on the screen.

Having trouble?

Let us know! We can also create a prototype for you, or help out with the design, that is what we do!

EverSave

Het zorgt ervoor dat je open documenten van alle programmas automatisch opgeslagen worden, iets wat ik niet altijd doe (helaas) wanneer ik helemaal in een bepaalde workflow ben.

Voor Fireworks is het belangrijk dat je de methode “Save by simulating save shortcut” selecteert bij de Timer

Fivesecondtest.com

User testing komt tegenwoordig in vele smaken. In-lab of remote, moderated vs. unmoderated, enz.
Regelmatig kom ik nieuwe tools of technieken tegen die zeker de moeite van het vermelden waard zijn. Vandaag de eerste: Fivesecondtest.com

Fivesecondtest.com biedt de mogelijkheid om (‘unmoderated remote’) vijf-seconden-tests uit te voeren. Bij een ‘vijf-seconden-test’ krijgt een respondent gedurende vijf seconden één pagina te zien om zijn eerste indruk van de site boven water te krijgen. Gebruikers vormen zich in de eerste vijf seconden een oordeel over belangrijke aspecten van de website en deze kunnen met behulp van een vijf-seconden-test objectief en onbeïnvloed worden achterhaald. Meer over de vijf-seconden-test vind je in deze podcast van Jared Spool en dit artikel van Christine Perfetti.

Het is een eenvoudige techniek die niet veel tijd kost om uit te voeren en bovendien geïntegreerd kan worden met andere taken of manieren van testen. Met behulp van fivesecondtest.com wordt het helemaal een fluitje van een cent: screenshot uploaden, (enkele) gegevens invullen en de rest gaat vanzelf. Naast de ‘classic’ test biedt fivesecondtest.com nog twee typen tests:

• De ‘compare’ test waarbij twee verschillende afbeeldingen ieder tweeënhalve seconden worden getoond en vervolgens met elkaar worden vergeleken;
• De ‘sentiment’ test die de respondent bevraagt over de beste en slechtste onderdelen van de interface.

Een nadeel van fivesecondtest.com is dat de meeste bezoekers waarschijnlijk uit de usability-, design-, of marketing-hoek komen, dus helemaal objectief zal je ontwerp niet worden beoordeeld.