<?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; Debunking Lean UX Myths</title>
	<atom:link href="http://johnnyholland.org/series/debunking-lean-ux-myths/feed/" rel="self" type="application/rss+xml" />
	<link>http://johnnyholland.org</link>
	<description>It&#039;s all about interaction</description>
	<lastBuildDate>Mon, 11 Mar 2013 23:07:51 +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>Lean UX is Nothing New</title>
		<link>http://johnnyholland.org/2012/09/lean-ux-is-nothing-new/</link>
		<comments>http://johnnyholland.org/2012/09/lean-ux-is-nothing-new/#comments</comments>
		<pubDate>Tue, 11 Sep 2012 16:00:28 +0000</pubDate>
		<dc:creator>Jeff Gothelf</dc:creator>
				<category><![CDATA[Methods & theory]]></category>

		<guid isPermaLink="false">http://johnnyholland.org/?p=16792</guid>
		<description><![CDATA[One of the most frequent critiques I hear about Lean UX is that it’s not new and that designers have been working this way for years. ]]></description>
			<content:encoded><![CDATA[<p>If you’re one of the designers who have always worked this way consider yourself particularly lucky. The overwhelming majority of designers working today &#8212; those in the bowels of banks, pharma companies and within agencies &#8212; work in a very linear, document-heavy process that demands up front definition (typically in a silo), offers late or no customer validation and delivers a fraction of the right experience with no ability to react to change mid-stream.</p>
<p>What&#8217;s interesting here is that while this all seems tactical, by pushing for a collaborative, cross-functional process UX designers are becoming grassroots strategic players. They are shifting the culture of their organization one project team at a time and pushing for a more agile and sustainable process. As these techniques take hold, the organization becomes more productive, efficient and effective. The organizational perception of the UX designer becomes more of a design facilitator, a UX *leader* and ultimately a company leader. This is the grassroots success that buys strategic access at higher levels of the organization.</p>
<p>Ultimately it doesn’t matter whether Lean UX is something new or a tried-and-true methodology that’s been practices for years. Even less important is what name you or your organization give it. As long as you&#8217;re working in this collaborative, iterative fashion you are approaching validated designs in a much more efficient way and no one is going to criticize you for not “doing” Lean UX or Agile or Agile Fall or whatever you call your process.</p>
<p>By working this way you are building new communication channels with other practitioners in your organization. These new channels facilitate the building of shared understanding which does not always have to manifest as a written document. Sometimes a conversation, a whiteboard sketch, a phone call or meeting can serve the same purpose as a Word document.</p>
]]></content:encoded>
			<wfw:commentRss>http://johnnyholland.org/2012/09/lean-ux-is-nothing-new/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Prototypes Are Vehicles of Shared Understanding</title>
		<link>http://johnnyholland.org/2012/08/prototypes-are-vehicles-of-shared-understanding/</link>
		<comments>http://johnnyholland.org/2012/08/prototypes-are-vehicles-of-shared-understanding/#comments</comments>
		<pubDate>Tue, 28 Aug 2012 15:53:32 +0000</pubDate>
		<dc:creator>Jeff Gothelf</dc:creator>
				<category><![CDATA[Methods & theory]]></category>

		<guid isPermaLink="false">http://johnnyholland.org/?p=16790</guid>
		<description><![CDATA[One way to minimize time spent creating documentation that will rarely be read and will constantly need updating is by [...]]]></description>
			<content:encoded><![CDATA[<p>One way to minimize time spent creating documentation that will rarely be read and will constantly need updating is by creating prototypes. By creating a prototype of the primary workflow you&#8217;re currently working on, your team can center around the interaction design in that workflow. Conversation is facilitated around that deliverable and the team can start building as the design is further refined.<br />
The prototype allows work to begin as it is a primary vehicle for creating shared understanding. That shared understanding is the currency of Lean UX and, as such, is traded against the depth of the documentation required.</p>
<blockquote><p>The prototype allows work to begin as it is a primary vehicle for creating shared understanding.</p></blockquote>
<p>The more shared understanding a team has, the less it has to document and, most importantly, the faster it can start building products. These products will then get into customer’s hands faster increasing the pace with which the team learns whether or not their design hypotheses were accurate or not. The prototype helps facilitate the conversation upon which shared understanding grows. As edge cases and exceptions to the core flow are raised they are addressed in real time, during this conversation (with developers, stakeholders, product managers, et al) &#8212; sometimes that will require additional documentation, and sometimes it won&#8217;t.</p>
]]></content:encoded>
			<wfw:commentRss>http://johnnyholland.org/2012/08/prototypes-are-vehicles-of-shared-understanding/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>The Value of the Minimum Viable Product</title>
		<link>http://johnnyholland.org/2012/07/the-value-of-the-minimum-viable-product/</link>
		<comments>http://johnnyholland.org/2012/07/the-value-of-the-minimum-viable-product/#comments</comments>
		<pubDate>Wed, 25 Jul 2012 15:53:06 +0000</pubDate>
		<dc:creator>Jeff Gothelf</dc:creator>
				<category><![CDATA[Methods & theory]]></category>

		<guid isPermaLink="false">http://johnnyholland.org/?p=16797</guid>
		<description><![CDATA[The minimum viable product (MVP) is the bare feature set needed to prove out a hypothesis.]]></description>
			<content:encoded><![CDATA[<img width="220" height="160" src="http://johnnyholland.org/wp-content/uploads/2012/07/mvp.jpg" class="attachment-index-categories wp-post-image" alt="mvp" title="mvp" /><p>The MVP brings tremendous value to a team’s Lean UX practice but it&#8217;s critical to understand what &#8220;value&#8221; actually means and how context changes that meaning. Value for your usability test participant is different than value for your a/b test subject as it is for your product owner or CEO. Your MVP must vary as you move through the validation cycles from each of these consumers of that MVP to the next. The shorter those cycles can be, the less time you spend refining the wrong solutions and the more time you spend refining the more accurate hypotheses.</p>
<p>Laugero makes a strong case for the MVP in his article “Lean UX is Dead, Long Live Lean UX” with this line, “As a discipline, we UXers don’t typically think too much about cost and benefits. We’re not typically held accountable to profits-and-losses. But MVP’s are a good discipline for us — they make us think about how to cost effectively make good decisions. They reduce product strategy to its fundamentals — what features move the business forward, fastest. That’s not typically the way we think. [emphasis added]”</p>
<p>There’s a clear reason why many UX practitioners don’t often think this way. For years, we&#8217;ve been focused on delivering documentation as opposed to product experiences. These have been the measuring sticks by which we’ve been evaluated, hired and compensated. The strategic value of UX is hardly ever revealed in the depths of a design specification. We&#8217;ve not been afforded the opportunities to engage in conversation at this strategic level because most of our customers see us a pixel-pushers.</p>
<p>By bringing the validated learnings that come out of the Lean UX process to our teams and leaders we begin to shift the perception of UX design from a tactical craft to one that provides strong strategic insight and value. That value can be communicated in many forms. These communication deliverables are transient artifacts and should facilitate knowledge transfer when person-to-person conversation is not an option or is not sufficient.</p>
<p>That being said, getting caught up in the production of these artifacts buries the UX discipline under the label of document-creators. Instead, as each young UX professional learns the craft and begins to master the design of compelling, useful and usable products and services the strategic value of these outcomes quickly outweigh the actual pushing of the pixels. Lean UX provides today’s UX practitioners with a framework for becoming more agile in their practices, focusing their tools with targeted depth so as to minimize wasteful work, and create short feedback cycles that drive towards validated design concepts that solve big, hairy business problems. It is through these repeated, strategic successes that our discipline will become even more valuable to our organizations than it is today.</p>
]]></content:encoded>
			<wfw:commentRss>http://johnnyholland.org/2012/07/the-value-of-the-minimum-viable-product/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Lean UX Is Not Anti-deliverable</title>
		<link>http://johnnyholland.org/2012/05/lean-ux-is-not-anti-deliverable/</link>
		<comments>http://johnnyholland.org/2012/05/lean-ux-is-not-anti-deliverable/#comments</comments>
		<pubDate>Wed, 23 May 2012 18:35:28 +0000</pubDate>
		<dc:creator>Jeff Gothelf</dc:creator>
				<category><![CDATA[Methods & theory]]></category>

		<guid isPermaLink="false">http://johnnyholland.org/?p=16785</guid>
		<description><![CDATA[A lot of people now consider Lean UX to be solely a tactical “anti-deliverables” practice that seeks to reduce the number of wireframes and spec pages. While they are partly right, they are mostly wrong. Let me debunk some of the myths.]]></description>
			<content:encoded><![CDATA[<img width="220" height="160" src="http://johnnyholland.org/wp-content/uploads/2012/05/lean-ux.jpg" class="attachment-index-categories wp-post-image" alt="lean-ux" title="lean-ux" /><p>Reducing deliverables is only one relatively small benefit of shifting our mindset away from traditional UX practices and thinking “lean.” Some of the most ardent promoters of thinking lean, towards UX and other disciplines, are practitioners outside of the UX world. The cross-functional collaboration, constant communication streams and customer-validated learnings that Lean UX provides broadens the impact that UX has on an organization. It does so tactically but even more so strategically. Lean UX opens up the discipline and invites others in to engage and educate them in all the good, bad and ugly twists the UX discipline goes through to arrive at viable solutions.</p>
<p>In his recent post “Lean UX is Dead. Long Live Lean UX.” Greg Laugero noted, “Some tendencies within Lean UX treat deliverables and documentation as the equivalent of clerical work, or worse as “waste.” To me, systems with any strategic value to our organizations require you to think through complex user stories. This will require some thought experiments, many of which need to be written down and shared with others who are not part of the small, co-located team.” Let me be very clear: Lean UX is not &#8220;anti-deliverables.&#8221; It is a refocusing of UX efforts away from the documentation for which we’ve become known inside and outside organizations. It moves towards validating product hypotheses that relieve the organization of wasteful practices that include designing and building products and features customers don’t actually want. We achieve this by creating interactive experiences – the ultimate manifestation of our work – earlier and more quickly. Inevitably, as Laugero notes, we will have to create artifacts along the way. The focus should still be to design the best experience while minimizing the amount of time designing the wrong ones &#8212; not to design documentation that describes these design hypotheses.</p>
<p>We all face many challenges to successful team collaboration including working with distributed teams. Testing and communication to distributed teams requires different types of communication. However by facilitating these communications through regularly cadenced, cross-functional conversations, the depth and complexity of the documentation you&#8217;ll need to create will be diminished. Subsequently, any rework of that documentation will also be diminished. This is the waste that is being removed.</p>
<p>&#8212;&#8212;&#8212;&#8211;<br />
Thumb image<a href="http://www.flickr.com/photos/juhansonin/3513105397/"> NC-BY-2.0 by juhansonin</a></p>
]]></content:encoded>
			<wfw:commentRss>http://johnnyholland.org/2012/05/lean-ux-is-not-anti-deliverable/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
	</channel>
</rss>
