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

1033Re: [agile-usability] user centered design overlaps with traditional analysis?

Expand Messages
  • Chris
    Feb 3, 2005
    • 0 Attachment
      Agreed.

      I use risk with priorities to guide efforts. I see change and the impact of change as risks.

      Putting together a very detailed artifact is a risk at different levels. Political, business, project survival, etc.

      Reducing the risks sets up the environment for success.

      -----Original Message-----
      From: "Desilets, Alain" <alain.desilets@...>
      Date: Thu, 3 Feb 2005 13:28:14
      To:"'agile-usability@yahoogroups.com'" <agile-usability@yahoogroups.com>
      Subject: RE: [agile-usability] user centered design overlaps with traditio
      nal analysis?

      When it comes to specs I believe width is more important to depth. Makes sure the spec is end to end, but it's OK if you can't go into detail on everything in between right away.

      -- Alain Désilets
      I am confused by this statement... it seems to contradict itself.

      To me, doing things "end-to-end" means depth-first, not breadth first. More precisely, it means you focus on one particular user task that the system needs to support, and implement it without worrying about the rest (or at least, not until the rest is proven to be actually needed). In ExtremeProgramming, this has been captured by quaint phrases like YAGNI ("You Ain't Gonna Need It") and "Implement the Simplest Thing that Could Possibly Work".

      I have found that to work very well. You design a small part of the system, implement it, deploy it, gather feedback about it, then refactor it, or augment it with new functionality. Each of these cycles takes about one to two weeks. Note that refactoring includes changing the UI so that it is easier to use given the current set of features supported by the system.

      In my opinion, this approach is the only way to gather information about ACTUAL needs, especially when you are designing a new and innovative product where no-one (including users, managers and yes, usability experts) really understand what is required.

      In my opinion, any process where more than 10% of the project time is spent upfront on gathering requirements and producing design documents, does not qualify as Agile.


      Alain Désilets, MASc
      Agent de recherches/Research Officer
      Institut de technologie de l'information du CNRC /
      NRC Institute for Information Technology

      alain.desilets@...
      Tél/Tel (613) 990-2813
      Facsimile/télécopieur: (613) 952-7151

      Conseil national de recherches Canada, M50, 1200 chemin Montréal,
      Ottawa (Ontario) K1A 0R6
      National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
      K1A 0R6

      Gouvernement du Canada | Government of Canada



      Yahoo! Groups Links
      To visit your group on the web, go to:
      http://groups.yahoo.com/group/agile-usability/
      To unsubscribe from this group, send an email to:
      agile-usability-unsubscribe@yahoogroups.com
      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      Sent wirelessly via BlackBerry from T-Mobile.
    • Show all 26 messages in this topic