<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Get Better Client Feedback Using Pain Charts</title>
	<atom:link href="http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/</link>
	<description>Ideas for building efficient developers and software</description>
	<lastBuildDate>Mon, 30 Jan 2012 11:03:44 -0500</lastBuildDate>
	
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Angela Watters &#187; Blog Archive &#187; Face in the Crowd</title>
		<link>http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-9936</link>
		<dc:creator>Angela Watters &#187; Blog Archive &#187; Face in the Crowd</dc:creator>
		<pubDate>Wed, 02 Jun 2010 21:57:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-9936</guid>
		<description>[...] the face to be a cross between the typical face of one of these little figures and a face from a pain chart in a doctor&#8217;s office or hospital.   Face in the Crowd &#124; 2010 &#124; Uncategorized &#124; Comments [...]</description>
		<content:encoded><![CDATA[<p>[...] the face to be a cross between the typical face of one of these little figures and a face from a pain chart in a doctor&#8217;s office or hospital.   Face in the Crowd | 2010 | Uncategorized | Comments [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin Deltener</title>
		<link>http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-358</link>
		<dc:creator>Justin Deltener</dc:creator>
		<pubDate>Fri, 12 Oct 2007 13:49:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-358</guid>
		<description>@Max

That clears up a bit more of your intent. In your article you mentioned using this in a client meeting. Are you implying a meeting where only a very specific set of metrics need to be measured to do some kind of preliminary data gathering before committing resources to a more in depth cycle?

When I first read this it scared me quite a bit. Yet another article trying to develop a programmatic means of abstracting raw binary data from clients. All too often developers and managers are emotionally disconnected from the people they work with. There is simply no substitution for a developer that has a direct, meaningful, deeply understood and empathetic connection to the client. You can&#039;t beat it. This of course takes years to develop as a skill for the resource and months to extend this kind of relationship to a new client but I think it should be all our goals to attempt. The net result of this relationship is obvious to the client, strengthens trust and ensures reciprocation of respect.

Being able to think on your clients behalf without having to bottleneck communication is absolutely invaluable. 

I can see using some kind of chart metric for purposely disposable clients, only if we all keep in sight the larger scope, long term objectives to be more personal and meaningful in our communications for the other 99% of out clients.</description>
		<content:encoded><![CDATA[<p>@Max</p>
<p>That clears up a bit more of your intent. In your article you mentioned using this in a client meeting. Are you implying a meeting where only a very specific set of metrics need to be measured to do some kind of preliminary data gathering before committing resources to a more in depth cycle?</p>
<p>When I first read this it scared me quite a bit. Yet another article trying to develop a programmatic means of abstracting raw binary data from clients. All too often developers and managers are emotionally disconnected from the people they work with. There is simply no substitution for a developer that has a direct, meaningful, deeply understood and empathetic connection to the client. You can&#8217;t beat it. This of course takes years to develop as a skill for the resource and months to extend this kind of relationship to a new client but I think it should be all our goals to attempt. The net result of this relationship is obvious to the client, strengthens trust and ensures reciprocation of respect.</p>
<p>Being able to think on your clients behalf without having to bottleneck communication is absolutely invaluable. </p>
<p>I can see using some kind of chart metric for purposely disposable clients, only if we all keep in sight the larger scope, long term objectives to be more personal and meaningful in our communications for the other 99% of out clients.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Max Pool</title>
		<link>http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-357</link>
		<dc:creator>Max Pool</dc:creator>
		<pubDate>Fri, 12 Oct 2007 12:29:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-357</guid>
		<description>@Justin

Let me give you a physical example  - remote usability testing.

I find old fashioned usability testing inefficient. Cameras, two way mirrors, hordes of information architects, it&#039;s too much.  

Instead send out a pile of pain chart pictures with usability tasks to accomplish.  When they are finished completing the task, have them circle how &quot;painful&quot; it was.

If 2+ people found a particular task higher than a 6 - you now have a reason to advance communication about what was difficult about that task.  

The introverts have a simple, non-confrontational means to communicate, the extroverts are limited to only circling a number, and your analysis for usability problems is reduced to scanning a pile of pain charts searching for common hot spots.  

You didn&#039;t have to talk to anyone!  How is that for streamlined!</description>
		<content:encoded><![CDATA[<p>@Justin</p>
<p>Let me give you a physical example  &#8211; remote usability testing.</p>
<p>I find old fashioned usability testing inefficient. Cameras, two way mirrors, hordes of information architects, it&#8217;s too much.  </p>
<p>Instead send out a pile of pain chart pictures with usability tasks to accomplish.  When they are finished completing the task, have them circle how &#8220;painful&#8221; it was.</p>
<p>If 2+ people found a particular task higher than a 6 &#8211; you now have a reason to advance communication about what was difficult about that task.  </p>
<p>The introverts have a simple, non-confrontational means to communicate, the extroverts are limited to only circling a number, and your analysis for usability problems is reduced to scanning a pile of pain charts searching for common hot spots.  </p>
<p>You didn&#8217;t have to talk to anyone!  How is that for streamlined!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin Deltener</title>
		<link>http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-356</link>
		<dc:creator>Justin Deltener</dc:creator>
		<pubDate>Fri, 12 Oct 2007 02:34:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-356</guid>
		<description>I&#039;m going to assume you&#039;re using the Pain Chart as a metaphor for an attempt to map the range of frustration into something workable that is common to all. God help me if you&#039;re actually touting using the real thing. Alas, I&#039;m having a difficult time swallowing your list of benefits...

&quot;Shorter meetings as discussion is held only when needed&quot;
Because of theoretically universal frustration scale? You may have great confidence in some magical scaling mechanism but will the client? It may be enough for you, but my money is on the client feels more alienated and separated from the process than if you were to ask specific questions, get your answers and  reflect your understanding. Pretty Meat N Taters sort of stuff..

&quot;Introverted clients get to voice their opinions&quot;
I can just hear the person saying.. Before I was too shy to voice my opinion; with this new pain chart though I&#039;m ready to face the world!

&quot;Extroverted clients don’t get the opportunity to monopolize discussions&quot;
Chart or not, Extroverted clients will tell you how they feel in great detail. If you use a diagram/chart approach, they will take 10 minutes telling you why they pointed to 6) on the ouchy scale.

I&#039;ve read some pretty good articles here @ CS but I&#039;m calling Fluffy Fluff Fluff on this one Max!</description>
		<content:encoded><![CDATA[<p>I&#8217;m going to assume you&#8217;re using the Pain Chart as a metaphor for an attempt to map the range of frustration into something workable that is common to all. God help me if you&#8217;re actually touting using the real thing. Alas, I&#8217;m having a difficult time swallowing your list of benefits&#8230;</p>
<p>&#8220;Shorter meetings as discussion is held only when needed&#8221;<br />
Because of theoretically universal frustration scale? You may have great confidence in some magical scaling mechanism but will the client? It may be enough for you, but my money is on the client feels more alienated and separated from the process than if you were to ask specific questions, get your answers and  reflect your understanding. Pretty Meat N Taters sort of stuff..</p>
<p>&#8220;Introverted clients get to voice their opinions&#8221;<br />
I can just hear the person saying.. Before I was too shy to voice my opinion; with this new pain chart though I&#8217;m ready to face the world!</p>
<p>&#8220;Extroverted clients don’t get the opportunity to monopolize discussions&#8221;<br />
Chart or not, Extroverted clients will tell you how they feel in great detail. If you use a diagram/chart approach, they will take 10 minutes telling you why they pointed to 6) on the ouchy scale.</p>
<p>I&#8217;ve read some pretty good articles here @ CS but I&#8217;m calling Fluffy Fluff Fluff on this one Max!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeremy N</title>
		<link>http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-353</link>
		<dc:creator>Jeremy N</dc:creator>
		<pubDate>Thu, 11 Oct 2007 21:53:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/get-better-client-feedback-using-pain-charts/#comment-353</guid>
		<description>Great idea, I wish I would have thought/read/heard of it earlier. 

With that said I believe the best thing any pm/ba/etc can do with their client is to lay down a  framework  (setting expectations) of how a true day-to-day project runs and not some marketing babble about the perfect project with huge savings (save 150% compared to our competitors). During my client interactions I felt that guiding (training) the client into realistic expectations, being up-front and honest (when issues came up or estimates are off), and giving them the consequences (options along with a set of pros/cons) of decisions so they can make the best choice for them (including walking away from the project) leads to the best possible outcome.</description>
		<content:encoded><![CDATA[<p>Great idea, I wish I would have thought/read/heard of it earlier. </p>
<p>With that said I believe the best thing any pm/ba/etc can do with their client is to lay down a  framework  (setting expectations) of how a true day-to-day project runs and not some marketing babble about the perfect project with huge savings (save 150% compared to our competitors). During my client interactions I felt that guiding (training) the client into realistic expectations, being up-front and honest (when issues came up or estimates are off), and giving them the consequences (options along with a set of pros/cons) of decisions so they can make the best choice for them (including walking away from the project) leads to the best possible outcome.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

