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

RE: [agile-usability] Seven habits of highly successful customers

Expand Messages
  • Desilets, Alain
    -- Alain Désilets wrote: Adrian, I like those guidelines, but many of them seem very code and developper centric. I was thinking more about practices that
    Message 1 of 3 , Aug 17, 2005
      -- Alain Désilets wrote:
      Adrian,

      I like those guidelines, but many of them seem very code and developper centric.

      I was thinking more about practices that someone acting in a customer role (either as the sole customer or as part of a customer team) can use to make sure that they guide the project properly.
      ----

      On 16 Aug 2005, at 15:43, Desilets, Alain wrote:
      [snip]
      > So here is my question to you U* folks. If you were to define a
      > small (say less than 12) set of U* practices with similar
      > properties (individually useful, provide immediate and visible
      > benefit), what would those be?
      [snip]

      /Good/ question :-)

      My little list of guidelines includes:

      * The UI is code

      Don't treat the UI as separate from the code base. Having a good
      clean simple UI is /just as important/ as having good clean code. Get
      this across to the development team and most of your job is done.

      * UI concepts should be reflected in the code

      If your UI has a whole bunch of Wibble Buttons that look and behave
      in the same way then there should be a WibbleButton abstraction in
      the code somewhere.

      * UI concepts should be reflected in the tests

      You can't automate usability testing. You can automate some aspects
      of it. Do so.

      * Use persona

      For those who've not come across them - little written sketches of
      the expected users' personalities. Have them pinned up in the team
      room. Encourage everybody to ask themselves "What would X do?" in any
      given situation. For more info see <http://www.evolt.org/article/
      Practical_Persona_Creation/4090/56111/>.

      * Code the UI first

      Draft out the UI before you write the code. This does /not/ mean
      design the entire UI of the application before you write the
      application. I like doing it at the planning game stage: when the
      stories are created or when the acceptance tests are being done.
      Incrementally as the project progresses.

      It also does not mean a glorious piece of Photoshop work that you
      want to hang on the wall. Think Agile Modeling. Think paper
      prototypes. Think sketches on the back of index cards. Simple HTML
      pages. Just enough to get the job done.

      * User advocate to the customer

      There should be at least one person in the Customer role who
      understands UI issues and can help shape the stories so they will
      meet user expectations.

      * User advocate to the developer

      There should be at least one person in the Developer role who
      understands UI issues and can help shape the code so it will meet
      user expectations.

      * Coding standards (extended XP practice, consequence of "UI is code")

      Some sort of UI standards should form part of the coding standards.
      Remember you don't have to define all your coding standards up front
      before the project starts. It's a living document that should reflect
      your learning as the project progresses. This applies much more to
      the HIG since they tend to be more project specific and will change
      as the team understands more about the project.

      Also, be sure to create UI standards that people can actually /use/.
      See <http://www.humanfactors.com/downloads/aug04.asp> for some tips.
      Eight pages of single typed 8pt text bad. Pictures good. Big post-it
      notes stuck on the wall - fantastic.

      * Refactor mercilessly (extended XP practice, consequence of "UI is
      code")

      You should treat inelegant UIs as harshly as you treat inelegant code.

      * Collective code ownership (extended XP practice, concequence of "UI
      is code")

      Everybody owns the UI. It's everybody's responsibility to fix
      problems with the UI.

      * The customer is always available (existing XP practice)

      Getting the programmers to guess about customer decisions affects the
      UI just as badly as it does the code.

      * Frequent small releases (existing XP practice)

      Log gaps between feedback from real users affects the UI just as
      badly than the code.

      * User stories are written (existing XP practice)

      Stories are much more user-centric than some more traditional
      requirements gathering processes, and help everybody create a better UI.

      * Pair programming (existing XP practice)

      Spreading the knowledge about the UI is just as important as
      spreading the knowledge about the code.

      * Create spike solutions to reduce risk (existing XP practice)

      Not sure which UI choice will work best? Throw together a prototype
      and try it on some people.

      ----

      Any more for any more?

      Cheers,

      Adrian





      Yahoo! Groups Links
    Your message has been successfully submitted and would be delivered to recipients shortly.