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

Re: How to write user stories for usability at release and sprint level

Expand Messages
  • aacockburn
    I m been following this question about usage and usability design VERSUS incremental development for quite a while - since Jeff started up this group, and
    Message 1 of 83 , May 8, 2008
      I'm been following this question about usage and usability design
      VERSUS incremental development for quite a while - since Jeff started
      up this group, and talking with him, and comparing how he describes
      visual designers' work v programmers work, and how I also do and see
      them.

      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.

      I don't know what the resolution can be. Certainly, faster more sketchy
      ideation period for the visual designers, learn to adjust to surprises
      that show up later and learn to work incrementally ... but until and
      unless someone shows up with a way to revise UIs inexpensively half-way
      through a project, I can't see advocating "do visual design as you go"
      as some companies are forcing their visual designers to work.

      I will counter with a particular proposal that may buy visual designers
      some time ... it's an idea from the old Smalltalk community back in the
      early 90s. Namely - have the software designer/programmers design and
      code up the system entirely to an API, not a visual interface.

      The API defines the services the system needs to support and the
      information structures it needs to be able to produce (and absorb).

      This is fairly much independent of the visual design, the sequence of
      screens, the placement of visual elements. That design can be going to
      in parallel, or even a bit behind, since it will simply call upon the
      interfaces.

      As I wrote, this is what we recommended and occasionally did in the
      early 1990s on Smalltalk projects (using the transcript window for all
      I/O to start with), and I have found myself doing this with my current
      project to replace my website. We have the entire website working with
      absolutely no visual design in place. There is (hopefully) nothing the
      visual component will ask for that we haven't already tested that the
      system can produce. We are, however, a bit more experienced in talking
      about what the meaning of certain requests mean in terms of
      computational implication. We've recently started on the visual design
      and not found any conflicts.

      what this means is that the software designer/programmers can code and
      test every part of their work independently of the visual design.

      I don't know how this would look on a larger project with multiple
      teams.

      The hard part really is finding programmers who are willing to build a
      headless system to an API. Most of them insist on a UI for no
      particular good reason (and thereafter couple the system too closely to
      the UI and get stuck after that).

      If anyone else is / has played with this approach, please comment on
      your experiences.

      cheers - Alistair
    • 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
        iterative.

        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.

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