<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Using the Right Medium</title>
	<atom:link href="http://catschwamm.com/2009/11/13/using-the-right-medium/feed/" rel="self" type="application/rss+xml" />
	<link>http://catschwamm.com/2009/11/13/using-the-right-medium/</link>
	<description>Making good software and building good teams.</description>
	<lastBuildDate>Mon, 07 Jun 2010 15:49:26 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: G Valentino</title>
		<link>http://catschwamm.com/2009/11/13/using-the-right-medium/#comment-36</link>
		<dc:creator>G Valentino</dc:creator>
		<pubDate>Fri, 13 Nov 2009 16:22:04 +0000</pubDate>
		<guid isPermaLink="false">http://catsch.wordpress.com/2009/11/13/using-the-right-medium/#comment-36</guid>
		<description>Primo: Loved the post and this series.

Deux: We&#039;re also dealing with what the right mix of text to mock-ups is. It&#039;s also complicated by the fact that most of our developers have English as a second (or third) language. They&#039;re all grand, don&#039;t get me wrong, but there are little nuances in language and culture that can get lost.

What we&#039;ve been doing lately is a hybrid approach:
1) I draft the workflow and screen progress in our whiteboard room, since I can do this quickly and it helps me make decisions on the fly.
2)Once that looks sensible, I create a high level story explaining the workflow. This gives us the need and the happy path solution. 
3) Our developers do a prelim tech analysis and estimation. This way the devs aren&#039;t surprised, and it helps us refine the scope so it can fit into our iteration.
4) I refine the story, translate my wireframes using pen and paper, scan those in, send to devs for full estimate. This gives them something more tangible to work with, and I can do this faster so they have more time to ask questions
5) Our UI guy in Moscow takes my screens and makes high-fidelity mock ups. He&#039;s a genius with UI, and also speaks both Russian and English perfectly so he can field a lot of questions/notes without having to involve me for every one.

By this point we have a story that
1) Describes the need/problem
2) Has a high level overview of the solution so they have a goal
3) Text to describe the basic workflow, with screens to provide as much detail as possible. The only descriptions for the screens are either for (1) validation or (2) non-typical events.

Also the story has gone through a few iterations at all levels, so there&#039;s a nice shared history of the experience which helps with answering questions that arise at design time.

It&#039;s not perfect, but hey, you gotta start somewhere.</description>
		<content:encoded><![CDATA[<p>Primo: Loved the post and this series.</p>
<p>Deux: We&#8217;re also dealing with what the right mix of text to mock-ups is. It&#8217;s also complicated by the fact that most of our developers have English as a second (or third) language. They&#8217;re all grand, don&#8217;t get me wrong, but there are little nuances in language and culture that can get lost.</p>
<p>What we&#8217;ve been doing lately is a hybrid approach:<br />
1) I draft the workflow and screen progress in our whiteboard room, since I can do this quickly and it helps me make decisions on the fly.<br />
2)Once that looks sensible, I create a high level story explaining the workflow. This gives us the need and the happy path solution.<br />
3) Our developers do a prelim tech analysis and estimation. This way the devs aren&#8217;t surprised, and it helps us refine the scope so it can fit into our iteration.<br />
4) I refine the story, translate my wireframes using pen and paper, scan those in, send to devs for full estimate. This gives them something more tangible to work with, and I can do this faster so they have more time to ask questions<br />
5) Our UI guy in Moscow takes my screens and makes high-fidelity mock ups. He&#8217;s a genius with UI, and also speaks both Russian and English perfectly so he can field a lot of questions/notes without having to involve me for every one.</p>
<p>By this point we have a story that<br />
1) Describes the need/problem<br />
2) Has a high level overview of the solution so they have a goal<br />
3) Text to describe the basic workflow, with screens to provide as much detail as possible. The only descriptions for the screens are either for (1) validation or (2) non-typical events.</p>
<p>Also the story has gone through a few iterations at all levels, so there&#8217;s a nice shared history of the experience which helps with answering questions that arise at design time.</p>
<p>It&#8217;s not perfect, but hey, you gotta start somewhere.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
