Loading ...
Sorry, an error occurred while loading the content.
 

Re: [agile-usability] Valuing stories

Expand Messages
  • Adam Sroka
    ... The best practice is probably not to do wireframes. Or, at least, to spend very little time on very basic wireframes and let the design evolve over time.
    Message 1 of 53 , Sep 6, 2009
      On Sun, Sep 6, 2009 at 3:52 AM, Biju vv<biju_v_v@...> wrote:
      >
      > Can anyone point the best practices followed in coming with wireframes with
      > minimal re-work during the sprint.


      The best practice is probably not to do wireframes. Or, at least, to
      spend very little time on very basic wireframes and let the design
      evolve over time.

      The problem with wireframes is analogous to the problem with UML
      designs. They aren't working software, and there is a tendency to
      over-design with them. e.g. The navigation goes here (What
      navigation?) The help button goes here (What help button?) Etc.

      The desire to create a complete design before you have working
      software is similar to the desire of many programmers to design an
      entire SOA/J2EE stack before creating a web page. As an Agile
      programmer I know that I can just throw up a page, and if I need
      SOA/J2EE I will be able to find it later.

      To be successful in an Agile environment designers need to embrace the
      same values that programmers do. It is only necessary or desirable to
      develop the parts of the design that are specific to the story at
      hand. So, in early stories designers will be thinking about what
      colors to use, when should an alert pop up? What kind of control
      should we use that will make sense to the user? Etc. Later, when the
      system begins to evolve, they will be able to worry about how the new
      pieces fit into the whole system.

      As far as "rework," certainly as the product evolves old elements of
      the design will be supplanted by new ones which means that things that
      were written earlier may have to change. If you believe that this is
      avoidable and/or that avoiding it is desirable, then I suggest you go
      back to RUP, waterfall, or whence ye came. If, on the other hand, you
      recognize that there is value in being able to change your mind to
      meet the customer/market then you should call it what it is - it's not
      "rework," it's refinement.
    • Adrian Howard
      ... I think that they re probably an orthogonal dimensions myself. I ve met people who make very good decisions about the design of the code/ ux - but are not
      Message 53 of 53 , Sep 11, 2009
        On 6 Sep 2009, at 21:27, Hassan Schroeder wrote:

        > On Sat, Sep 5, 2009 at 8:31 PM, William Pietri<william@...>
        > wrote:
        >
        >> .... In fact, teams are doing design all the time. The choice
        >> isn't between designing and not designing; it's between designing
        >> well
        >> and designing poorly.
        >
        > Or between designing consciously and designing unconsciously,
        > the latter being fairly close to "not designing" :-)


        I think that they're probably an orthogonal dimensions myself. I've
        met people who make very good decisions about the design of the code/
        ux - but are not really able to articulate the reasoning behind them
        very well.

        This can be problematical since their decisions can sound arbitrary to
        others - even when they're really good decisions.

        Cheers,

        Adrian

        --
        http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
      Your message has been successfully submitted and would be delivered to recipients shortly.