<?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>Johnny Holland &#187; mission critical</title>
	<atom:link href="http://johnnyholland.org/tag/mission-critical/feed/" rel="self" type="application/rss+xml" />
	<link>http://johnnyholland.org</link>
	<description>It&#039;s all about interaction</description>
	<lastBuildDate>Wed, 08 Feb 2012 18:15:24 +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>Designing alarms and alerts</title>
		<link>http://johnnyholland.org/2010/08/designing-alarms-and-alerts/</link>
		<comments>http://johnnyholland.org/2010/08/designing-alarms-and-alerts/#comments</comments>
		<pubDate>Mon, 23 Aug 2010 11:00:45 +0000</pubDate>
		<dc:creator>Mikkel Michelsen</dc:creator>
				<category><![CDATA[Digital UX]]></category>
		<category><![CDATA[Psychology]]></category>
		<category><![CDATA[Urban UX]]></category>
		<category><![CDATA[Alarm design]]></category>
		<category><![CDATA[Alerts]]></category>
		<category><![CDATA[Critical events]]></category>
		<category><![CDATA[Event handling]]></category>
		<category><![CDATA[mission critical]]></category>
		<category><![CDATA[User recovery]]></category>

		<guid isPermaLink="false">http://johnnyholland.org/?p=7546</guid>
		<description><![CDATA[<img width="220" height="160" src="http://johnnyholland.org/wp-content/uploads/2011/12/alarm.jpg" class="attachment-index-categories wp-post-image" alt="alarm" title="alarm" />Is your design resistant to failure? If a worst case occurs, can the user recover and regain trust in your [...]]]></description>
			<content:encoded><![CDATA[<img width="220" height="160" src="http://johnnyholland.org/wp-content/uploads/2011/12/alarm.jpg" class="attachment-index-categories wp-post-image" alt="alarm" title="alarm" /><p><a href="http://johnnyholland.org/wp-content/uploads/warning1.png"><img class="alignnone size-full wp-image-8296" title="warning1" src="http://johnnyholland.org/wp-content/uploads/warning1.png" alt="Warning sign for a road-cleaning machine" width="415" height="162" /></a><br />
Is your design resistant to failure? If a worst case occurs, can the user recover and regain trust in your solution?<span id="more-7546"></span></p>
<p>This article explores the case of warnings, alerts and alarms, and provides an introduction to the important factors in gaining user attention to failures or critical events – and how to deal with them. As designers, we all would like to focus on the “happy trail” through our system; but as many users will tell you, annoyances and obstacles to a pleasurable user experience is how a system handles errors and important events out of the ordinary.</p>
<h2>Alerts—an interaction design issue</h2>
<p>Alerts are used to give the user feedback about important events that need attention for some reason. This may mean errors, failures, breakdowns, or important changes that need action—or interaction. The term “alert” is used here to include different types of significant event feedback in order of criticality:</p>
<ul>
<li>Alarms</li>
<li>Warnings</li>
<li>Cautions</li>
<li>Advisory messages</li>
</ul>
<blockquote><p>The goal of the alert is to give users the ability to recover from important events. This is basically an interaction design issue.</p></blockquote>
<p>The goal of the alert is to give users the ability to recover from important events. This is basically an interaction design issue. When we study different cases of system breakdowns, an important commonality occurs. How users respond is often the make-or-break part of the event. Interaction design is a critical factor in empowering the user to do the right thing. Through design, we can facilitate users responding correctly to critical events.</p>
<p>For instance, the Chernobyl nuclear accident in 1982 was characterized by three important flaws in the security system that occurred simultaneously. Functionally, the reactor did not live up to minimum heat resistance requirements. In terms of personnel, the staff lacked sufficient training. But just as importantly, the staff ignored system warnings.</p>
<div id="attachment_7551" class="wp-caption alignnone" style="width: 310px"><em><em><a href="http://johnnyholland.org/wp-content/uploads/38361951.jpg"><img class="size-medium wp-image-7551" title="Chernobyl Reactor Accident" src="http://johnnyholland.org/wp-content/uploads/38361951-300x222.jpg" alt="Chernobyl Reactor Accident" width="300" height="222" /></a></em></em><p class="wp-caption-text">The 1986 Chernobyl reactor accident - a case of ignoring warnings</p></div>
<p>&nbsp;</p>
<p>Ignoring system alerts is an interaction design issue—proving an important point: the interaction design can cause the chain of events to occur—or, through the right design, break that chain and help users recover from failure.</p>
<blockquote><p>The interaction design can cause the chain of events to occur—or, through the right design, break that chain and help users recover from failure.</p></blockquote>
<p>Most of us will never work on systems with such a high degree of &#8220;criticality.&#8221; But we still for need to design alerts as feedback to important events, and regardless of the level of criticality, the alerts will determine users&#8217; ablility to recover. Thoughtful alert design helps that process; it supports the flow of work. This is why alert design matters.</p>
<h2>Make users act, not panic</h2>
<p>The first rule of alert design is to allow the display to trigger action, correction or recovery—as opposed to causing panic.</p>
<p>Compare it to a trip down the highway in your car. The kids are in the backseat. Suddenly, the engine compartment catches fire and starts to smoke heavily, with flames coming out the side. You brake quickly and pull over. How do you instruct your kids? What voice would you carry? You would probably use a firm voice, right? A raised voice, but controlled. “We need to get out now. Take it easy. Only through the right hand side door. Don’t run. It’s under control.” Your voice should not cause the kids to panic, only to act, and to act in the right way.</p>
<p>The above analogy is actually used when designing cockpit voice alerts. It is also the reason a female voice is often used in most voice alert settings. Users are somehow more prone to respond calmly to a female voice than with that of a male.</p>
<h2>Matching criticality to obtrusiveness</h2>
<p>When designing the actual feedback element, we can start by looking at visibility. With different levels of importance, how should the obtrusiveness be scaled? This leads us to another important rule in alert design:</p>
<p><em><strong>Match the obtrusiveness of the alert to the criticality of the event.</strong></em></p>
<p>Do not make the alert too obtrusive for trivial caution displays. On the other hand, avoid making the design of important alarms too &#8220;silent&#8221; to be noticed.</p>
<p>Obtrusiveness can be manipulated through specific design elements. Here are some of the major design aspects to manipulate:</p>
<ul>
<li><strong>Size and placement </strong>determine visibility.</li>
<li><strong>Colors </strong>signal criticality. Need I say more? Use red sparingly, and save it for high criticality alerts and to raise obtrusiveness.</li>
<li><strong>Static or dynamic</strong>. The eye catches movement. Raise obtrusiveness with animation and movement in general.</li>
<li><strong>Sound/voice</strong>. Sound is crucial. If the user is not looking at your display device, the will not notice the alert. This is why most alerts are also audible.</li>
<li><strong>Repetition</strong>: User might not catch the first alert.</li>
<li><strong>Permanence</strong>: Consider the case of missed alerts. User might not have noticed the alert the moment it occurred. By raising the amount of time the alert is displayed, obtrusiveness can be raised.</li>
</ul>
<p>An example of intelligent alert priority design is the cockpit warning and caution unit. Alert criticality is distinguished by sound, placement, color and size, yet integrated into a single sorted “inbox” concept, displaying all alerts in one location.</p>
<div id="attachment_8298" class="wp-caption alignright" style="width: 250px"><a href="http://johnnyholland.org/wp-content/uploads/a380-cockpit.jpg"><img class="size-full wp-image-8298" title="a380-cockpit" src="http://johnnyholland.org/wp-content/uploads/a380-cockpit.jpg" alt="A380 Cockpit" width="240" height="160" /></a><p class="wp-caption-text">Cockpit of an A380.</p></div>
<h2>Dismiss and act—or interact</h2>
<p>Depending on which system provides feedback, the user might have options to interact, or just options to “dismiss and act accordingly.&#8221; In less critical alerts, provide options for interaction: “Fix”, “Retry”, “Close valve”, “Show list”. This keeps the locus of control with the user and builds trust.</p>
<p>In alert dismissal, there are no particular actions to feed back to the system. In this case, combine the alert with a suggested action: “Engine is on fire. <strong>Exit car to the right.</strong>”</p>
<p><strong>Cry Wolf Syndrome</strong></p>
<p>The most common pitfall in alert design is to handle obtrusiveness and repetition incorrectly. If the alert is displayed too frequently, the user will become blind to the alert and will then ignore it. It also causes trust to be lowered for other types of alerts. “It does this all the time. I never listen to it anymore.”</p>
<p>The best way to avoid Cry Wolf Syndrome is to make sure alerts are easily dismissable, only occur and repeat when necessary, with the lowest possible interval, and are as obtrusive as their criticality warrants.</p>
<blockquote><p>Make every alert count.</p></blockquote>
<p>One design solution to Cry Wolf Syndrome is to create display permanence with less obtrusiveness for the same alert. This can be done automatically “docking” the alert as opposed to repeating it. The user will not be forced to interact with the alert—and possibly dismiss something of importance. Another strategy for avoiding the pitfall is to simply avoid the alert alltogether. Consider if the action or alert is necessary. Can response or interaction be automated—or avoided? This will typically prove to be the best solution to fight user blindness. Make every alert count.</p>
<div>Top photo by <a href="http://www.flickr.com/people/arenamontanus/" rel="cc:attributionURL">Anders Sandberg</a> <a href="http://creativecommons.org/licenses/by-sa/2.0/" rel="license">CC BY-SA 2.0</a></div>
<div>A380 photo by <a href="http://www.flickr.com/photos/83823904@N00/" rel="cc:attributionURL">Adam</a> <a href="http://creativecommons.org/licenses/by-sa/2.0/" rel="license">CC BY-SA 2.0</a></div>
]]></content:encoded>
			<wfw:commentRss>http://johnnyholland.org/2010/08/designing-alarms-and-alerts/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Interaction Design for Specialized Tasks</title>
		<link>http://johnnyholland.org/2009/11/interaction-design-for-specialized-tasks/</link>
		<comments>http://johnnyholland.org/2009/11/interaction-design-for-specialized-tasks/#comments</comments>
		<pubDate>Fri, 20 Nov 2009 10:49:29 +0000</pubDate>
		<dc:creator>Mikkel Michelsen</dc:creator>
				<category><![CDATA[Digital UX]]></category>
		<category><![CDATA[Psychology]]></category>
		<category><![CDATA[Urban UX]]></category>
		<category><![CDATA[friction]]></category>
		<category><![CDATA[mission critical]]></category>
		<category><![CDATA[professional]]></category>
		<category><![CDATA[simulation]]></category>
		<category><![CDATA[specialized]]></category>
		<category><![CDATA[training]]></category>

		<guid isPermaLink="false">http://johnnyholland.org/?p=4402</guid>
		<description><![CDATA[Specialized interaction design comes into relevance when user is subjected to prolonged or highly intensive periods of use on a particular system, typically as part of a professional workspace context requiring highly trained users for operation. It can be the transaction platform of a financial instrument trader, the word processor of a writer, the table of a DJ, the decision-making tool of a surgeon or the steering wheel of a Formula-1 racer.]]></description>
			<content:encoded><![CDATA[<img width="220" height="160" src="http://johnnyholland.org/wp-content/uploads/2011/12/wool.jpg" class="attachment-index-categories wp-post-image" alt="wool" title="wool" /><p>&nbsp;</p>
<p>No single user is “special” &#8211; or maybe <em>all </em>users are? Either way you look at it, we as interaction designers will encounter contexts of use or knowledge domains out of the ordinary at some point or other during our career. In my experience, designers need not apply magic tools when designing for special situations. It is however beneficial to bear in mind some core differences between specialized use contexts and the mainstream use of a mass consumer product such as a social networking site or a mobile phone. And that&#8217;s what I want to focus on in this article.<span id="more-4402"></span></p>
<p>In the digital work environment of a specialist such as the nurse, designing the patient vital sign monitor requires the interaction designer to use and apply domain-specific knowledge. “Systolic Blood Pressure” is not just a label in a list; you have to know what it <em>means</em>. And then you have to design what it means to the <em>nurse</em>.</p>
<p>So how can we design the best possible systems when faced with these special contexts? How do we ensure that interactive systems for specialized users do not become needlessly complex and difficult to use? This article provides an introduction to domain of specialized interaction design, and provides you with some key guidelines for a successful UX result.</p>
<h2>Designing for a particular context</h2>
<p>Think of a work arena or professional domain with highly trained users.</p>
<ul>
<li>What systems surround the user?</li>
<li>Are the systems interactive in nature?</li>
<li>What specific tasks will require a high degree of knowledge when performed?</li>
</ul>
<p><span style="color: #000000;">Any interactive device can be the subject of a “specialized” use context.</span>In the definition used here, the specialized interaction design comes into relevance when a user is subjected to prolonged or intensive periods of use on a particular system. And this is typically as part of a professional workspace. This context requires a highly trained user for operation. It can be the transaction platform of a financial instrument trader, the word processor of a writer, the table of a DJ, the decision-making tool of a surgeon or the steering wheel of a Formula-1 racer.</p>
<div id="attachment_4403" class="wp-caption alignright" style="width: 310px"><a href="http://johnnyholland.org/wp-content/uploads/a340_cockpit.jpg"><img class="size-medium wp-image-4403 " title="Airbus 340 Cockpit" src="http://johnnyholland.org/wp-content/uploads/a340_cockpit-300x294.jpg" alt="Ask yourself: what makes your user special?" width="300" height="294" /></a><p class="wp-caption-text">What makes your user special?</p></div>
<p>More and more domains of highly trained and demanding users become the subject of interaction design. Many specialized work domains were previously supported by fitting mass-produced systems to do the job; it has however become more commonplace to see interactive solutions targeted for particular contexts.</p>
<h2>A special body of knowledge</h2>
<p>The training or education of the specialized users is an important factor for consideration. The body of knowledge that can be presupposed for these users gives the designer many advantages in designing an efficient use of the system. To name a few:</p>
<ul>
<li>Specific domain symbology standards can contain important data or information, that otherwise would need extensive labeling and explanation;</li>
<li>Abbreviation or shortening words can make a lot of sense to trained users. This allows for more effective real estate distribution; such as referring directly to procedure numbers or shortname references – the user will know the reference through repeated training;</li>
<li>Features need not be that transparent &#8211; hidden shortcuts and interactive sequences can more easily be learned to support super-usage;</li>
<li>Guidance and supportive features can be kept to a minimum. This doesn&#8217;t mean the system doesn&#8217;t have to be learnable.</li>
</ul>
<div id="attachment_4412" class="wp-caption alignright" style="width: 310px"><a href="http://johnnyholland.org/wp-content/uploads/p1310237-copy.jpg"><img class="size-medium wp-image-4412 " title="APP6A Symbology" src="http://johnnyholland.org/wp-content/uploads/p1310237-copy-300x224.jpg" alt="APP6A Symbology - incomprehensible or very effective? This is an anti-amour unit." width="300" height="224" /></a><p class="wp-caption-text">Use of specialized symbology. Incomprehensible to outsiders but extremely effective to the domain user. Example shows APP6A; infantry, recon and anti-armour symbols.</p></div>
<p>The body of knowledge that supports the design process can also challenge it. No interaction designer can ever completely understand the work context of a surgeon or a pilot. A system that needs to be easily accesible to a user with multiple years of pre-training or education, interaction designers cannot target in early iterations without support. In addition, the world of the user can be hard to replicate or even physically see or visit.</p>
<p>For this purpose, it is very common to employ in-house domain experts. These domain advisors are not a part of the client product ownership but work closely with the UX and development teams. They are an indispensable part of designing the right solution for the end user.</p>
<h2>Trained users and steep learning curves</h2>
<p>A core difference when designing systems for special users is how the user accesses the learning curve of the system. A specialized interaction design can often suppose the end user to enter the interactive system relatively high on its learning curve through pre-training or guidance.</p>
<p>This fact allows the designer to avoid supportive low-barrier entry features that similar systems would require when designed for a broader field of users. The reduction in functional redundancy, that might make sense for exploratory use, appears as noise and friction to the trained user. The very design choice that makes an interactive system seem inaccessible to the untrained eye might be what actually makes it highly usable for prolonged use.</p>
<p><span style="color: #000000;">This can be seen </span>when designing the overall navigation structure of a specialized system. An effective design will remove most layers of navigation by avoiding steps, wizard-like interaction patterns, states and modes. Multiple systems can be placed side-by-side with positive result. This is why financial traders love multiple displays. Effective design occurs when striving to populate the first layer of navigation as much as possible.</p>
<h2>Challenging procedure</h2>
<p>Users within a specialized domain will often have developed a rigid doctrine or detailed procedures facilitating task completion. This can be both a help and a burden to the interaction designer. On one hand, a process can serve as a guideline for developing an efficient system since these procedures have been sharpened over years by multiple groups of users to yield maximum output. Best practices are common. For instance, a work hazard checklist can serve as an important tool when digitizing the workflow.</p>
<div id="attachment_4411" class="wp-caption alignright" style="width: 310px"><a href="http://johnnyholland.org/wp-content/uploads/853785_21738071.jpg"><img class="size-medium wp-image-4411 " title="Buttons" src="http://johnnyholland.org/wp-content/uploads/853785_21738071-300x225.jpg" alt="Avoiding friction: Populating the outermost layer of navigation entirely." width="300" height="225" /></a><p class="wp-caption-text">Populating the outermost layer of navigation entirely.</p></div>
<p>However, the same tool can hinder improvement to the everyday life of the user. In the case of a specific physical checklist, users can be highly resistant to change. Maybe less steps in the operation are needed with a digital device. Maybe they steps can be overlapped or re-ordered with a new interaction pattern. The digital tool might also automate some features. But this doesn&#8217;t matter &#8211; users have invested time and energy and the current procedure has become a natural and reflex-like part of work.</p>
<p>As an interaction designer, it then becomes essential to challenge the &#8220;way we do it&#8221; and reach the point of minimum justification for change.</p>
<h2>Designing for attention span</h2>
<div id="attachment_4417" class="wp-caption alignright" style="width: 310px"><a href="http://johnnyholland.org/wp-content/uploads/blood-pressure-monitor.jpg"><img class="size-medium wp-image-4417 " title="blood-pressure-monitor" src="http://johnnyholland.org/wp-content/uploads/blood-pressure-monitor-300x212.jpg" alt="Monitor for patient vital signs - focused and very short periods of use" width="300" height="212" /></a><p class="wp-caption-text">Monitor for patient vital signs - focused and very short periods of use.</p></div>
<p>Considering the attention span of the highly trained user is one of the key contributors to a successful design, and this design approach is not even specific to specialized users. The user directs varying amounts of attention towards any system we design. But for highly trained users, the difference can be more pronounced.</p>
<p>In the case of a system for analysis, such as the vital sign monitor, the specialist has a very low percentage of total work time dedicated to that system. Maybe the user just briefly turns to the display for look-up or analysis, then returns to the main task. The system becomes a supportive system for critical decisionmaking surrounding a different main task. For this, the interaction design must ensure easy access, very low friction and mostly no layers of navigation. Systems for monitoring can use sound effectively (but should be used scarcely) to direct attention.</p>
<div id="attachment_4416" class="wp-caption alignright" style="width: 310px"><a href="http://johnnyholland.org/wp-content/uploads/8635-711946.jpg"><img class="size-medium wp-image-4416 " title="ATC Workspace" src="http://johnnyholland.org/wp-content/uploads/8635-711946-300x199.jpg" alt="ATC workspace - a place of prolonged and intensive use" width="300" height="199" /></a><p class="wp-caption-text">The air traffic controller workspace - a place of prolonged and intensive use.</p></div>
<p>Other systems require prolonged periods with 100% of user attention directed towards the system, such as is the case with the air traffic controller workspace. In this case, the design of the screen must apply methods for noise- and stressfree visuals, but it can also be highly effective in the use of real estate. When anyone sits long hours looking at the same screen, small pixel changes are sufficient to indicate change or needed reaction. Combined with specialized symbology, content can be presented in surprisingly compact ways and still make a world of sense.</p>
]]></content:encoded>
			<wfw:commentRss>http://johnnyholland.org/2009/11/interaction-design-for-specialized-tasks/feed/</wfw:commentRss>
		<slash:comments>12</slash:comments>
		</item>
	</channel>
</rss>

