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

Re: [agile-usability] Usability, personas, use cases

Expand Messages
  • Kevin Doyle
    ... I m not an agile guru, but I am a design and usability consultant - so, here s my take on it, however wrong it may be. ;) Personas are really more of a
    Message 1 of 8 , Jul 15, 2005
      > Whilst both are new 'languages', personas are most
      > useful in communicating to the project team what the users (your
      > actors) actually desire in terms of their goals, however getting
      > empathy from the large majority of developers is an added challenge
      > often with fruitless results.

      I'm not an agile guru, but I am a design and usability consultant -
      so, here's my take on it, however wrong it may be. ;) Personas are
      really more of a tool for determining a product's requirements, and
      aren't really used by developers. Personas give a face and depth to
      the possible user that's impossible to create without having a product
      or prototype you can throw off a group of use-testers. Once you're at
      the testing stage of the game, personas really help in determining
      your tester base. They can even be a help to developers -- developers
      sometimes have a hard time seeing what they're making through the eyes
      of the user and personas can help with this - however, that implies
      that the developer wants to know more about the user.

      > Use-cases do not seem to bridge any communication gaps as they are a
      > language in their own right that needs to be learnt by rote and being
      > textual in nature are uninteresting and wordy. In fact I've never once
      > seen an effective use-case because they're so difficult to get 'right'
      > and even harder to communicate value. Also, the mere thought of asking
      > one of my customers to attempt to understand one is tantamount to
      > asking them to start coding for me. I can't see it and need
      > enlightenment!

      Use cases aren't one of my strengths, but they're HUGELY important if
      you want to determine a product's requirements -- especially if you're
      developing a completely new application or site. Yes, use cases have
      their own vocabulary you need to have translated if you're trying to
      explain them to a group of stakeholders or team members who have never
      used them. If you're someone responsible for presenting a series of
      use-cases to a group of stakeholders or team members, you are going to
      have to learn how to translate those use cases to your team and to the
      stakeholders. Use cases can reduce the amount of guesswork and can be
      a big help on determining each step of a complicated process. I can't
      imagine ~not~ using them -- I'm just not very good at creating them.

      > * Usability whilst useful in most contexts is just ' good design ' and
      > therefore a misnomer. When was anything 'well designed' unusable?

      Have you ever visited a web page that looked great visually, but had a
      hard time trying to figure out where the link to something important
      was? As you rolled your mouse over the page, perhaps lots of neat
      things happened - cool mouseover behaviors or other types of neat
      animations are triggered, but you still couldn't find that link you
      were looking for? Sure, the site looks AWESOME, but it's so cutting
      edge that the novice user can't even figure the page out. (Flash sites
      are SOOO guilty of this.)

      When something is considered "well designed" in my book, it has to be
      intuitive ~and~ visually appealing. The term "design" is a strange one
      in site and application development. Design, for me, has two parts -
      visual design and interface design; the two are very different. Sure,
      both require knowledge of how to layout a page, but interface design
      is where the "usability" happens. Perhaps visualize interface design
      as the skeleton and visual design as the skin. (The muscle could
      perhaps be called the backend and/or "programming".) Interface design
      includes detailing each part of the site -- menu placement, page
      behavior (mouseover or onClick), button vs. link usage and placement,
      radio button vs. checkbox vs. alt/shift menu selection, content
      placement, etc., etc. Visual design includes stylesheet creation,
      color guide creation and usage, branding, typography, etc., etc...
      Frank Lloyd Wright once said, "'Form follows function' - that has
      been misunderstood. Form and function should be one, joined in a
      spiritual union." I view "form" as the visual design and "function" as
      the interaction design.

      Okay. Babbling is over... Feel free to flame, correct, slap, or comment.

      Kevin Doyle
      Senior Consultant, CC Pace, Inc.
    Your message has been successfully submitted and would be delivered to recipients shortly.