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

A case study in the making

Expand Messages
  • tmfspeck
    My company adopted the agile process for web development tasks quite recently (within the last 6 months) at the suggestion of our lead web
    Message 1 of 6 , Jul 3, 2005
    • 0 Attachment
      My company adopted the agile process for web development tasks quite
      recently (within the last 6 months) at the suggestion of our lead web
      programmer/developer. While we're still sort of finding our way with
      the process, I'm (pleasantly) surprised at the relatively enthusiastic
      response it's recieved.

      Up until that point, our web applications developed somewhat
      organically, and were largely driven from the technical end, with most
      folks viewing the design process as "adding blush" to the finished
      app, even though those of us in the design group find ourselves not
      only designing layouts, but click-flows, navigation, and usability.
      We're all versed in XHTML, CSS, XML/XSL, we all share the graphical
      chores, and we code a fair amount of program logic in C#. We even end
      up writing some of the technical copy, e.g. program feedback.

      The problem/challenge for our group has been two-fold: overcoming the
      perception of us as really nothing more than "the font and color
      guys", and often having to sort of retrofit usable interfaces and
      address user experience issues almost after-the-fact.

      I'm an interaction designer on various development teams, each of
      which typically consists of a "product owner" (expert user), designer,
      db specialist and technical developer(s). The adoption of the agile
      process has helped a great deal in getting those of us in the design
      team in on the ground floor of application development; however, the
      process is still largely tech-driven, with still some large interface
      design/usability issues being addressed concurrently with, and often
      as an adjunct to, technical development.

      Quite recently, our group was given budget and responsibility for
      usability testing and training (to which I credit the agile process)
      which presents some new challenges of its own:

      1) How to best conduct some basic usability tests, glean useful
      results, and apply the learnings in application development.

      2) How to mesh the broader overview of application design/usability,
      with the shorter term, iterative agile development process.

      Wondering how to face those challenges is what lead me here. As I'm
      relatively new to both the agile process and formal usability
      integration, I'm still absorbing, so don't know that I have any
      intelligent questions to ask here - yet<g>. Just wanted to reach out
      to what looks to be an smart and helpful group while I search for the
      best starting points.

      I look forward to reading more of the postings and related articles,
      many of which I've already found quite helpful. Of course, any
      pointers for someone like me, new to both agile development and formal
      usability, will be enthusiastically received.

      And hope this all makes sense.

      Kurt Morris
      Interaction Designer
      The Motley Fool
      http://www.fool.com
    • Desilets, Alain
      Sounds like you re definitely on the right track! ... I m an interaction designer on various development teams, each of which typically consists of a product
      Message 2 of 6 , Jul 5, 2005
      • 0 Attachment
        Sounds like you're definitely on the right track!

        I have a point to make which does not pertain directly to your posting, but it has been an irritant for me and other fellow developpers. It pertains to your use of the word "design" in the following sentences, without prefacing it with a word like "interaction":

        ----
        I'm an interaction designer on various development teams, each of which typically consists of a "product owner" (expert user), ***designer**, db specialist and technical developer(s).

        <SNIP>

        The adoption of the agile process has helped a great deal in getting those of us in the ***design team*** in on the ground floor of application development
        ----

        When you use the standalone word "design" like this instead "interaction design", you (probably unintentionally) make it sound like interaction designers have a monopoly on design, or that THEIR design activities are somewhat more important. This is very annoying to developpers who also do a lot of design and whose design work has as much impact on the success or failure of the final product, and even on its usability (a product that connects to a slow database will be unusable no matter how good the UI).

        From reading the rest of your post, I know that this is not what you actually mean, but this is the message that is being carried across. You are not the only interaction designer who uses the word "design" in that way. I just came back from the UPA workshop on Agile Usability, and many of the interaction designers in that group used the term in that way too. Even gurus like Alan Cooper use the term that way. In fact, if you read the "Inmates" book, you can see that Cooper actually DOES mean that interaction designers have a monopoly on design... His book clearly states that "designers" (meaning interaction designers) design the product, developpers build it, and business people sell it. But design is an all-encompassing activity that needs to involve all three of those types of people throught the development cycle.

        Sorry if this looks like a trivial peeve, but it has been bothering me for a while.


        Alain Désilets, MASc
        Agent de recherches/Research Officer
        Institut de technologie de l'information du CNRC /
        NRC Institute for Information Technology

        alain.desilets@...
        Tél/Tel (613) 990-2813
        Facsimile/télécopieur: (613) 952-7151

        Conseil national de recherches Canada, M50, 1200 chemin Montréal,
        Ottawa (Ontario) K1A 0R6
        National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
        K1A 0R6

        Gouvernement du Canada | Government of Canada
      • Joshua Seiden
        Alain points to one of the difficult aspects of design--it takes place on so many levels. Designers tend to focus on one aspect, one element, one medium, one
        Message 3 of 6 , Jul 5, 2005
        • 0 Attachment
          Alain points to one of the difficult aspects of design--it takes place
          on so many levels. "Designers" tend to focus on one aspect, one element,
          one medium, one problem type, etc. We often forget *or simply don't
          know* about the others.

          I think this second point is important--designers don't know that other
          kinds of design exists. If you're not a specialist, design is an opaque
          activity. I have a friend who designs microprocessors. I have NO IDEA
          what he does, despite my many cocktail party attempts to understand it.
          Does he have some special software that he uses? He told me once that he
          sometimes uses an oscilloscope (I think) but I don't know what that is,
          let alone know how it furthers the cause of design.

          Imagine someone trained in graphic arts (not to pick on anyone)--has he
          ever seen a source code editor? How does he relate to the design
          problems a programmer faces?

          One of the reasons that I like this group is because it brings different
          types of designers together.

          I will tell you too, Alain, that we interaction designers often feel a
          sense of being in the minority. We struggled for some time just to be
          allowed to call what we do design, so we may sometimes use the word in a
          chauvinistic sense. That is certainly what Cooper chose to do in
          Inmates, but for him it was a rhetorical strategy to put interaction
          design on the map.

          None of this should be read as a justification, by the way. I really
          believe in the UXnet (http://uxnet.org) principles--no-one group owns
          design. I'm just pointing out that it's easy to be unaware of the work
          that our cube-mates are doing. (Do I hear all the Agilists shouting,
          "Exactly..."?)

          JS

          -----Original Message-----
          From: agile-usability@yahoogroups.com
          [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
          Sent: Tuesday, July 05, 2005 9:53 AM
          To: 'agile-usability@yahoogroups.com'
          Subject: RE: [agile-usability] A case study in the making


          Sounds like you're definitely on the right track!

          I have a point to make which does not pertain directly to your posting,
          but it has been an irritant for me and other fellow developpers. It
          pertains to your use of the word "design" in the following sentences,
          without prefacing it with a word like "interaction":
        • tmfspeck
          ... posting, but it has been an irritant for me and other fellow developpers. It pertains to your use of the word design in the following sentences, without
          Message 4 of 6 , Jul 5, 2005
          • 0 Attachment
            > I have a point to make which does not pertain directly to your
            posting, but it has been an irritant for me and other fellow
            developpers. It pertains to your use of the word "design" in the
            following sentences, without prefacing it with a word
            like "interaction"

            Hi Alain,

            Point taken, and I'll actually take your quibble one step further to
            help illustrate my point: Several of us in the "design group" are
            actually designers on several levels: My title is "interaction
            designer" (literally architecting interaction), but I also do a fair
            amount of graphical design (UI) work as well - layouts, fonts,
            colors, etc. To further complicate matters, the entire development
            team has weekly "design meetings" at which code structure/flow,
            database issues, and ui concerns are hashed out. My apologies that
            the terms blur - they blur here as well, as we struggle to find job
            and task titles that are more descriptive and more specific.

            Far from giving the web developers short shrift, or claiming "DESIGN"
            as my domain, my teammates and I rely upon and support each other to
            truly "design" the finished product in every sense of the word.

            I realize, however, that such imprecision can be confusing when
            talking about our internal structure here in a more public forum, and
            I'll try to more clearly define my role(s), and those of my teammates
            when discussing specifics. I hope that by doing so, I can move
            quickly from academic definitional questions to those that will help
            me and my team successfully meld Usability and Agile.

            I meant no offense to web developers, especially those upon whom I
            rely <g>.

            Thanks for your thoughts,

            Kurt Morris
            Interaction Designer
            The Motley Fool
            http://www.fool.com
          • Kevin Narey
            ... It s right and fitting that you mention this Alain, because it really is a difficult problem and is anything but trivial. Unfortunately it is likely to be
            Message 5 of 6 , Jul 5, 2005
            • 0 Attachment
              On 7/5/05, Desilets, Alain <alain.desilets@...> wrote:

              > Sorry if this looks like a trivial peeve, but it has been bothering me for a while.

              It's right and fitting that you mention this Alain, because it really
              is a difficult problem and is anything but trivial. Unfortunately it
              is likely to be around for some time to come, but we can console
              ourselves that we share a common goal (and this is often lost sight of
              in the melee): We want to help deliver great solutions.

              Kevin
            • Desilets, Alain
              I will tell you too, Alain, that we interaction designers often feel a sense of being in the minority. We struggled for some time just to be allowed to call
              Message 6 of 6 , Jul 6, 2005
              • 0 Attachment
                I will tell you too, Alain, that we interaction designers often feel a sense of being in the minority. We struggled for some time just to be allowed to call what we do design, so we may sometimes use the word in a chauvinistic sense. That is certainly what Cooper chose to do in Inmates, but for him it was a rhetorical strategy to put interaction design on the map.

                -- Alain:
                I hang around with and work closely with many interaction design people so I understand their pain. There are many developpers out there (few agilists I would hope) who even today, believe that usability is just a matter of slapping a GUI over a backend.

                But the solution to this impass is certainly not to turn things around and advocate that we should be designing the GUI and then just slap a backend underneath it. Yet this is exactly what Cooper proposes in "Inmates". Advocating such a process can only piss-off those "unenlightened" developpers and get them even more set in their ways. The solution, as you and I obviously agree, is for interaction designers and developpers to engage in continuous day-to-day cooperative problem solving.

                BTW: This is exactly what has happened with Agile and testing. QA people used to feel like their message didn't get across to developpers. There were all kinds of misconceptions on both sides of the fence. QA people felt that programmers didn't care about quality, whereas programmers felt that QA people didn't understand the pressures of code writing and meeting deadlines. But Agile methods (XP in particular) solved the issue by bringing testers into the trenches and having them collaborate on a day to day basis with developpers. As a result, developpers in an XP team tend to be much more sympathetic to quality issues, and in fact, they litterally live by unit testing. And yes, there is still room in XP teams for testing specialists, who can advise developpers on how to write good test and who do independent testing.

                I'm glad to see that many interaction designers are taking a similar approach and I trust that it will completely change the way developpers think about and react to issues of usability.
                ----
              Your message has been successfully submitted and would be delivered to recipients shortly.