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

usability expert credentials - was: Re: Thanks for showing up!

Expand Messages
  • Jeff Patton
    ... 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
    Message 1 of 11 , Jul 13, 2004
    • 0 Attachment
      --- 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
      >
      >
      >
      > __________________________________
      > Do you Yahoo!?
      > Yahoo! Mail is new and improved - Check it out!
      > http://promotions.yahoo.com/new_mail
    • David Anderson
      Jeff, I want to thank you for inviting me. Looking through the membership I see that quite a few people know me, and mostly for my recent work on Agile
      Message 2 of 11 , Jul 13, 2004
      • 0 Attachment
        Jeff,

        I want to thank you for inviting me.

        Looking through the membership I see that quite a few people know me,
        and mostly for my recent work on Agile Management. However, I was the
        UI Architect on the original FDD project in Singapore and personally
        designed 450 of the 600 screens in the GUI for that system.

        I've recently been asked a few times to write more about agile UI
        design and usability and I do have some stuff to share which reflects
        work which I did between 1997 and 2000 before I was press ganged into
        the management at Sprintpcs.com ;-)

        I am overdue to post some web log entries at uidesign.net with that
        material.

        I'm happy to be here. Pleased that agile usability is getting
        attention and I look forward to fruitful discussions on this list.

        Cheers

        David

        --- 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.
        >
      • Ron Vutpakdi
        ... Well, it sort of depends how you re lumping together. Within Landmark, when most people say usability they tend to lump together the 2 human factors
        Message 3 of 11 , Jul 13, 2004
        • 0 Attachment
          --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@a...>
          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?

          Well, it sort of depends how you're lumping together. Within
          Landmark, when most people say "usability" they tend to lump together
          the 2 human factors folks (who have a degree in human factors), the
          interaction designer (me), the domain experts (about 12), and the
          documentation folks as usability due to the way the group was
          originally formed (even though the group has now been disbanded and
          dispersed.

          Jeff's general lumping of up front folks, designers, and design
          validation/testing is the most common lumping that I've seen in terms
          of skill sets, interests, and activities. I most often see the first
          and last group lumped together also.

          I'd expand on the up-front description a bit to include to include
          conducting ethnographic research which goes into the determining what
          to build.

          And, as Jeff pointed out, everyone has a slightly different focus. I
          prefer to fall on the design and upfront parts, but I also do the
          design validation and testing side too.

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

          Perceptions of what "doesn't suck" does vary dramatically though. For
          example, I work with a developer whose perception of "doesn't suck"
          means that *he* can use the software well enough to exercise the
          necessary functionality. Luckily, the perception of the dev lead is a
          little different, so I get her to tell him that an interface needs to
          be changed and he needs to listen to me.


          >
          > I think others on the list could better say what proficiencies a
          > usability person should have.

          I think that an important proficiency is the ability to be flexible
          and adapt to the current situation. Doesn't mean cave in and just
          rubber stamp things, but understanding how to adapt, when to push, and
          when not to push.

          Ron
        • 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 4 of 11 , Jul 13, 2004
          • 0 Attachment
            --- 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 5 of 11 , Jul 14, 2004
            • 0 Attachment
              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 6 of 11 , Jul 14, 2004
              • 0 Attachment
                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 7 of 11 , Jul 14, 2004
                • 0 Attachment
                  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 8 of 11 , Jul 18, 2004
                  • 0 Attachment
                    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 9 of 11 , Jul 20, 2004
                    • 0 Attachment
                      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.