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

Re: [agile-usability] Re: How to write user stories for usability at release and sprint level

Expand Messages
  • William Pietri
    Hi, Alistair. Good to hear from you. ... As somebody who has much more experience in under-the-hood design than as visual designer, I may be wildly off base
    Message 1 of 83 , May 8, 2008
      Hi, Alistair. Good to hear from you.

      aacockburn wrote:
      > I confess that I can't yet see a way out of the conundrum.
      > Visual designers really do benefit from wide-band ideation, exploring
      > lots of ideas early and concurrently and leaving ideas on the table for
      > cross-pollination. The sketchboard and cartooning discussions show this
      > well.
      > Software designers/programmers these days tend to get the base idea
      > pretty quickly and program incrementally, changing the architecture as
      > they go.

      As somebody who has much more experience in under-the-hood design than
      as visual designer, I may be wildly off base here. But this is also an
      area that I've been researching, and here's my take.

      My pre-agile approach as a software designer was to take the same path
      as a lot of people on the user experience side are comfortable with:
      lots of research, lots of planning, lots of sketching out alternatives,
      and wanting to settle on one before starting to code.

      The number one factor for me in getting comfortable with working
      differently was learning how to safely change my designs later. That let
      me do my designs when I had the most information available. There were a
      variety of technical practices that made this possible, including
      test-driven development, refactoring, once-and-only-once orientation,
      and frequent, easy releases.

      Now, I still do plenty of sketching of architectural possibilities, but
      I do them on a ongoing basis, considering possible paths and
      destinations. It reminds me of the way a big-city taxi driver doesn't
      plan a single route, but keeps the options alive in his head, so that
      when he hits traffic, he'll instantly change plans.

      I think on the design side, things have lagged behind. Not because of
      any fault of designers, mind you. I think it's partly because
      plan-driven methods caused a lot more pain for developers than
      designers, so they had more incentive to switch. And partly because one
      of the big agile methods, Extreme Programming, was mainly programmer
      created. But I think a big driver is that developers can make their own
      software tools, and so there are more and better software tools for
      solving developer problems than designer problems.

      Still, at least in the web world, I think things have improved a fair bit.

      The rise of CSS has been a huge help. The good agile designers I know
      are just as fanatical about organizing and refactoring their CSS as
      developers are about continuously improving technical architecture. And
      they do it for the same reason: reducing the cost of change. Early web
      frameworks were very page-focused, which pushed against the kind of
      reuse that eases agility. Now there are better options for componentized
      UIs, so that the same visual component may appear in may places but is
      only coded once.

      And coming back to your other point, headless systems that provide API
      for UI, Ajax-ish approaches and better in-browser tools have made that
      easier. It's not that one builds a whole back-end system first and then
      puts on a UI, naturally. But people do tend to end up with a more slowly
      evolving back-end system and a more quickly evolving front-end
      interface. In the projects I keep an eye on, this has drastically
      reduced the cost of design change, and led to a lot more lightweight
      prototyping and design exploration than I saw at the beginning of the

      So the way I see out of this is more of the same: new practices,
      improved tools, better collaboration, and more experience making agile
      design work.

    • carl myhill
      I m a bit new to Agile but don t really see the problem with this vision thing. I use the Cooper Goal-Directed Design Method. We interview users to learn their
      Message 83 of 83 , Jun 2, 2008
        I'm a bit new to Agile but don't really see the problem with this
        vision thing. I use the Cooper Goal-Directed Design Method.

        We interview users to learn their goals and understand their tasks and
        we do that up front, perhaps as a sprint rather than anything

        We produce personas, from the interview data, and goals. And we
        produce high level context scenarios, which start making basic
        references to concepts that will exist in the design.

        From the context scenarios we can almost underline the parts which
        indicate user needs.

        Then we take out a whiteboard pen and write a storyboard wireframe
        (which Cooper used to call the Design Vision and now call in
        Interaction Framework). We elaborate a bit on the design hinted at in
        the context scenario and produce a key path scenario, which describes
        in more detail how the user will interact with the design. This whole
        exercise lets us outline the anatomy of the design and to understand
        how to play it.

        When we are happy with that Design Vision, we can jump into iterations
        and do a bit of 'just in time' detailed design.

        The Vision, is the Design Vision. It is justified through
        understanding the users typical day and their typical needs. It
        probably won't change much since it is quite high level.

        I'm not sure where the problem is with a vision like this. perhaps,
        the only drawback is that you have to do a bit of work in front of the
        iterative cycles to get a good understanding of the users and what
        they do to enable you to get this vision pinned down.

        i'd be interested in comments on this.

      Your message has been successfully submitted and would be delivered to recipients shortly.