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

Re: Thanks for showing up!

Expand Messages
  • Deb
    ... Hi Jeff. Thanks for organising this. I may be more of a lurker, but am very interested. I am a ScrumMaster, and find that a self organising team
    Message 1 of 11 , Jul 13, 2004
      --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@a...>
      wrote:
      > I want to thank everyone for very quickly signing up for this
      > group. I'm seeing a really great mix of participants with
      > varying degrees of experience in both usability and agile
      > development.

      Hi Jeff. Thanks for organising this.

      I may be more of a lurker, but am very interested. I am a ScrumMaster,
      and find that a "self organising team" dominated by programmers can
      forget about the user experience. I am wondering where, in the cycle
      of Scrum, usability design fits in. I suspect there are various
      answers to this, depending on the scope of the work being done...

      I'll be watching. :-)
      deb
    • Adam Carter
      ... Who says it doesn t suck ? Adam
      Message 2 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 3 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 4 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 5 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 6 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.