<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Boxes and Arrows: Comments by gleb a</title>
    <link>http://www.boxesandarrows.com/person/112293</link>
    <pubDate>Wed, 30 Dec 2009 11:39:45 GMT</pubDate>
    <description>Comments by gleb a</description>
    <item>
      <description>&lt;p&gt;I think the idea behind the article is really good. if the specs include both the technical part and the graphical part, if they are written in plain language rather than technical cliches, this is a good way to start a development process.&lt;br /&gt;As for gui prototypes, I think they serve a good purpose, when client draws a lot of attention to detail, or when you don&amp;#8217;t want to have any arguments post factum&amp;#8230;. when it&amp;#8217;s all written on paper, and signed off by both parties, it&amp;#8217;s much easier. If the client does not like the way ui prototypes look, it makes sense to provide design mockups too. this way expectations can be managed in a smart way.&lt;br /&gt;as for the &amp;#8220;add widget button&amp;#8221; vs &amp;#8220;way to add widgets&amp;#8221; problem, I think it all depends on what kind of client it is. I for one prefer the &amp;#8220;add widget button&amp;#8221; option for the specs (provided it&amp;#8217;s been confirmed with client that he wants this solution specifically). at least this is the way we do it. Gleb, &lt;a href="http://www.specshelp.com" rel="nofollow"&gt;www.specshelp.com&lt;/a&gt;&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/getting_creative_with_specs_usable_software_specifications#content_49682</link>
      <guid>http://www.boxesandarrows.com/view/getting_creative_with_specs_usable_software_specifications#content_49682</guid>
      <pubDate>Wed, 30 Dec 2009 11:39:45 GMT</pubDate>
      <author>gleb a</author>
    </item>
  </channel>
</rss>

