<?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>Tim Minor &#187; usability</title>
	<atom:link href="http://www.t75.org/category/usability/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.t75.org</link>
	<description>Web usability consultant</description>
	<lastBuildDate>Tue, 15 Jun 2010 12:43:00 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Bad user testing beats no user testing</title>
		<link>http://www.t75.org/2009/09/bad-user-testing-beats-no-user-testing/</link>
		<comments>http://www.t75.org/2009/09/bad-user-testing-beats-no-user-testing/#comments</comments>
		<pubDate>Tue, 15 Sep 2009 12:40:44 +0000</pubDate>
		<dc:creator>Tim</dc:creator>
				<category><![CDATA[usability]]></category>

		<guid isPermaLink="false">http://www.t75.org/?p=105</guid>
		<description><![CDATA[Jakob Nielson offers a great summary of why to do at least some user testing. Even if it&#8217;s poor, you&#8217;re likely to catch at least a few major errors. I believe that when deadlines are short and expectation high, even chatting through ideas with a colleague has its benefits.
Nielsen initially launched his &#8216;discount&#8217; ideas on [...]]]></description>
			<content:encoded><![CDATA[<p>Jakob Nielson offers a great summary of why to do at least <em>some</em> user testing. Even if it&#8217;s poor, you&#8217;re likely to catch at least a few major errors. I believe that when deadlines are short and expectation high, even chatting through ideas with a colleague has its benefits.</p>
<p>Nielsen initially launched his &#8216;discount&#8217; ideas on the world twenty years ago this month. So what&#8217;s changed in all that time?</p>
<p><q>It might be hard to appreciate today, but these ideas were heresy 20 years ago&#8230; it has come a long way since I launched it to a lecture room of maybe 100 or so people. On balance, I&#8217;m happy that I started this campaign and will continue the fight for simpler usability, more broadly applied.</q> <cite>Discount Usability: 20 Years, Jakob Nielsen</cite></p>
<p>Hear, hear!</p>
<p>Read more: <a href="http://www.useit.com/alertbox/discount-usability.html">http://www.useit.com/alertbox/discount-usability.html</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.t75.org/2009/09/bad-user-testing-beats-no-user-testing/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>In Favour of Complexity</title>
		<link>http://www.t75.org/2009/06/in-favour-of-complexity/</link>
		<comments>http://www.t75.org/2009/06/in-favour-of-complexity/#comments</comments>
		<pubDate>Wed, 24 Jun 2009 16:48:37 +0000</pubDate>
		<dc:creator>Tim</dc:creator>
				<category><![CDATA[thoughts]]></category>
		<category><![CDATA[usability]]></category>
		<category><![CDATA[google]]></category>
		<category><![CDATA[norman]]></category>

		<guid isPermaLink="false">http://www.t75.org/?p=93</guid>
		<description><![CDATA[I was fortunate enough to attend the sell-out ‘UX London’ conference at The Cumberland Hotel, Marble Arch this year (June 15th &#8211; 17th). It was the first conference if its type here in London aimed at user experience practitioners and ably presented by the good folk at Clearleft. There were some big names in attendance [...]]]></description>
			<content:encoded><![CDATA[<p>I was fortunate enough to attend the sell-out ‘<a href="http://www.uxlondon.com/">UX London</a>’ conference at The Cumberland Hotel, Marble Arch this year (June 15th &#8211; 17th). It was the first conference if its type here in London aimed at user experience practitioners and ably presented by the good folk at <a href="http://www.clearleft.com/">Clearleft</a>. There were some big names in attendance – both lecturing and running half-day workshops.<span id="more-93"></span></p>
<p>The conference ran over three information-filled days. Day One was lecture day, with inspirational talks from the likes of Peter Merholz, Luke Wroblewski, Dan Saffer, Jared Spool, Jeffrey Veen and most excitingly Don ‘The Don’ Norman.</p>
<p>Days Two and Three went into much greater detail, with interactive workshops covering all aspects of user experience practice; from sketching lessons to learning how organisations can make better decisions through design. In fact there were too many fantastic workshops to get around all of them and there were no “fillers”.</p>
<p>One of the highlights for me however was hearing Don Norman speak on Day One. The author of seminal books such as The Design of Everyday Things, Things That Make us Smart and more recently The Design of Future Things, Don is well known to all user experience architects and designers alike. The fact that his comments were Twittered with the hashtag ‘#TheDon’ just goes to show the affection and regard in which he is held.</p>
<p>Often the contrarian (“When everyone is asking for something, I tend to take the opposite approach”), Norman has recently caused minor storms by arguing that simplicity is highly overrated and that complexity is good thing. At first this approach feels wrong: as usability people, we are often in the habit of trying to make online experiences as simple as possible. Surely complexity can only harm the experience and put customers off?</p>
<p>Norman offers a familiar example of simplicity: the Google search homepage &#8211; often quoted as the epitome of the simple. Without a doubt, Google is by far and away the most popular search engine. And yet Yahoo! have the most popular homepage and it’s packed with information. Yahoo! is optimised for exploration, with Google it takes a little more work. You might argue that these two homepages are different products but the sheer popularity of  Yahoo! goes some way to show that complex pages are popular.</p>
<p>Another example: the iPhone is often touted as simple and consumer-friendly. And yet with a new software update, Apple has added 100 extra new features. How is this level of complexity compatible with the idea of a simple product? One might argue it’s because users have learnt how to use the device and are now demanding more advanced tools (like Copy and Paste).</p>
<p>There appears to be a fundamental conflict here: when asked, people will demand simplicity (“Why is it so hard to use?”, “Why can’t products be simpler?” [<a href="#references">1</a>]) but when you watch these same people comparing products side-by-side, it is the number of features that sell a product. People want more features even when they realise this must complicate the product. People believe that as you add features you add capability, thereby making more feature-laden products more desirable. However, as user experience professionals, we believe adding more features decreases usability. Both positions, Norman argues, are wrong. “We must distinguish complexity from confusion, perplexity, and unintelligibility. The goal is complexity with order, lucidity and understandability.”</p>
<p>People prefer complex things. If it’s too simple, it gets boring. Once a user gains experience with a product, the user moves into a new role; that of the Intermediate and suddenly their perception of what is complex changes.</p>
<p>An aside &#8211; roughly speaking, there are three classes of user: the Beginner, the Intermediate and the Expert. If we plot the number of people against perceived skill level, like most population distributions we get the classic statistical bell curve, with most users situated in the middle of the curve at ‘Intermediate’. It stands to reason therefore, that these are the users we should spend the most amount of time designing for. And yet it’s often the Beginners and the Experts who get the most attention. The Product Manager demands the Beginner must be able to hit the ground running and yet the engineer or developer, if left to their own devices, designs for their own skill-level – that of the Expert.</p>
<p>So how does Norman suggest we solve the complexity problem? Unsurprisingly the first approach should be through well-researched design. By modularising actions we can contain the complexity and by teaching users as they go, we can help them manage complex interactions.</p>
<p>I’ll leave the last few words to The Don himself: “Why are things so complex? Because the world is complex. Our tools must reflect reality. Complexity can be good, leading to a rich, satisfying life, filled with rich, satisfying experiences.&#8221;</p>
<p>And again: &#8220;The mark of the great designer is the ability to provide what people need without excessive complexity, without feature bloat. Simplicity should never be the goal. Follow the famous Einstein quote: “Everything should be made as simple as possible, but not simpler.” Complex things will require complexity. It is the job of the designer to manage that complexity with skill and grace.&#8221;[<a href="#references">2</a>]</p>
<p><strong>Thanks</strong></p>
<p>To <a href="http://www.lukew.com/ff/entry.asp?837">Luke W for his notes on the lecture</a> that were far more comprehensive than my own.</p>
<p>And to the <a href="http://search.twitter.com/search?q=%23TheDon">Twitterers</a> who helped refresh my memory.</p>
<p><strong id="references">References:</strong></p>
<ol>
<li><a href="http://www.jnd.org/dn.mss/simplicity_is_highly.html">http://www.jnd.org/dn.mss/simplicity_is_highly.html</a></li>
<li><a href="http://www.jnd.org/dn.mss/why_is_37signals_so_1.html">http://www.jnd.org/dn.mss/why_is_37signals_so_1.html</a></li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://www.t75.org/2009/06/in-favour-of-complexity/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>In a perfect world, no one would be able to use anything*</title>
		<link>http://www.t75.org/2009/05/in-a-perfect-world-no-one-would-be-able-to-use-anything/</link>
		<comments>http://www.t75.org/2009/05/in-a-perfect-world-no-one-would-be-able-to-use-anything/#comments</comments>
		<pubDate>Wed, 27 May 2009 08:24:04 +0000</pubDate>
		<dc:creator>Tim</dc:creator>
				<category><![CDATA[humour]]></category>
		<category><![CDATA[usability]]></category>
		<category><![CDATA[ux humour]]></category>

		<guid isPermaLink="false">http://www.t75.org/2009/05/in-a-perfect-world-no-one-would-be-able-to-use-anything/</guid>
		<description><![CDATA[Fantastic Dilbert cartoons at 90% of Everything this morning.
Dilbert on User Experience:
http://www.90percentofeverything.com/2009/05/26/dilbert-on-user-experience/
* The views expressed in this title are Mordac&#8217;s alone and do not represent my own&#8230;
]]></description>
			<content:encoded><![CDATA[<p>Fantastic Dilbert cartoons at 90% of Everything this morning.</p>
<p>Dilbert on User Experience:</p>
<p><a title="Dilbert on User Experience" href="http://www.90percentofeverything.com/2009/05/26/dilbert-on-user-experience/">http://www.90percentofeverything.com/2009/05/26/dilbert-on-user-experience/</a></p>
<p>* The views expressed in this title are Mordac&#8217;s alone and do not represent my own&#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://www.t75.org/2009/05/in-a-perfect-world-no-one-would-be-able-to-use-anything/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>How to turn a light off in the dark</title>
		<link>http://www.t75.org/2009/05/how-to-turn-a-light-off-in-the-dark/</link>
		<comments>http://www.t75.org/2009/05/how-to-turn-a-light-off-in-the-dark/#comments</comments>
		<pubDate>Sat, 02 May 2009 16:43:09 +0000</pubDate>
		<dc:creator>Tim</dc:creator>
				<category><![CDATA[thoughts]]></category>
		<category><![CDATA[usability]]></category>

		<guid isPermaLink="false">http://www.t75.org/?p=23</guid>
		<description><![CDATA[Hotel rooms present a variety of novel user-interactions to their often tired and stressed guests. But do travellers really value chic design and high-concept living when all they want to do is turn off the lights and go to sleep?

Hotels have been welcoming guests for many hundreds of years, and certainly since the invention of [...]]]></description>
			<content:encoded><![CDATA[<p class="intro">Hotel rooms present a variety of novel user-interactions to their often tired and stressed guests. But do travellers really value chic design and high-concept living when all they want to do is turn off the lights and go to sleep?<span id="more-23"></span></p>
<p><img src="/img/light-control.jpg" alt="Light control" /></p>
<p>Hotels have been welcoming guests for many hundreds of years, and certainly since the invention of the light bulb, interior and electronic design have been integral to the guest&#8217;s experience. You might have thought, therefore, that hotel designers have had a chance to get things right. However, contemporary hotels are under pressure to provide all kinds of modern convenience. From wifi and iPod connections to innovative, comprehensible controls for taps, heating, lighting, television, cable, telephones, room service and trouser pressing &#8211; all in one room, without cluttering the place up or making it look ugly.</p>
<p>I recently had the pleasure to stay in the centre of Barcelona, in a fantastic new hotel. I&#8217;ll leave their name out of it but in case you&#8217;re up on your &#8220;boutique&#8221; Barca residences, this one had an open air swimming pool on the roof…</p>
<p>The hotel was marvelous and the service was wonderful, so no complaints there. The problem came in the room when trying to control the lights. Surely the lighting problem has been pretty much solved by now &#8211; it can&#8217;t get much harder than on and off? Or can it&#8230;</p>
<p>The lighting system in our hotel room was incredibly counter-intuitive. Suffice it to say my girlfriend got extremely tired of me trying to work it out, especially when that meant my fiddling turned the lights on and off every five minutes. However, the usability issue that really caught my attention was this &#8211; why illuminate an off switch in the dark? Surely it would be much more useful to illuminate the &#8220;On&#8221; switch, so that when you&#8217;re desperately trying to creep to the bathroom in the middle of the night, you don&#8217;t have to fiddle about? I can only imagine the button was wrongly labelled and then wired in according to the incorrect label? Or does someone see a benefit that I&#8217;m missing?</p>
<p><img  src="/img/light-control-fixed.jpg" alt="Fixed light control" /><br />
<span style="display:inline;">The fixed control &#8211; pretty simple huh?</span></p>
<p>So, it was particularly interesting for me to hear the following <a href="http://www.uie.com/brainsparks/2009/04/03/userability-podcast-6-20-years-no-improvement/">UIE podcast</a> upon my return, where this sensible question was asked (and I paraphrase) &#8220;If Don Norman&#8217;s seminal <a href="http://www.jnd.org/books.html#33">The Design of Everyday Things</a> is twenty years old, why are simple design mistakes still being made?&#8221;</p>
<p>Let me know.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.t75.org/2009/05/how-to-turn-a-light-off-in-the-dark/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Poka-yoke</title>
		<link>http://www.t75.org/2009/03/poka-yoke/</link>
		<comments>http://www.t75.org/2009/03/poka-yoke/#comments</comments>
		<pubDate>Mon, 30 Mar 2009 01:02:34 +0000</pubDate>
		<dc:creator>Tim</dc:creator>
				<category><![CDATA[thoughts]]></category>
		<category><![CDATA[usability]]></category>

		<guid isPermaLink="false">http://www.t75.org/?p=9</guid>
		<description><![CDATA[Poka yoke, pronounced &#8220;POH-kah YOH-keh&#8221; — is a Japanese term that translates as &#8220;mistake-proofing&#8221; (from the Japanese yokeru (avoiding) and poka (inadvertent errors). A poka-yoke device is any mechanism that either prevents a mistake from being made or makes the mistake obvious at a glance. The idea is to prevent errors from being made in [...]]]></description>
			<content:encoded><![CDATA[<p class="intro"><a href="http://en.wikipedia.org/wiki/Poka-yoke">Poka yoke</a>, pronounced &#8220;POH-kah YOH-keh&#8221; — is a Japanese term that translates as &#8220;mistake-proofing&#8221; (from the Japanese <em>yokeru</em> (avoiding) and <em>poka</em> (inadvertent errors). A poka-yoke device is any mechanism that either prevents a mistake from being made or makes the mistake obvious at a glance. The idea is to prevent errors from being made in the first place, or if they are made, making those errors very obvious. The concept was formalised on the Toyota production lines by the Japanese industrial engineer <a href="http://en.wikipedia.org/wiki/Shigeo_Shingo">Shigeo Shingo</a>.<span id="more-9"></span></p>
<h3>Mistake proofing</h3>
<p>Shigeo Shingo defines three types of Poka-Yoke:</p>
<p><img class="floatright" src="../img/article-disk.jpg" alt="Floppy disk" /></p>
<ol>
<li>The <em>contact method</em> identifies defects by whether or not contact is established between the device and the product. Color detection and other product property techniques are considered extensions of this.</li>
<li>The <em>fixed-value method</em> determines whether a given number of movements have been made.</li>
<li>The <em>motion-step method</em> determines whether the prescribed steps or motions of the process have been followed.</li>
</ol>
<p>A familiar example of the poka-yoke philosophy is the 3.5&#8243; floppy disk. You probably won&#8217;t need reminding that the top-right corner is shaped in a certain way, meaning the disk cannot be inserted upside-down. Undoubtably helpful in all sorts of situations, so how can this be applied to the web and websites?</p>
<p>Certainly one the most frustrating objects encountered on many websites is the ubiquitous web form. Where ever you go on the web, a form is the most likely way you are going to interact, order, sign-up, comment or log in. There are server-farms full of pages on how to create html forms so I&#8217;m not going to go into code detail, but maybe it&#8217;ll be instructive to run through Shingo&#8217;s three types of poke yoka with respect to internet forms.</p>
<p>Our goal is to remove, or at least reduce, the number of errors occuring on our forms. Often sales or contacts are lost when users become frustrated by malfunctioning online forms. The more we can do to prevent mistakes in the first place, the less money we’ll spend fixing things later, and the happier our customers will be!</p>
<p>The 1-10-100 Rule states that as a product moves through the production system, the cost of correcting an error multiplies by ten. Ensuring an order is correctly entered costs us £1. Detecting an error at the billing stage costs £10. If the error isn&#8217;t caught in time and is passed on to the customer, that costs us £100 to fix. If we don&#8217;t fix it at that point and the customer complains to their friends, the cost can quickly escalate to £1000!</p>
<h3>The Contact Method</h3>
<p>This group of checks include “methods in which sensing devices detect abnormalities in product shape or dimension by whether or not contact is made” (Shingo). These methods are usually used to check size, shape, orientation, presence/absence, or appearance. They are also referred to as “physical poka-yokes”.</p>
<p>Although web forms don&#8217;t usually handle product shapes and physical objects, I think in this group we can include the following tests:</p>
<ol>
<li>always make sure an email address is correctly formatted (often acheived by testing the &#8217;shape&#8217; of the address, in that it contains an at symbol and a fullstop)</li>
<li>required fields must always be tested for the presence of a valid string</li>
<li>phone number fields must contain numbers</li>
</ol>
<h3>The Fixed-Value Method</h3>
<p>Fixed-value methods &#8211; or counting poka yokes &#8211; determine that a fixed number of movements have been made and is analagous to ensuring all your required fields have been completed. But they might also be seen in online games, or where users have to accept terms and conditions. A purchase-step progress bar could also fit into this category &#8211; those identifiers that graphically display your progress in an online transaction. They give you a count of how many pages you are away from completing your transaction, thereby providing some reassurance that progress is being made.</p>
<h3>The Motion-Step Method</h3>
<p>The third poka yoke method uses sensors to determine if a motion or step in a process has been completed. If the step has not been completed or has been completed out of sequence, a sensor signals the process should stop.</p>
<p>When applied to the web, you can quickly see who this can easily be enforced by a suitable linking strategy. Users should only be presented with links that are relevant to their current situation. And if they are about to make a purchase, don&#8217;t complicate matters with adverts that can distract and lead them astray.</p>
<p>If an email address has been entered incorrectly, ensure the user is made aware of that fact immediately, rather than when they submit the form.</p>
<h3>Summary and comments</h3>
<p>The concept of a poka yoke device is useful in reducing errors made by users. Reducing the occurence of errors leads to lower costs and happier customers. Poka yoke is well established in the industrial work place, applying the concepts to web pages isn&#8217;t a perfect fit but the essential principles can help establish good working practices that lead to improved user experiences.</p>
<p>Anything to add? <a href="mailto:tim@t75.org">Drop me a line</a> and if you aren&#8217;t a spambot I&#8217;ll add your comment below.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.t75.org/2009/03/poka-yoke/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
