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

RE: [agile-usability] Re: The Role of Vision

Expand Messages
  • KATHARINA BRUNAGEL
    Alain - I couldn t agree more. I find the use of personae and high level user tasks also really useful especially, if I have to work with user stories that are
    Message 1 of 83 , May 30, 2008
    View Source
    • 0 Attachment
      Alain - I couldn't agree more. I find the use of
      personae and high level user tasks also really useful
      especially, if I have to work with user stories that
      are very general and state something as generic such
      as
      'As a customer' and the target segment - could we a
      business user in a one man band company or a 350
      employee size company... I started to use personae
      associated with a spreadsheet that uses a high level
      of user task matrix in context per persona to
      highlight how user needs can affect different
      functionality and found that this is quite
      useful...especially when persona's have to be
      introduced late into a project that already works with
      user stories but has lost the vision or not clearly
      articulated upfront who the product is really for....


      --- "Desilets, Alain" <alain.desilets@...>
      wrote:

      > Great posting. I like your use of "values".
      >
      >
      >
      > I have also found Focal User Models and Personaes
      > and Core High level
      > User Tasks to be useful for helping in decision
      > making. Whenever we are
      > faced with design choices and tradeoffs, we make
      > sure that we can
      > explain our choices in terms of how it will better
      > support a particular
      > Focal user to carry out a core task. Often we find
      > that we can't justify
      > our initial choice, which is a sure sign that we
      > were out of alignment
      > with the vision.
      >
      >
      >
      > Alain
      >
      >
      >
      > From: agile-usability@yahoogroups.com
      > [mailto:agile-usability@yahoogroups.com] On Behalf
      > Of Darius Kumana
      > Sent: May 13, 2008 2:33 PM
      > To: agile-usability@yahoogroups.com
      > Subject: Re: [agile-usability] Re: The Role of
      > Vision
      >
      >
      >
      >
      >
      > Hi,
      >
      >
      >
      > I thought I'd share a technique I am trying at the
      > moment for helping to
      > communicate vision in an agile environment.
      >
      >
      >
      > I wanted to find a way to communicate vision that
      >
      > * Was not so high level that it seemed
      > irrelevant to developers at
      > ground zero
      >
      > * Could be commonly understood by people in
      > diverse disciplines,
      > fields and levels in the company
      >
      > * Did not take a large amount of time/effort for
      > people to stay
      > up-to-date with
      >
      > * Could be easily translated into ACTION / help
      > inform design and
      > implementation decisions
      >
      > * Provide a shared focus and discipline that
      > empowers the whole
      > team to strive toward a common goal
      >
      >
      >
      > Staying Relevant
      >
      >
      >
      > As Scott said in his post:
      >
      >
      >
      > "Vision in the usual agile sense means a common
      > understanding of where
      > the project is trying to go and why. It's the shared
      > criterion that
      > people apply in making decisions"
      >
      >
      >
      > I couldn't agree with this more!
      >
      >
      >
      > This is why I have often found problems
      > communicating vision using the
      > "mission statement" like decree from c-level execs
      > in isolation. Such
      > statements often seem irrelevant to those making
      > low-level day-to-day
      > design and implementation decisions.
      >
      >
      >
      > In order to help better communicate our c-level
      > execs vision I'm trying
      > to supplement the mission statement with a set of
      > values...
      >
      >
      >
      > Common Understanding
      >
      >
      >
      > To hone in on an appropriate set of values, it helps
      > if you have a
      > sounding-board (I use the positive terms from
      > Microsoft's Product
      > Reaction Cards
      >
      <http://www.google.com/url?sa=t&ct=res&cd=2&url=http%253A%252F%252Fwww.m
      >
      icrosoft.com%252Fusability%252FUEPostings%252FProductReactionCards.doc&e
      >
      i=ctwpSI2KG6bGQcKVoIUK&usg=AFQjCNFlexj0CBzYjPyUt4QBc_X5QdrX5g&sig2=Rse3J
      > HAPygsjFlv9pFSiYQ> mixed in with organisational
      > brand values and those
      > explicitly identified as part of the original
      > mission statement). So
      > basically you end up with a big long list of
      > positive values!
      >
      >
      >
      > An exercise can then be carried out whereby the
      > development team,
      > business sponsors and some target users help to
      > collectively identify
      > the key values wanted for the new product. (eg. From
      > the list, tick all
      > the terms that apply to the experience we want for
      > our customers when
      > using our product. Circle just 5 of the most
      > important terms).
      >
      >
      >
      > Sanity checking the results with our senior
      > executives and product owner
      > (who ultimately own the vision), we ended up with a
      > set of values of
      > various priorities (depending on the number of times
      > that value was
      > ticked/circled). These values were used to help
      > supplement the vision.
      >
      >
      >
      > Minimum Effort
      >
      >
      >
      > To ensure these values could be easily grasped and
      > were constantly
      > accessible (with minimum effort) to the agile team
      > they were displayed
      > as wall-art! A poster of the values was stuck on
      > the wall (tag-cloud
      > format - so the important values were bigger.).
      > Basically a big
      > easy-to-digest information-radiator for the
      > product's key values and
      > their relative importance.
      >
      >
      >
      > Turning Vision Into Action
      >
      >
      >
      > Design is often about choices and choices are about
      > options. By
      > supplementing your vision with a set of values - you
      > start to provide
      > the options.
      >
      >
      >
      > As an agile team we need to ensure that the choices
      > we make will lead us
      > to a solution that is in alignment with "the
      > vision". I.e. When / how /
      > where / should trade-offs be made.
      >
      >
      >
      > Mission statements were ok - but they didn't always
      > seem relevant to
      > work going on in the current sprint. Values on the
      > other-hand could be
      > applied across the board regardless of the features
      > being developed.
      >
      >
      >
      > Eg. It became clearer that "Speed" was perceived as
      > much more important
      >
      === message truncated ===



      __________________________________________________________
      Sent from Yahoo! Mail.
      A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
    • 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
      View Source
      • 0 Attachment
        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.