<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rss 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/" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" version="2.0">

<channel>
	<title>Agile Dossier » Meaghan Waters</title>
	
	<link>http://www.agiledossier.com</link>
	<description>Essays on Agile, Product Management, Teams, Trends and more</description>
	<lastBuildDate>Thu, 17 May 2012 14:37:30 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://feeds.feedburner.com/AgileDossierMeaghanWaters" /><feedburner:info uri="agiledossiermeaghanwaters" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><feedburner:browserFriendly></feedburner:browserFriendly><item>
		<title>Skills and Structure for Customer Experience Teams</title>
		<link>http://www.agiledossier.com/skills-and-structure-for-customer-experience-teams</link>
		<comments>http://www.agiledossier.com/skills-and-structure-for-customer-experience-teams#comments</comments>
		<pubDate>Sun, 27 Nov 2011 16:39:14 +0000</pubDate>
		<dc:creator>agilegeneralist</dc:creator>
				<category><![CDATA[Customer Experience]]></category>
		<category><![CDATA[Meaghan Waters]]></category>
		<category><![CDATA[New Product Development]]></category>
		<category><![CDATA[Product Manager]]></category>
		<category><![CDATA[Product Owner]]></category>
		<category><![CDATA[Trends in Agile Space]]></category>
		<category><![CDATA[UX team structure]]></category>
		<category><![CDATA[agile product development]]></category>
		<category><![CDATA[Agile Product Owner]]></category>
		<category><![CDATA[Org Model]]></category>
		<category><![CDATA[User Experience Teams]]></category>
		<category><![CDATA[UX Talk]]></category>

		<guid isPermaLink="false">http://www.agiledossier.com/?p=329</guid>
		<description><![CDATA[by Meaghan Waters  Introduction New Product Development (NPD) in large corporations are fraught with challenges, specially for products that involve user interface. What are the options available for the product team to arrange the specialized and coveted UX (User experience) folks? What kind of talent they should look for? And what are the pros and cons [...]]]></description>
			<content:encoded><![CDATA[<div class="tweetmeme_button" style="float: right; margin-left: 10px;">
			<a href="http://api.tweetmeme.com/share?url=http%3A%2F%2Fwww.agiledossier.com%2Fskills-and-structure-for-customer-experience-teams"><br />
				<img src="http://api.tweetmeme.com/imagebutton.gif?url=http%3A%2F%2Fwww.agiledossier.com%2Fskills-and-structure-for-customer-experience-teams&amp;style=compact&amp;b=2" height="61" width="50" /><br />
			</a>
		</div>
<p><em>by</em><strong> <a href="http://www.agiledossier.com/?page_id=22" target="_blank">Meaghan Waters</a> </strong></p>
<p><strong>Introduction</strong></p>
<p>New Product Development (NPD) in large corporations are fraught with challenges, specially for products that involve user interface. What are the options available for the product team to arrange the specialized and coveted UX (User experience) folks? What kind of talent they should look for? And what are the pros and cons of various structures used by different product teams? <a href="http://www.agiledossier.com/contributors" target="_blank">Meaghan Waters</a>, Experience Design Consultant with ThoughtWorks (she is based out of Australia), shares her thoughts and recommendations for agile product owners and managers in this concise yet thought-provoking article. You can reach Meaghan at mwaters@thoughtworks.com.</p>
<p><span id="more-329"></span></p>
<p>Almost everyone putting together a product development team (specially for products with user interface) these days will look to include some form of Customer Experience focus in the team. With the rapid rise of social media and crowd sourced recommendations, user experience and user interaction have become critical differentiators. This welcome demand has created an unwanted problem – <a href="http://jobs.thoughtworks.com/UK#ViewJob/159" target="_blank">supply</a>. How do you fulfill the need and how do you manage the UX teams? Specifically how do you manage these creative bunch within relatively  large organizations?</p>
<p>There are a number of facets in supplying UX (or customer experience, or experience design, or ) inside of a large corporation. The two critical ones that I wanted to touch on here are</p>
<ul>
<li>Individual skills – UX practitioners are not interchangeable: different UX  people can have very different skill mixes &#8211; the first question to ask is  how can you get the skill mix right?</li>
</ul>
<ul>
<li>Structure –Once  you’ve worked out the skill set, you have to figure out  how do you get these people to work together to deliver products across the organization.</li>
</ul>
<p><strong>Individual Skills</strong></p>
<p>One of the challenges of setting up and managing UX teams is that the skill sets are so diverse. The core competencies that are often seen in the UX space are</p>
<ul>
<li><a href="http://hbr.org/2009/03/ethnographic-research-a-key-to-strategy/ar/1" target="_blank">Ethnographic research</a></li>
<li>Behavioral data analysis</li>
<li>Usability testing</li>
<li>Interaction Design</li>
<li>Experience strategy</li>
<li><a href="http://en.wikipedia.org/wiki/Information_Architecture" target="_blank">Information Architecture</a></li>
<li>Content strategy/writing</li>
<li><a href="http://en.wikipedia.org/wiki/Graphic_design" target="_blank">Visual Design</a></li>
<li>Facilitation</li>
<li>Business and/or Systems Analysis</li>
<li>Front-end development</li>
</ul>
<p>Different practitioners will have more or less competency in different areas based on past experience and, to some extent, natural inclination. So you need to be careful looking for the right talent for your team. Firstly, you need to know what type of projects your team are going to be working on so that you know what type of skills are going to be in demand.</p>
<p>Are you mainly working on application projects? Then you probably don’t need a lot of depth in Visual Design or Content Strategy, but having people with Business Analysis, Interaction Design and Usability Testing skills could be key. However if more informational websites are going to be a major part of your work then having those Visual Design and Content Strategy skills are essential and you’ll probably want to add in Behavioural data analysis and strong Information Architecture skills as well.</p>
<p>Have a look at your current and projected program of work and analyze around the skills. Do not just say “I need 5 UX people to cover our 4 projects”. That’s just the way to a lot of pain &#8211; pain for the projects as they may not get what they really need, pain for the practitioner as they feel key skills are unused while others are not up to the project’s demands, and pain to the UX practice as a whole as the skills mismatch has led to the perception that UX can’t deliver.</p>
<p>Once you’ve got the overall skills mix sorted out and the number of people nailed the next thing you need to figure out is the type of work involved in these projects as that will help you in targeting the right experience level. Here is a basic rule of thumb to follow:</p>
<ul>
<li>Mainly procedural = more junior practitioners</li>
<li>Mainly original, complex work = more senior practitioners</li>
</ul>
<div>So, with all of this worked out you need to balance your team to ensure you’re going to meet the needs of your organization. My advice – be prepared to be flexible, unfortunately UX practitioners rarely turn up in the exact pre-mixed skill set that you’re really looking for. That is why structure is so important.</div>
<p><strong>Structure</strong> (or how do you organize and distribute these people for best results)</p>
<p>The structure really comes into play once you have UX practitioners (with different and relevant skill set) distributed across the organization are working on different products/projects. There are three standard models that can be used –</p>
<ul>
<li><strong>Centralised/Internal Agency</strong> – The UX practitioners are directly accountable to the central team rather than to the projects that they have been assigned to. The UX team is seen as a gatekeeper and bottleneck for development (of any form): organizations usually find a way around this (by hiring their own UX folks) and soon the UX team ceases to have real impact and meaning. Basically don’t do this, it doesn’t end well.</li>
</ul>
<ul>
<li><strong>Distributed amongst product teams</strong> – The only accountability for the UX folks is to the project teams or product groups that hired them. You seem to end up with a bunch of isolated individuals, turf wars and duplicated effort. It can kind of work but is not really reliable.</li>
</ul>
<ul>
<li><strong>Matrixed</strong> &#8211; is an effort to smooth out the rough edges in the other two: centralized hiring and career management but co-located with product teams. I’ve worked in and managed teams in all three different models and the Matrix is definitely the most effective way of delivering good products and long term value to the organisation as a whole. It’s also seems to be the way most teams effectively working in agile environments are organised. You get the necessary UX people directly involved with and able to respond to the projects needs as well as being able to leverage the large skill pool of the UX team as a whole when the project needs it.</li>
</ul>
<p><em>So how does a matrix model work? </em>I have made an attempt to show that in the image below &#8211; if not understood well, then there is always the text to follow that up.</p>
<p><a href="http://www.agiledossier.com/wp-content/uploads/2011/11/Matrix_UX.png"><img class="aligncenter size-medium wp-image-348" title="Matrix_UX" src="http://www.agiledossier.com/wp-content/uploads/2011/11/Matrix_UX-300x300.png" alt="matrix layout for UX" width="300" height="300" /></a></p>
<blockquote><p>An experienced UX manager hires, trains and manages practitioners as part of a central team. Knowing their skill set and the business need, the manager assigns practitioners to particular products or business functions.</p>
<p>Practitioners are assigned to projects for substantial amounts of time to build up domain expertise but are rotated amongst different projects to maintain perspective and to ensure an aligned experience is being delivered across the organization.</p>
<p>Priorities on a project are managed by project owner, with UX manager providing regular coaching, UX QA, and helping with synergies between different projects.</p>
<p>Supports the growth of junior practitioners while giving senior practitioners the degree of autonomy they prefer</p></blockquote>
<p><strong>To Summarize</strong></p>
<p>Managing the supply of UX practitioners is a tricky business but it can be solved by the use of those same techniques that have created the demand for UX in the first place &#8211; an ability to look beyond what the user says and uncover their underlying needs (the skills) and an ability to look at the overall system of use &#8211; not just one small piece (the structure).</p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://www.agiledossier.com/skills-and-structure-for-customer-experience-teams/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

