<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>iAllenkelhet &#187; Synve R. Fossum</title>
	<atom:link href="http://iallenkelhet.no/author/synve/feed/" rel="self" type="application/rss+xml" />
	<link>http://iallenkelhet.no</link>
	<description>En blogg fra Netlife Research</description>
	<lastBuildDate>Tue, 07 Feb 2012 13:54:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
		<item>
		<title>Brukervennlighet vs. Sikkerhet vol. 2</title>
		<link>http://iallenkelhet.no/2012/02/07/brukervennlighet-vs-sikkerhet-vol-2/</link>
		<comments>http://iallenkelhet.no/2012/02/07/brukervennlighet-vs-sikkerhet-vol-2/#comments</comments>
		<pubDate>Tue, 07 Feb 2012 09:00:20 +0000</pubDate>
		<dc:creator>Synve R. Fossum</dc:creator>
				<category><![CDATA[Ukategorisert]]></category>
		<category><![CDATA[Brukervennlighet]]></category>
		<category><![CDATA[passord]]></category>
		<category><![CDATA[sikkerhet]]></category>

		<guid isPermaLink="false">http://iallenkelhet.no/?p=12296</guid>
		<description><![CDATA[Brukervennlighet vs. Sikkerhet er en unyttig kamp. Ofrer du brukervennligheten så senker du den faktiske sikkerheten. Er det på tide å legge boksehanskene på hyllen? ]]></description>
			<content:encoded><![CDATA[<p>Det er ikke alltid man skal speide mot horisonten. Noen ganger kan det lønne seg å ta et tilbakeblikk. Viktige tema går ikke av moten sammen med forrige ukes vinner i Appstore. Lunsjpraten her på kontoret er ofte preget av hva vi driver med. Nylig kom vi inn på temaet sikkerhet og brukervennlighet. Dette skrev jeg en bloggpost om i 2008. Inspirert av mine kollegaer leste jeg den igjen. Dessverre er den like relevant i dag som for 3,5 år siden. Dermed drister jeg meg til et dypdykk i arkivet.</p>
<p><a href="http://iallenkelhet.no/2012/02/07/brukervennlighet-vs-sikkerhet-vol-2/boksehansker_liggende_620x300-1/" rel="attachment wp-att-12359"><img class="alignright size-full wp-image-12359" src="http://iallenkelhet.no/files/2012/02/boksehansker_liggende_620x300-1.png" alt="Boksehansker" width="620" height="300" /></a></p>
<h2>Brukervennlighet kan ikke ofres for sikkerhet</h2>
<p>Bloggposten <a title="Brukervennlighet vs. sikkerhet. En unyttig kamp. " href="http://iallenkelhet.no/2008/06/06/brukervennlighet-vs-sikkerhet-%E2%80%93-en-unyttig-kamp/">&#8220;Brukervennlighet vs. Sikkerhet. En unyttig kamp&#8221;</a> tok for seg hvorfor det er meningsløst å snakke om at man kan eller må ofre brukervennlighet på bekostning av sikkerhet. Hovedpoenget er at dersom man gjør en oppgave for vanskelig for brukeren så vil de finne på alternative løsninger som gjør oppgaven lettere.</p>
<h2>1000 Passord</h2>
<p>Et klassisk eksempel er passord. De fleste har flere passord og mange har vanskelige passord som i tillegg må endres ofte. Løsningen for de fleste er å skrive passordet ned på en Post-it. De fleste har denne hverdagshjelperen godt synlig plassert ved PC-en mens de litt mer innovative (?) har den under musematten, potteplanten, bildene av barna eller lignende. Noen igjen har samme passord på alt. Ingen av løsningene er spesielt sikre &#8211; og resultatet er da altså ikke at man har ofret brukervennligheten på bekostning av sikkerheten men at man derimot har senket sikkerheten på grunn av dårlig brukervennlighet. Her kan jeg anbefale en annen bloggpost fra skattekammeret &#8211; nemlig Monas <a title="Passordtyranniet" href="http://iallenkelhet.no/2006/08/27/passordtyranniet/">Passordtyranniet.</a></p>
<h2>Hodeløse oppdateringer</h2>
<p>Et annet eksempel er oppdateringer av operativsystemet. For å hindre at noen kan utnytte hull i systemet kommer det stadig oppdateringer etterhvert som hullene oppdages. For den jevne bruker kjennetegnes disse av en haug av bokser som støtt og stadig dukker opp. Med uforståelige tekster, utydelige funksjoner og dårlige timing antar jeg at de fleste ender opp med å gjøre som meg. De trykker ja eller nei i et vilkårlig mønster. Gjerne nei, dersom de tror det kommer til forstyrre dem i arbeidet.</p>
<h2>Brukervennlige sikkerhetstiltak</h2>
<p>Det er altså ikke mulig å snakke om å ofre brukerens behov når man skal designe en sikker løsning. Brukervennlige sikkerhetstiltak kjennetegnes av å:</p>
<ul>
<li>Være <em>enkle nok</em> til at brukeren ikke må ta snarveier.</li>
<li>Gjøre at brukeren forstår hvorfor han/hun må gjøre gjennomføre de handlingene de gjør.</li>
<li>Kommunisere hva som skjer. Det betyr å gi feedback til brukeren om når noe er sikkert eller ikke og hvordan ens handlinger påvirker sikkerheten.</li>
<li>Ta hensyn til at det å opprettholde sikkerhet er noe som skjer hver dag og gjerne i en travel hverdag. Dett er noe løsningen må ta hensyn til.</li>
</ul>
<h2>Dine skrekkhistorier</h2>
<p>Er du enig i at temaet tålte gjensyn? Forhåpentligvis er denne bloggposten latterlig overflødig i 2015, men jeg har en følelse av at det om 3,5 år fortsatt kan være et behov for en vol.3 av denne bloggserien. I mellomtiden samler jeg på skrekkhistorier.</p>
<p>Har du noen eksempler på hvordan brukerfiendtlige sikkerhetskrav fører til mindre sikre løsninger?</p>
<p>PS: Sikkerhet vs. Brukervennlighet er en meningsløs kamp men som andre kamper fører den ofte til at man får skjerpet argumentene og utfordret inngrodde oppfatninger. Webdagenes program har allerede begynt å lekke ut og her får du et hint til. Konseptet til Webdagene 2012 er preget av dynamikken i en debatt. Opplyst eller mer forvirret? Følg med på <a title="Twitter Webdagene" href="http://twitter.com/webdagene">http://twitter.com/webdagene</a></p>
]]></content:encoded>
			<wfw:commentRss>http://iallenkelhet.no/2012/02/07/brukervennlighet-vs-sikkerhet-vol-2/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Brukerundersøkelse + Innovasjon = Sant</title>
		<link>http://iallenkelhet.no/2011/11/29/brukerundersokelserinnovasjonsant/</link>
		<comments>http://iallenkelhet.no/2011/11/29/brukerundersokelserinnovasjonsant/#comments</comments>
		<pubDate>Tue, 29 Nov 2011 15:03:52 +0000</pubDate>
		<dc:creator>Synve R. Fossum</dc:creator>
				<category><![CDATA[Brukervennlighet]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Måling og analyse]]></category>
		<category><![CDATA[brukertesting]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[metode]]></category>
		<category><![CDATA[psykologi]]></category>

		<guid isPermaLink="false">http://iallenkelhet.no/?p=11542</guid>
		<description><![CDATA[Noen tror at en grundig analyse av brukerne og deres behov hindrer en i å designe noe nytt og revolusjonerende. Det er feil. Les mer om hvordan brukerundersøkelser kan støtte innovasjon. ]]></description>
			<content:encoded><![CDATA[<p>2008? Så gammelt? I bransjen vår er de digital løsningene omtrent like holdbare som en åpnet makrellboks på sydentur. Å komme på noe nytt er viktig.</p>
<p>Ironisk nok ser det ut til å være resirkulering av sitater når man snakker om innovasjon. To sitater brukes ofte for å illustrere noe av problemene man kan støte på når man driver med brukerundersøkelser.</p>
<blockquote><p><em>&#8220;If I&#8217;d asked my customers what they wanted, they&#8217;d have said a faster horse.”</em><br />
Henry Ford.</p>
<aside class="quote">
<blockquote>
<h3><em>You can’t just ask customers what they want (&#8230;). By the time you get it built, they’ll want something new.</em><br />
(Steve Jobs)</h3>
</blockquote>
</aside>
<p><em>“You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.”</em><br />
Steve Jobs.</p></blockquote>
<p>Jeg er helt enig i hva de sier. Det som får meg til å skyte ut piggene er når de blir brukt for å argumentere MOT nytten av å lære seg mer om hvem brukerne dine er og hva de gjør. Problemet ligger i at noen oppfatter at en grundig analyse av brukerne og deres behov hindrer en i å designe noe nytt og revolusjonerende.</p>
<p>Det er feil.</p>
<p>Gode brukerundersøkelser dikterer nemlig ikke noe som helst når det gjelder verken funksjonalitet eller design.</p>
<p>En god brukerundersøkelse skal rett og slett belyse problemområdet, vise hva brukernes behov er og tydeliggjøre hvilke oppgaver som skal løses, ikke hvordan de skal løses. Den skal informere, ikke diktere funksjonalitet og utforming.</p>
<p>Det vi trenger er et evidensbasert grunnlag for hva vi driver med og hjelpe oss til, som <a title="Eivind Lund - slutt å synse" href="http://iallenkelhet.no/2011/09/16/konsulenter-skjerp-dere/">Eivind Lund sa på Webdagene, ”å slutte å synse”</a>.</p>
<p>Vi skal vite.</p>
<h2>Brukerundersøkelser som støtter nytenkning</h2>
<p>Velg riktig metode for å få svar på det du lurer på.</p>
<p>Et vanlig problem er å ha overkonfidens på hvor gode data man får av metoder basert på selvrapportering. Ofte benytter man seg av metoder som intervju og spørreskjema når man egentlig burde sett på atferd.</p>
<p>Metoder som ser på atferd er for eksempel observasjon, søkelogger og annen webstatistikk, og ikke minst den gamle klassikeren brukertester. Det er en god ide å kombinere flere metoder for å kompensere for svakheter.</p>
<p>Se for eksempel <a title="Jakob Nielsens oversikt over metoder for brukerundersøkelser" href="http://www.useit.com/alertbox/user-research-methods.html">Jakob Nielsens oversikt over metoder</a>.</p>
<h2>Som du spør får du svar</h2>
<p>Spør kun brukerne dine om om ting de har forutsetning for å svare på.</p>
<p>Det betyr at du for eksempel ikke bør spørre om: Hvordan synes du test.no sine nettsider burde se ut? Brukerne dine kan masse om hva de vil utføre på siden din men de er sannsynligvis ikke den neste Steve Jobs.</p>
<p>Fokuser på oppgaver, ikke meninger.</p>
<p>Ikke forvent at brukeren skal komme med løsninger direkte.</p>
<p>Jared Spool sier det godt når han blir bedt om å svare på hva det største problemet for folk er når de gjør brukerundersøkelser: ”<a title="Adaptive Path intervju med Jared Spool " href="http://adaptivepath.com/ideas/e000516">I think probably the biggest thing is not understanding the difference between observation, inference, opinion, and recommendation. Those four things are quite distinct and independent of each other. And if you don’t realize there’s a difference, you tend to muddle them up, and then things get very confusing.</a>”</p>
<h2>Analyser brukerne &#8211; ikke løsningen</h2>
<p>Tenk smart når du analyserer data.</p>
<p>Du skal forsøke å forstå hva brukeren faktisk trenger og ikke nødvendigvis hva de sier at de trenger. Det er din jobb å skille tingene fra hverandre.</p>
<p>Analysen bør ende opp i et bilde av hvem brukerne dine er og hva oppgavene deres er. Dette er i tråd med <a href="http://www.gerrymcgovern.com/" title="Gerry McGovern">Gerry McGovern</a> sitt poeng når han mener at vi må slutte å tenke informasjon og heller fokusere på oppgaver.</p>
<p>Presenter analysen på en slik måte at den åpner opp for å tenke nytt. Hold fokus på brukernes forutsetninger og oppgaver. Ikke bland inn meninger eller beskrivelse av design og teknologi.</p>
<h2>Brukerundersøkelse + Innovasjon = Sant</h2>
<p>For alle som liker å VITE hva man driver med og ikke GJETTE så anbefaler jeg å børste støv av de gode gamle metodene.</p>
<p>Brukerundersøkelse + Innovasjon = Sant (såfremt du vet hva du driver med)</p>
]]></content:encoded>
			<wfw:commentRss>http://iallenkelhet.no/2011/11/29/brukerundersokelserinnovasjonsant/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

