Architectuur in de digitale wereld/2010-11/begrippen/Ontwerpparadox

Ontwerpparadox

Je kunt de presentatie downloaden: Klik hier

Een woord vooraf

Deze pagina gaat over ontwerpparadox ofwel functionaliteitsparadox. Of er een verschil zit tussen deze twee termen is nog nader te bepalen, op deze pagina gaan we ervan uit dat er geen verschil tussen deze twee termen zit. Een term die wel mag worden onderscheiden van de hoofdterm is schijnbare ontwerpparadox, deze zal ook later worden toegelicht.

Een ontwerpparadox ontstaat als een artefact en een gebruiker in een bepaalde context worden geplaatst waarin het artefact niet (ideaal) gebruikt kan worden en waarbij de oorzaak hiervan binnen het ontwerp van het artefact zit. Hierbij kan een artefact een product zijn, maar ook een (deel)computerprogramma of systeem.

Plaatsing

Om een idee te krijgen waar je Ontwerpparadox moeten plaatsen, kun je kijken naar deze afbeelding:

Ontwerpparadox is dus een type ontwerpfout, waar bij het maken een product rekening mee moet worden gehouden dat deze kan ontstaan, zodat ze kunnen worden voorkomen.

Algemene definitie

Een ontwerpparadox is een situatie waarin de omgeving, toestand van de gebruiker of het gebruik de gebruiker belemmeren om het artefact te gebruiken op de gewenste manier.

Splitsing van definitie

Voor een ontwerpparadox gelden 1 of meer van de volgende beweringen:

1. Een ongewenste situatie waarin een beperking van de gebruiker de belemmering is het artefact gewenst te gebruiken.
2. Een ongewenste situatie waarin een kenmerk van het artefact de belemmering is het artefact gewenst te gebruiken.
3. Een ongewenste situatie waarin de omgeving van het artefact de belemmering is het artefact gewenst te gebruiken.

Toelichting

Vaak is een combinatie van twee punten de grondoorzaak van het probleem. Ook heeft de 'schuldvraag' invloed op welke punten van toepassing zijn. Er zijn argumenten te verzinnen waarom de ontwerper van een product verantwoordelijk is voor zijn product en paradoxen zou moeten voorkomen, maar daarentegen zijn er argumenten te verzinnen dan de gebruiker verantwoordelijk is voor de manier waarop hij het product gebruikt. Bekijk de voorbeelden om hier een beeld van te krijgen.

Voorbeelden

Uitleg voorbeelden

1. Lichtschakelaar:
   1. Context: donkere kamer, gebruiker komt kamer binnen.
   2. Contextartefacten: -
   3. Actie: de gebruiker ziet niets in een donkere kamer en tast in het donker naar de lichtschakelaar.
   4. Probleem: Ontwerpparadox: om de lichtschakelaar goed te kunnen vinden en te bedienen, moet die verlicht zijn en moet de lamp al aan zijn, als de lamp echter al aan is, heb je de lichtschakelaar niet nodig.
2. Tandpasta tube:
   1. Context: Tandpasta wordt gebruikt bij de activiteit 'tandenpoetsen'.
   2. Contextartefacten: tandenborstel, wastafel.
   3. Actie: na het opdoen van tandpasta, draait de gebruiker de dop terug op de tube met dezelfde hand als waar hij de borstel in vasthoud, de tandenborstel wordt hierdoor ook gedraaid en de tandpasta valt in de wastafel.
   4. Probleem: Procesontwerpfout: (Bij nader inzien is hier geen paradox aanwezig, enkel een product dat door veel mensen op manier X wordt bedient met als ongewenst gevolg Y.)
3. Leren handschoenen met gesp
   1. Context: activiteit handschoenen aandoen en sluiten. Eén handschoen is al aan. Handen kunnen koud zijn.
   2. Contextartefacten: -
   3. Actie: de gesp op de tweede handschoen sluiten met de hand die al een handschoen draagt.
   4. Probleem: Ontwerpparadox: om de tweede handschoen goed te kunnen sluiten, moet de gebruiker eigenlijk zijn eerste handschoen weer uit doen. Zo krijgt hij ze echter nooit allebei aan en dicht.
4. Mobiel beschermhoesje anti-slip
   1. Context: activiteit het aannemen van de telefoon uit een broekzak.
   2. Contextartefacten: broekzak
   3. Actie: de telefoon gaat af en de gebruiker wil de telefoon aannemen en moet het toestel hiervoor uit zijn broekzak halen, dit gaat moeilijk vanwege het beschermhoesje.
   4. Probleem: Procesontwerpfout: om de telefoon snel uit zijn broekzak te kunnen halen, moet de gebruiker de telefoon uit het hoesje halen, om dit te kunnen doen, moet hij het juist eerst uit zijn broekzak krijgen.
5. Uitschakel knop windows
   1. Context: computer, besturingssyteem, activiteit: het uitschakelen van een windows computer XP en eerder.
   2. Contextartefacten: windows xp computer, muis
   3. Actie: de gebruiker drukt op start om op afsluiten te kunnen klikken om de computer af te sluiten.
   4. Probleem: Ontwerpparadox: de gebruiker moet op start klikken om de computer te stoppen.
6. Software updaten
   1. Context: computer, werken achter de computer, gebruikmakende van programma's met update-mogelijkheid.
   2. Contextartefacten: computer
   3. Actie: de gebruiker start een programma op en het programma gaat eerst updaten of vraagt of hij nu mag updaten.
   4. Probleem: Ontwerpparadox: de gebruiker start een programma (en wil het programma dus gebruiken, daarom start hij het op), de gebruiker moet echter eerst updaten.
7. Mobiel
   1. Context: tijdens presentatie van derden, bij activiteit "mobiel stil zetten",
   2. Contextartefacten: mobiel, specifiek: htc desire Z met android (2011 jan)
   3. Actie: de gebruiker wil de presentatie niet onderbreken en wil daarom zijn mobiel op stil zetten. Na 3 à 4 keer op knop A te hebben gedrukt, staat de mobiel op stil. (Trillen.) Bij elke keer drukken maakt de mobiel echter een piepgeluid in de zaal.
   4. Probleem: Ontwerpparadox: om de mobiel op stil te kunnen zetten, maakt de mobiel eerst piepgeluiden.
   5. Extra: dit is een schijnbare ontwerpparadox omdat het inhouden van de knop A, de mobiel zonder piepgeluid op de trilstand zet. De gebruiker was hiervan niet op de hoogte. Het gebrek van kennis de gebruiker (en/of het gebrek van voorlichting op het scherm van de mobiel) is de oorzaak van de schijnbare ontwerpparadox.

Vragen

Welke problemen lost Ontwerpparadox op?

Ontwerpparadox zelf lost geen problemen op, het is namelijk zelf het probleem. Je bewust worden van het bestaan van zulke paradoxen (en veelvoorkomende ontwerpfouten) en de middelen hebben om ze vroegtijdig te kunnen herkennen, geeft ontwerpers van allerlei een extra competentie om frustratie of andere problemen bij gebruikers te voorkomen. Je ontwerpt toch iets omdat je iets beter wilt maken, niet omdat juist meer frustratie en lijden de wereld in wilt helpen.

Wat zijn de grenzen van het concept Ontwerpparadox?

Het is niet altijd eenvoudig ontwerpfouten van elkaar te onderscheiden en de schuldvraag is nogal een afleider. Je afvragen of de verantwoording van een ongewenste situatie bij de gebruiker ligt of bij de ontwerper, neemt niet weg dat er nog steeds een ongewenste situatie is. Als je iets een ontwerpparadox noemt, impliceer je eigenlijk al dat de verantwoording bij de ontwerper ligt.

Dit is ook precies de bestaansoorzaak van schijnbare ontwerpparadox. (Zie laatste voorbeeld). Ook hier is het antwoord op de vraag waar ligt de verantwoording een grijs gebied.

Daarnaast is een het vinden van ontwerpparadox volledig in de digitale wereld moeilijk aangezien dit meestal resulteert in een deadlock. Als je echter interactie tussen mens en machine erbij betrekt dan zijn er wel weer ontwerpparadoxen te vinden. Zie voorbeeld Afsluiten.

Hoe draagt het concept bij aan een goede Architectuur?

1. Door jou (ontwerper) bewust te laten worden dat ontwerpfouten bestaan.
2. Onzichtbare ontwerpfouten, van te voren zichtbaar maken.
3. Vooruitdenken, scenario's draaien.

Kortom: in het ontwerpproces rekening houden met de gevaren en stappen ondernemen om ontwerpfouten te voorkomen en meer te streven naar pure functionality by design en niet dis-functionality by design.

Tentative below this line. Je kunt beter nu niet verder lezen, want het gaat nog veranderen.

Sandbox

Terzijde:
Software kun je updaten, fysieke producten niet gemakkelijk en hebben last van het legacy-fenomeen. (Ook al is er een beter alternatief, het implementeren van het alternatief kost te veel geld / tijd et cetera. )