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

Re: [agile-usability] Thanks for showing up!

Expand Messages
  • Adam Carter
    ... Who says it doesn t suck ? Adam
    Message 1 of 11 , Jul 14, 2004
      Phlip wrote:

      > I always just relied on the "doesn't suck" principle
      > myself...

      Who says it 'doesn't suck'?

      Adam
    • Phlip
      ... Me! /a beat/ This might be considered a gap in the process. ;-) ===== Phlip http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
      Message 2 of 11 , Jul 14, 2004
        Adam Carter wrote:

        > Phlip wrote:
        >
        > > I always just relied on the "doesn't suck"
        > > principle myself...
        >
        > Who says it 'doesn't suck'?

        Me!

        /a beat/

        This might be considered a gap in the process.

        ;-)


        =====
        Phlip
        http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



        __________________________________
        Do you Yahoo!?
        Yahoo! Mail - You care about security. So do we.
        http://promotions.yahoo.com/new_mail
      • Adam Carter
        ... Not surprisingly I think that is the answer for most application development :P Adam
        Message 3 of 11 , Jul 14, 2004
          Phlip wrote:

          > > Who says it 'doesn't suck'?
          >
          > Me!
          >
          > /a beat/
          >
          > This might be considered a gap in the process.
          >
          > ;-)
          >
          >
          > =====
          > Phlip

          :)

          Not surprisingly I think that is the answer for most application
          development :P

          Adam
        • Arlen Bankston
          What is the role of the Interaction Designer (ID) in agile teams? To build on the many insightful observations that have come before, I ll unload the
          Message 4 of 11 , Jul 18, 2004
            What is the role of the Interaction Designer (ID) in agile teams? To
            build on the many insightful observations that have come before, I'll
            unload the following opinions:

            THE INTERACTION DESIGNER SHOULD REPRESENT THE USERS
            As several have noted previously [16, 56], there are major differences
            between the XP Customer and an application's Users. Keeping this in
            mind, one can examine the XP system of Developers and Customers and
            see that there is a productive tension between the two; this can be
            multiplied by introducing Users as a third party. Since the full
            continuum of Users rarely enjoy direct representation in a project
            team (even by proxy), someone must advocate for their needs, as does
            the Customer for the business's needs (or their own), and the
            Developers for the system's quality and their own bandwidth. This
            responsibility should lay with the Interaction Designer.

            IDs SHOULD BE GENERALIZING SPECIALISTS
            Jeff earlier divided usability folks into three groups:
            up-front/requirements people, design/implementation people and testing
            people. I would contend that, especially in an agile team, these are
            skills that are applied at various stages of a project, but ones that
            should all be held to some degree by a single person. (A partial
            exception is testing, which is multifaceted and deserves attention
            from several parties, and a separate discussion.) Agile teams need
            the eponymous "generalizing specialist" [Ambler], with core
            proficiencies in interaction and UI design, and strong capabilities in:
            - Business analysis
            - GUI development
            - User observation & analysis
            - Usability testing
            - Graphic design

            I have seen few agile projects that would readily fund more than a
            single individual in this general line of practice, so this is to some
            degree a matter of practicality. However, it is more about the single
            point of responsibility noted above; in order to have a consistent
            shared vision and quality execution throughout an incremental process,
            someone must be singularly focused on the none-too-simple task of
            smoothly integrating all of those changing requirements into the
            broader navigation structure, as well as into the individual screens.
            The mental context switch between interaction/UI design and OO
            development is significant, and asking Developers to manage both will
            inevitably lead to sacrifices on one side or the other.

            THE CUSTOMER NEEDS HELP UNDERSTANDING BUSINESS VALUE
            I believe that the ID provides a vital service to the Customer by
            providing a more objective picture of their User's needs than they
            might otherwise enjoy. This perspective is both an addendum and a
            counterbalance to internal business objectives, as Brian noted
            eloquently in message 16. For example, a Customer might feel that
            they need certain features, but have little true idea of the relative
            value of each; this information can be provided by the application of
            Usage-Centered Design, by ethnographic observation and other means.
            The Customer still has the final word on what they want to do, but now
            they're getting strong opinions from both Developers and Users (via
            the ID) to inform their decisions.

            Some other quickies addressing previous posts:

            * Usability should be cultural, but not solely distributed. Its value
            should be clear to the entire team, and they should collaboratively
            practice and learn it as much as possible. However, diluting the
            responsibility among the team (even with a pinch-hitting UI/usability
            expert) is risky, because the practices are different and complex
            enough that a single owner is generally warranted (IMO). I really
            like Kent's approach in message 30.

            * ID practices generally move to a very different beat than the rest
            of development. This means that they can be done in parallel, yet
            another argument for a dedicated resource (see Mark's message 18).

            * The ID's skills can be useful even in projects with little or no UI,
            as noted in the thread regarding API development. I have been
            involved in several business process redesign efforts, for instance;
            the principles and practices are much the same, and similar to those
            of business analysts.

            OK, I think that's long-winded enough. 'Til next time... ;)

            Arlen Bankston
            Interaction Design Manager | CC Pace | www.ccpace.com
          • Gary
            Hi, another blast from the past post that evidently took the scenic route (and still is). I agree with Jeff s breakdown with 2 slight twists. From what I ve
            Message 5 of 11 , Jul 20, 2004
              Hi,

              another "blast from the past" post that evidently took the scenic route
              (and still is).

              I agree with Jeff's breakdown with 2 slight twists. From what I've seen
              companies break the work down into the 3 chunks.
              In large organizations Usability usually starts out with testing, then
              gets into some design, followed by front-end work, and finally more
              design and a life-cycle process.

              Second, most people seem to specialize in one phase or another. In fact
              they typically specialize in using a few of the tools available in that
              phase.

              So what are the credentials? That is a different question. I've known
              folks who have had 1 year of experience 10 or more years and a few who
              have crammed 2 years of experience into a year. Additionally there
              isn't a certification program that is universally accepted. So for
              credentials we typically look at tools used, portfolio of work, input
              from collegues, and gut feel.

              gary


              > Jeff Patton wrote:
              >
              >> --- In agile-usability@yahoogroups.com, Phlip <phlipcpp@y...> wrote:
              >> > What kind of credentials do usability experts need?
              >>
              >> As always, the answer is "it depends."
              >>
              >> I lump usability people into three groups:
              >> 1. up-front people: those who work at pre-development/pre-product
              >> stage to determine what software is appropriate to build 2. design
              >> people: knowing what the software should do, how exactly
              >> does it do it? Both appearance and user interaction
              >> 3. design validation or test people: given a piece of software
              >> functionality, exactly how usable is it? What adjustments could be
              >> made to make it more usable?
              >>
              >> Like developers, there are usability generalists who do all those
              >> things well, and specialists who focus hard on doing a particular
              >> thing well. Among usability people there are many different points
              >> of view on how any of those activities are done.
              >>
              >> What best credentials are depends on where you perceive risk to be
              >> in your project. Are customers unsure what to do? Are they sure
              >> what it should do, but hazy on exactly how? Do you have a product
              >> that does what it should, but does it poorly?
              >>
              >> >
              >> > I always just relied on the "doesn't suck" principle
              >> > myself...
              >>
              >> Me too - sort of. If the piece of functionality is used by one
              >> proficient person infrequently, I let it suck. If it's used by
              >> hundreds of inexperienced people very frequently, sucking might get
              >> expensive. Especially if you have to pay to frequently train this
              >> people, and provide help desk support for them. Since sucking can
              >> get very expensive in that situation, an expert in making it not
              >> suck can pay big dividends to a customer concerned with ROI.
              >> I think others on the list could better say what proficiencies a
              >> usability person should have.
              >> Also, usability people, if you have other points of view than mine
              >> on the 3 classes - I'd like to hear them.
              >> -Jeff
              >>
              >>
              >>
              >>
              >>
              >> >
              >> >
              >> >
              >> > =====
              >> > Phlip
              >> > http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfac
              >> es
              >> >
              >> >
            Your message has been successfully submitted and would be delivered to recipients shortly.