<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Comments on Users In The Development Cycle: Effective Project Communication</title>
    <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication</link>
    <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
    <description>Don&amp;#8217;t be another project manager who thinks end users have no place in the development cycle.  Get the right information from the right people and make sure your team has everything they need to do their jobs properly.  When your application is loved by all and you&amp;#8217;re responsible for its success, your entire team will thank you for it.</description>
    <item>
      <description>&lt;p&gt;Ralph,&lt;/p&gt;

	&lt;p&gt;You can always argue for more interaction and/or tiers in the design process.  My intention was not to discount added levels or specific expertise in the ladder; rather to focus on the minimum requirements.&lt;/p&gt;

	&lt;p&gt;I imagine most medium-sized organizations dont have budgets for requirements analysts, so I didnt get into too much specialized detail.&lt;/p&gt;

	&lt;p&gt;You raise an excellent point, though.  Thank you for the comments.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_654</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_654</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Salvatore Palmisano</author>
    </item>
    <item>
      <description>&lt;p&gt;Sal:&lt;/p&gt;

	&lt;p&gt;The requirements-gathering responsibilities in your article which the PM and users are to shoulder look to me just like what good analysts or designers are supposed to do.  Would you consider the role of analyst/designer to possibly be a missing role in your list of PM/developer/user? It&amp;#8217;s been my experience that a good PM and a good requirements analyst are not the same person.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_653</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_653</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>ralph</author>
    </item>
    <item>
      <description>&lt;p&gt;Each project is going to require a different sort of communication.  Whats important here is to make sure that communication happens on some level.&lt;/p&gt;

	&lt;p&gt;If users are completely unavailable, a higher level of interpretation is needed; if its an internal project and project management/development is on-site, it should be easier to get feedback.&lt;/p&gt;

	&lt;p&gt;.sal&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_652</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_652</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Salvatore Palmisano</author>
    </item>
    <item>
      <description>&lt;p&gt;Hello again,&lt;/p&gt;

	&lt;p&gt;I still don&amp;#8217;t understand how you get users into your communications. They are not at the work place. How do they even know development is occuring? How can they get their feedback to the developers, if you are not using the observation techniques I have seen in the usability expert books? Or does the project manager inform them and collect their input? How do you deal with &amp;#8220;self-reporting&amp;#8221; issues?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_651</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_651</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Cecelia</author>
    </item>
    <item>
      <description>&lt;p&gt;Adam, thank you for the comments.  Yes you have misunderstood me.&lt;/p&gt;

	&lt;p&gt;The main ingredents of my article were communication and collaboration.  Im calling for everyone to work together to make sure these types of applications arent built in the first place.&lt;/p&gt;

	&lt;p&gt;Im sure there are plenty of examples of this process gone wrong; bad web sites, unused intranet modules, et cetera.  Im calling for a solid development process where each component (not just the users) know their place and what&amp;#8217;s called for in that place.  Development shouldnt run amok thinking they know whats best for the user, and the users shouldnt clam up thinking &amp;#8216;the developers will do what they please so why should we even say anything?&amp;#8217;&lt;/p&gt;

	&lt;p&gt;The expertise I meant users should respect is in respect to technological development of the application; it was not meant as a pat on the user&amp;#8217;s head by the developers saying: We know what to do, trust us.  I can understand how it might have been construed that way, but it was not my intention.&lt;/p&gt;

	&lt;p&gt;Most importantly, this was not meant as a lecture to any side of the cycle.  It was a call to work together as efficiently as possible.&lt;/p&gt;

	&lt;p&gt;Again, thanks for the comments and I hope Cecilia (and others) are getting a better understanding of where this article is going.&lt;/p&gt;

	&lt;p&gt;.sal&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_650</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_650</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Salvatore Palmisano</author>
    </item>
    <item>
      <description>&lt;p&gt;OK, I&amp;#8217;ve been holding off on commenting here, but seeing as we&amp;#8217;re now getting someone &amp;#8211; Cecelia &amp;#8211; involved who is imbibing this as mothers&amp;#8217; milk, I felt like I had to speak up.&lt;/p&gt;

	&lt;p&gt;Sal, you say this: users should &amp;#8220;respect the development team&amp;#8217;s expertise, and believe their requests aren&amp;#8217;t going completely unheeded,&amp;#8221; right?&lt;/p&gt;

	&lt;p&gt;Try this. (This is just the very first example that occurs to me, &lt;span class="caps"&gt;BTW&lt;/span&gt;.) Go to this site: &lt;a href="http://www.sonyadtv.com/index_e.html" rel="nofollow"&gt;http://www.sonyadtv.com/index_e.html&lt;/a&gt;&lt;/p&gt;

	&lt;p&gt;If you were a user of this site, why in the world would you respect the development team, when that team obviously showed little respect for the user? As for &amp;#8220;unheeded,&amp;#8221; well, we might say that not only were the users unheeded, they were ignored. (Usability testing was performed on this site, and the results discarded as being politically inconvenient.)&lt;/p&gt;

	&lt;p&gt;Users are human beings, as I never tire of reminding people, and are therefore subject to all kinds of human foibles &amp;#8211; including the occasional inability to put their requests in language that developers will readily understand. But this in no way justifies lecturing them that Father Knows Best.&lt;/p&gt;

	&lt;p&gt;He doesn&amp;#8217;t, all too often.&lt;/p&gt;

	&lt;p&gt;Have I misunderstood you?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_649</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_649</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Adam Greenfield</author>
    </item>
    <item>
      <description>&lt;p&gt;Cecelia &amp;#8230; add customers.com to you list. It is more about direct communication than the others. Of course I would interpret Contextual Inquiry as a direct mode of interaction &amp;#8230; It is basically a form of interview with users, and any good usability test should always include a place where users get to respond directly to their experience. What you do with that information is totally different.&lt;br /&gt;&amp;#8212;dave&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_648</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_648</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>dave</author>
    </item>
    <item>
      <description>&lt;p&gt;Can you recommend some books for me?  Thank you for helping me with my learning.&lt;br /&gt;I have:&lt;br /&gt;Designing Web Usability&lt;br /&gt;Designing Easy to Use Websites&lt;br /&gt;Back to the User&lt;br /&gt;Don&amp;#8217;t Make Me Think&lt;br /&gt;About Face&lt;br /&gt;Usability for the Web&lt;br /&gt;User-centered Web Design&lt;br /&gt;Contextual Design&lt;br /&gt;Inmates are Running the Asylum&lt;br /&gt;Usability Engineering (this one is very dull!)&lt;/p&gt;

	&lt;p&gt;I like the idea of just asking users what they think and to give input directly, for it seems much faster.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_647</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_647</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Cecelia</author>
    </item>
    <item>
      <description>&lt;p&gt;Cecelia,&lt;br /&gt;To even attempt to &amp;#8216;read the users mind&amp;#8217; or to get usability information solely from observation is a primary reason rifts exist between users and PM.&lt;/p&gt;

	&lt;p&gt;If you want to know the answer to a question, you have to ask it first.&lt;br /&gt;Here&amp;#8217;s one: Perhaps its time for new books?&lt;/p&gt;

	&lt;p&gt;Thanks for the comments,&lt;br /&gt;.sal&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_646</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_646</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Salvatore Palmisano</author>
    </item>
    <item>
      <description>&lt;p&gt;Salvatore has presented a good overall theme, that users &lt;span class="caps"&gt;MUST&lt;/span&gt; be included at different points in the full lifecycle of a project.&lt;/p&gt;

	&lt;p&gt;However, there is an underlying idea that &amp;#8220;Users must know their place.&amp;#8221; Unfortunately, this seems like an IT-centric viewpoint. Users are generally unaware that software development is happening until software is released. It is up to the project manager or other facilitators of requirements/input to manage end-user input into a project.&lt;/p&gt;

	&lt;p&gt;Certainly, to Cecelia&amp;#8217;s point, if you ask users &amp;#8220;What do you want?&amp;#8221; you will probably get answers from black to white and hot to cold. A good project manager/analyst/UX person should be able to understand the business well enough to see through the fog and turn those &amp;#8220;pie-in-the-sky&amp;#8221; ideas into as much reality as is feasible, using input mechanisms such as surveys and other tools of the &lt;span class="caps"&gt;UCD&lt;/span&gt;/UX trade.&lt;/p&gt;

	&lt;p&gt;Users should not have to &amp;#8220;know their place.&amp;#8221; Users should only have to know their job. It&amp;#8217;s really up to us to turn that stream of desire into meaningful features that help them get that job done.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_645</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_645</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Jeff Corkran</author>
    </item>
    <item>
      <description>&lt;p&gt;Well, I read this&lt;/p&gt;

	&lt;p&gt;&amp;#8220;The users have to live with the application once complete, and need to know how to communicate their needs properly. Development teams aren&#8217;t mind-readers, and will need to know what&#8217;s necessary outside the scope of the original design specifications.&amp;#8221;&lt;/p&gt;

	&lt;p&gt;and I thought it said that it is the end user&amp;#8217;s job to communicate their needs clearly to the development team. But in all the books I&amp;#8217;ve read on this stuff, it says it&amp;#8217;s the devlopment team&amp;#8217;s job to observe and coax knowledge from the users, and that users *aren&amp;#8217;t capable* of making their true needs known.&lt;/p&gt;

	&lt;p&gt;In fact, the books say it&amp;#8217;s the development team&amp;#8217;s job (in particular the usability engineer&amp;#8217;s) to &amp;#8220;read the user&amp;#8217;s mind&amp;#8221;&lt;/p&gt;

	&lt;p&gt;I do totally think it&amp;#8217;s cool that PM&amp;#8217;s do user research. I mean, why does it always have to be the IA/Designer if there is no usability engineer on staff?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_644</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_644</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Cecelia</author>
    </item>
    <item>
      <description>&lt;p&gt;Dave, excellent point.  Im overly left-brained sometimes and consider efficiency and usability over whats &amp;#8216;pretty&amp;#8217;.  But you&amp;#8217;re right about adding features that sales can use as a closer.&lt;/p&gt;

	&lt;p&gt;Thanks for the support.&lt;/p&gt;

	&lt;p&gt;.sal&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_643</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_643</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Salvatore Palmisano</author>
    </item>
    <item>
      <description>&lt;p&gt;Im more concerned with being cognizant of user needs than I am with placing &amp;#8216;responsibility for usability&amp;#8217; onto end users.  The more project managers know about their audience, the better they are going to be able to direct their project.&lt;/p&gt;

	&lt;p&gt;Why use another tier between project management and usability?  Why not include user requests in project specs and eliminate the guess work?&lt;/p&gt;

	&lt;p&gt;This does &lt;span class="caps"&gt;NOT&lt;/span&gt; mean I call for users involved in every aspect of the project life.  Users must know their place; they should be aware only they can get across what matters most to them about the application.  Project management should interpret those requests and disseminate them to development.  From there wish lists can be regarded and decisions can be made about what stays and what goes.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_642</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_642</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Salvatore Palmisano</author>
    </item>
    <item>
      <description>&lt;p&gt;Salvatore, this is great.&lt;br /&gt;First to Cecelia&amp;#8217;s point. I don&amp;#8217;t think that he was stating that Users do usability. It is more that you can&amp;#8217;t make a usable product without end-users&amp;#8217; voice in the project. Also, I don&amp;#8217;t think he was saying that project managers DO usability, but project managers can make sure that user studies are included in the project plan, and that &lt;span class="caps"&gt;UCD&lt;/span&gt; is a core part of the project lifecycle.&lt;/p&gt;

	&lt;p&gt;I liked this article a lot. It is missing one distinction that I have learned is very important for product creation and that is the difference between the end-users and the customers. Customers don&amp;#8217;t always buy what will work best for users and quite honestly if customers don&amp;#8217;t buy it, then users will never see it.&lt;/p&gt;

	&lt;p&gt;I call this the bell &amp;#38; whistle requirement. Why? Well b/c customers are humans and even the largest purchase has a little human impulsiveness around it. I work for an enterprise software company, and I am amazed at how &amp;#8220;Ooo! &amp;#38; Ahhh!&amp;#8221; makes people buy things even at this level of scalibility and robustness requirements. Why? b/c a fact sheet will never differentiate you from the competition. A &amp;#8220;Wow!&amp;#8221; will every time.&lt;/p&gt;

	&lt;p&gt;I have designed pieces of our software that &lt;span class="caps"&gt;I KNOW&lt;/span&gt; is completely unusable, but the sales staff say that it is a requirement as is, b/c it makes for a kick-butt demo.&lt;/p&gt;

	&lt;p&gt;Anyway, I don&amp;#8217;t think this takes away at all from Salvatore&amp;#8217;s overall theme. I just wanted to make sure that we remember many of us are in the business of design and have a higher calling than &lt;span class="caps"&gt;UCD&lt;/span&gt; theory &amp;#8230; that is selling products.&lt;br /&gt;&amp;#8212;dave&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_641</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_641</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Dave</author>
    </item>
    <item>
      <description>&lt;p&gt;Wow.  I&amp;#8217;ve never seen responsibility for usability placed on the shoulders of the end users before. Is this wise, considering all the &amp;#8220;Don&amp;#8217;t listen to users&amp;#8221; stuff on useit.com? And I didn&amp;#8217;t know that project managers did usability.&lt;/p&gt;

	&lt;p&gt;This is a radically different view of the user-centered design cycle than all the stuff in books lately.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_640</link>
      <guid>http://www.boxesandarrows.com/view/users_in_the_development_cycle_effective_project_communication#content_640</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:26 GMT</pubDate>
      <author>Cecelia</author>
    </item>
  </channel>
</rss>
