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

What's Interaction Design?

Expand Messages
  • jeff621
    I d like to get this group s opinion on an assertion I ve made: In a couple papers I ve submitted recently I ve made the assertion that Interaction Design
    Message 1 of 6 , May 10 12:44 PM
    • 0 Attachment
      I'd like to get this group's opinion on an assertion I've made:

      In a couple papers I've submitted recently I've made the assertion
      that Interaction Design represents a class of activity that can be
      effectively added into agile development methodologies such as XP or
      Scrum. I'm asserting Usage-Centered Design, in the agile form that
      Larry and Lucy teach it, represents an ideal method for implementing
      Interaction Design in practice.

      So, is that statement garbage?

      I've been asked for more references on Interaction Design as a
      discipline. And, unfortunately I'm coming up short. It turns out I
      may have my own working definition of the term - and it may not match
      with other's. How would _you_ define "Interaction Design"? Does
      Usage-Centered Design qualify as form of Interactions Design? If
      not, is there a generic term for what Usage-Centered Design is - a
      Superclass so to speak? Are there books, or articles you could
      recommend that might discuss Interaction Design as a discipline?

      Thanks for any opinions you can offer.

      -Jeff
    • Larry Constantine
      Jeff, Thanks for raising another good question. Interaction design, like information architecture, is a neologism that many are claiming is an advance over or
      Message 2 of 6 , May 11 6:14 PM
      • 0 Attachment
        Jeff,

        Thanks for raising another good question.

        Interaction design, like information architecture, is a neologism that many
        are claiming is an advance over or better than or newer than user interface
        design. Like much other current terminology, it has almost as many meanings
        as it has users.

        In the broad sense, interaction design means design of the interaction--the
        process of exchange or intercommunication--between users and a system. Some
        claimants to the title of interaction designer say they do not do user
        interface design--that's old stuff and the easy part. Most seem to see
        interaction design as embracing aspects of the design problem not covered by
        user interface design as many have come to regard it, which became stuck at
        the level of widget choice and layout.

        In the narrow sense in which we often use the term interaction design, it is
        just one part of user interface design, that is, design of the interface
        between the system and the user. Interaction design concerns dynamics and
        behavior; it's complement is visual design, which concerns layout and
        appearance. Obviously this shows a GUI bias. If you have a voice interface,
        the split is less clear, but there are structural aspects--how the options
        and responses are organized into menus, submenus, packets--and the dynamic
        aspects involving sequence, interruptability, etc.

        David Anderson at uidesign.net is one of the strong proponents of
        interaction design as distinct from (rather than a part of) user interface
        design.

        There is also a political issue, which is that interaction design is more
        trendy than UI design.

        As to usage-centered design, we would describe it as a refinement of
        improvement upon user-centered design. It is one method for approaching
        interaction design, user interface design, visual interface design...

        That's how I'd call it. Any other comments out there?

        --Larry Constantine
        forUSE 2002 | 25-28 August 2002
        Sponsored by Constantine & Lockwood, Ltd.
        www.foruse.com/2002/


        > -----Original Message-----
        > From:
        > sentto-1175705-108-1021059889-lConstantine=compuserve.com@...
        > .yahoo.com
        > [mailto:sentto-1175705-108-1021059889-lConstantine=compuserve.com@return
        > s.groups.yahoo.com]On Behalf Of jeff621
        > Sent: 10 May 2002 3:45 PM
        > To: usage-centered@yahoogroups.com
        > Subject: [usage-centered] What's Interaction Design?
        >
        >
        >
        > I'd like to get this group's opinion on an assertion I've made:
        >
        > In a couple papers I've submitted recently I've made the assertion
        > that Interaction Design represents a class of activity that can be
        > effectively added into agile development methodologies such as XP or
        > Scrum. I'm asserting Usage-Centered Design, in the agile form that
        > Larry and Lucy teach it, represents an ideal method for implementing
        > Interaction Design in practice.
        >
        > So, is that statement garbage?
        >
        > I've been asked for more references on Interaction Design as a
        > discipline. And, unfortunately I'm coming up short. It turns out I
        > may have my own working definition of the term - and it may not match
        > with other's. How would _you_ define "Interaction Design"? Does
        > Usage-Centered Design qualify as form of Interactions Design? If
        > not, is there a generic term for what Usage-Centered Design is - a
        > Superclass so to speak? Are there books, or articles you could
        > recommend that might discuss Interaction Design as a discipline?
        >
        > Thanks for any opinions you can offer.
        >
        > -Jeff
        >
        >
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >
      • Nuno J. Nunes
        on 12/05/02 01:14, Larry Constantine at lConstantine@compuserve.com wrote: I agree that interaction design is far more a political issue rather than an
        Message 3 of 6 , May 12 2:54 PM
        • 0 Attachment
          on 12/05/02 01:14, Larry Constantine at lConstantine@... wrote:

          I agree that interaction design is far more a political issue rather than an
          interesting scientific or technical breakthrough, whether in user-interface
          design or user-centered development. The issue is quite similar to the
          "agile development" movement... Suddenly every method out there is "agile"
          or "extreme", it doesn't matter if many of the proponents don't have a clue
          about the development context (software engineering in the small) that
          jumpstarted lightweight methods - I prefer to use the older terms since I
          don't see any fundamental different between them!

          I agree with Larry in the broad definition of interaction design as "design
          of the interaction between users and a system". However, I disagree with the
          narrow definition...

          > In the narrow sense in which we often use the term interaction design, it is
          > just one part of user interface design, that is, design of the interface
          > between the system and the user. Interaction design concerns dynamics and
          > behavior; it's complement is visual design, which concerns layout and
          > appearance. Obviously this shows a GUI bias. If you have a voice interface,
          > the split is less clear, but there are structural aspects--how the options
          > and responses are organized into menus, submenus, packets--and the dynamic
          > aspects involving sequence, interruptability, etc.

          Assuming the broad definition, it seams obvious that interaction design
          starts at early project inception when task cases (or task flows) are
          identified and the structure of use is captured and worked. This is
          specially true when work or process re-engineering are a concern (and they
          should always be in my opinion). The key issue here is that, assuming
          interaction design starts early in the project lifecycle, then it highly
          influences the system architecture... And perhaps that is the major
          breakthrough in the last couple of years (together with what is known as
          OOUID). Unfortunately it seams that those important aspects are not
          interesting in a world of x-something or agile-something!!!

          That brings us to Jeff's assertion...

          >> In a couple papers I've submitted recently I've made the assertion
          >> that Interaction Design represents a class of activity that can be
          >> effectively added into agile development methodologies such as XP or
          >> Scrum. I'm asserting Usage-Centered Design, in the agile form that
          >> Larry and Lucy teach it, represents an ideal method for implementing
          >> Interaction Design in practice.

          I'm sorry but I can't figure out how you can practice interaction design as
          an activity in XP without creating something which is not XP at all... On
          the other hand I can't see how UsageCD can be classified as an agile-method
          when Larry and Lucy are strong proponents of upfront-modeling and claim that
          agile development can cope with upfront specification of dozens of task
          cases without iterative or evolutionary development!!! I hope that somebody
          doesn't think about using the excellent modeling techniques of UsageCD,
          while doing XP, and them call it X-UsageCD...

          Please don't misinterpret me. I'm a strong proponent of some of the
          techniques in UsageCD (and XP). I believe that they can be combined in a
          different process setup to create agile-methods. I'm also a strong proponent
          of engineering practices such as the ones proposed by Larry and others...
          Surely nobody would want to cross a bridge or fly an airplane that was build
          over a set of "religious" principles...

          This is perhaps a useless discussion, at least until we can settle over
          definitions of some simples things like technique, method, process...

          I would highly recommend reading an interview with Jeff Raskin about
          Cooper's book that coined (at least to my knowledge) the term interaction
          design (http://www.uidesign.net/2000/letters/raskinoncooper.html)...

          Please carry on...
          Nuno

          --
          Nuno Jardim Nunes
          URL: http://www.math.uma.pt/njn/
        • Paul Hodgetts
          In scanning through some recent usage-centered mailings (yeah, I m running a bit behind ;-), I found: ... Are these papers available somewhere? I d like to
          Message 4 of 6 , May 14 7:20 PM
          • 0 Attachment
            In scanning through some recent usage-centered mailings (yeah,
            I'm running a bit behind ;-), I found:


            jeff621 wrote:

            > I'd like to get this group's opinion on an assertion I've made:
            >
            > In a couple papers I've submitted recently I've made the assertion
            > that Interaction Design represents a class of activity that can be
            > effectively added into agile development methodologies such as XP or
            > Scrum. I'm asserting Usage-Centered Design, in the agile form that
            > Larry and Lucy teach it, represents an ideal method for implementing
            > Interaction Design in practice.

            Are these papers available somewhere? I'd like to take a look
            if I could.

            > So, is that statement garbage?

            I don't think so. I've spent a lot of time on my last client's
            project working with the IA/UI Designer to weave his activities
            into the overall agile process (mostly based on XP). He uses a
            process very much like UCD, which I also advocate.

            The main issue we encountered is that some of the IA activities
            seem to best occur upstream from the development activities.
            For example, the layout of the use cases into an overall task
            map, with a map of the pages, seems to fit better when run close
            to the story writing activities, since these help the Customer
            define and scope the story. The developers really can't start
            writing the guts of the pages unless they know what pages exist
            and know what widgets need to be on the pages. Adding the page
            refinements, like graphics and fonts and widget locations can be
            done concurrently with the development.

            Just as an added thought, one key reason we can't do all of this
            in parallel is that the skill sets for IA/UI (especially graphic
            design) is really different from the skill set for programming
            the business logic with Java. The only overlap is in the areas
            of HTML and Javascript. So, we can't treat the IA/UI design as
            just another task for the task pool, and pairing has limited
            returns when the skill sets are so different.

            We focused a lot on determining what the minimal investment
            that needed to be made in the IA/UI design before we could
            feed it to the developers. This investment was made when the
            Customer was reasonable certain the story would show up in the
            next iteration, so the IA/UI Designer was essentially working
            one iteration ahead of the Java developers. The IA/UI design
            products are incrementally refined as needed through the two
            iterations, with good source control used to make sure the
            UI designers and developers aren't trashing each other's work.
            This "pipeline" is decidedly /not/ agile, but it's the best we
            came up with and it worked well in practice.


            Also, while we're on this thread, Nuno J. Nunes wrote:

            > Suddenly every method out there is "agile" or "extreme", it
            > doesn't matter if many of the proponents don't have a clue
            > about the development context (software engineering in the
            > small) that jumpstarted lightweight methods

            I agree about the misuse of the term "agile," however the main
            context that spurred the development of agile methods like XP
            wasn't programming in the small, it was development in an
            environment where requirements were changing and rapid
            development was needed. Agile methods are mostly oriented
            towards moving fast and adapting to change. Simplicity,
            providing feedback, close collaboration, avoiding debt, etc.
            are strategies used to manifest rapid, adaptable development.

            I also agree with Nuno that adding UCD into XP seems to result
            in something that is no longer XP due to the pipeline effect
            I mentioned above that prevents a single iteration from being
            a discrete unit of development. I belive we can apply agile
            principles and strategies to UCD (Larry's got some stuff on
            this as well), and our experience is that the result is agile
            enough for the projects where we've tried it. YMMV.

            Regards,
            Paul
            -----
            Paul Hodgetts -- Principal Consultant
            Agile Logic -- www.agilelogic.com
            Training, Mentoring, Development -- Agile Processes, XP, Java, J2EE, C++
          • jeff621
            Thanks all for the comments back. Nuno, thanks for the reference to UIDesign.net. I d read the Cooper interview, but not the Raskin comments afterwards.
            Message 5 of 6 , May 15 8:53 AM
            • 0 Attachment
              Thanks all for the comments back.

              Nuno, thanks for the reference to UIDesign.net. I'd read the Cooper
              interview, but not the Raskin comments afterwards. Basically if
              these well-respected people don't have a common definition of
              Interaction Design, I don't expect I'll find one.

              The stuff I'm trying to label are the decisions made before we know
              what might be on the user interface - or if there should be a user-
              interface at all. I'm seeing Interaction Design addressing questions
              like: "Who are the users?", "What do they want?", "How should they
              interact with some system to get it?", "Who else cares and what do
              they want?". Once we've decided what the users should do with the
              system, and basically what interaction contexts might contain, we can
              go about designing user interface and measuring its effectiveness.
              But no amount of good user-interface will compensate for
              misunderstanding the goal of a user - or leaving an important user
              out completely.

              Paul Hodgets wrote:
              >Are these papers available somewhere? I'd like to take a look
              if I could.<

              They're simple experience reports and still a work in progress.
              XP/Agile Universe and OOPSLA have accepted drafts. They'll be
              presented at each of those conferences. It's feedback from those
              groups that prompted my post. I'd asserted that some form of
              Interaction Design should be used - but then only gave information
              about U-CD. Which prompted the fair question "What is interaction
              design exactly? And, what other forms are there?" - Which maybe
              should have been my real posted question to this group.

              Nuno Nunez wrote:
              >Assuming the broad definition, it seams obvious that interaction
              design
              starts at early project inception when task cases (or task flows) are
              identified and the structure of use is captured and worked. This is
              especially true when work or process re-engineering are a concern
              (and they
              should always be in my opinion). The key issue here is that, assuming
              interaction design starts early in the project lifecycle, then it
              highly
              influences the system architecture... And perhaps that is the major
              breakthrough in the last couple of years (together with what is known
              as
              OOUID). Unfortunately it seams that those important aspects are not
              interesting in a world of x-something or agile-something!!!<

              Good comments. I'll focus on the comment on interaction design
              influencing system architecture. We've had good luck bringing
              developers, business people, end-users and UI people together in
              collaborative U-CD sessions. We find that developers and UI people
              come away with a better understanding of why things are the way they
              are. And, business people and end-users understand how doing things
              a little differently can be more cost effective and faster. U-CD
              gives us a framework to make sure we ask and answer all those right
              questions. We end up calling this agile because it's highly
              collaborative, we throw around lots of 3x5 cards, we churn out lots
              of poster-sized post-its then roll them up and call them design
              documents. We may be guilty of calling it agile because it doesn't
              look like anything we used to do.

              Nuno Nunez also wrote:
              >I'm sorry but I can't figure out how you can practice interaction
              design as
              an activity in XP without creating something which is not XP at
              all... On
              the other hand I can't see how UsageCD can be classified as an agile-
              method
              when Larry and Lucy are strong proponents of upfront-modeling and
              claim that
              agile development can cope with upfront specification of dozens of
              task
              cases without iterative or evolutionary development!!! I hope that
              somebody
              doesn't think about using the excellent modeling techniques of
              UsageCD,
              while doing XP, and them call it X-UsageCD...<

              This is a fun one to respond to. I've never seen an XP project that
              could be called XP – including the one I spent a year on that was set
              up by Kent Beck himself. We're definitely not doing pure XP. We do
              XP style planning, regular iterations, unit-testing, refactoring,
              pair programming.. yada yada yada. But, we front-end this entire
              process with a collaborative U-CD session. We "re-brand" our
              resulting task-cases as user-stories then use them to plan releases
              and iterations. Things get "agile" when we realize we made a mistake
              and need to change our minds about what to develop. We go back to
              the user roles and task cases and make our decisions with what we
              hope are interaction designer's sensibilities.

              On iterative development and upfront specification of lots of task
              cases, I find that when XP people bristle at big upfront design,
              they're generally talking about the architecture & objects under the
              interactions. In practice we don't decide any of that stuff up
              front. We still have lots of room to make mistakes and change that
              design without affecting the interactions we agreed on together.
              There's still plenty of room to really evolve the architecture over
              the course of many iterations. We may let interaction requirements
              push some major architectural issues – like "the performance of
              interactions required for this user may be better served by a Java
              Swing UI rather than an HTML/Servlet based approach."

              I hope we don't see an X-UsageCD either. I'll make it a career goal
              right now to never invent a software development methodology. I
              couldn't take the resulting abuse… ;-) - Makes me think of the joke
              you've likely all heard: "What's the difference between a
              methodologist and a terrorist? – You can negotiate with a terrorist."

              Larry Constantine wrote:
              >There is also a political issue, which is that interaction design is
              more trendy than UI design.<

              I'm adopting the more trendy interaction design label. The political
              issue I keep fighting in the XP/Agile community is: "UI designers are
              the people you bring in to make things pretty just before you ship."
              The emphasis in XP and agile processes to involve the "customer" or
              user in the process is a good one. Now if we can just get someone in
              there to ask the customer the right questions, we may just get
              somewhere. So, coming full circle, that skill of knowing what
              questions to ask and how to respond to that with an appropriate piece
              of software - can I get away with calling that "Interaction Design?"

              Someone also forwarded me this link:
              http://www.chesco.com/~cmarion/PCD/WhatIsInteractionDesign.html -
              thanks Peter. I haven't digested this article yet, but it may have
              some useful ideas as well.

              Thanks again for everyone's comments. Lots of good information and
              lots of good ideas to consider.

              Jeff Patton
              Development Team Lead
              Tomax Technologies
              (801) 924 - 6924

              "We can't solve problems by using the same kind of thinking we used
              when we created them."
              Albert Einstein
            • Nuno Jardim Nunes
              ... That s fine, but what people are doing is combining different techniques to create a customised method. The key issues here are, for instance, what process
              Message 6 of 6 , May 15 9:26 AM
              • 0 Attachment
                On 15/05/02 02:20, "Paul Hodgetts" <phodgetts@...> wrote:


                > I don't think so. I've spent a lot of time on my last client's
                > project working with the IA/UI Designer to weave his activities
                > into the overall agile process (mostly based on XP). He uses a
                > process very much like UCD, which I also advocate.

                That's fine, but what people are doing is combining different techniques to
                create a customised method.

                The key issues here are, for instance, what process framework emerges from
                combining XP and UsageCD? Iterative? Evolutionary? Spiral?
                Are task cases the stories used in XP? If not, what is used? What are
                stories in XP? How do you convey stories in XP?
                How much effort is put into UsageCD up-front design? What about up-front
                design and XP principles? Does that design only impact the UI or also the
                internal functionality?
                How do you convey architectural spikes in UsageCD+XP? What is the impact of
                UI elements in the architectural spike? What is an architectural spike in
                XP? What is an architectural model in UsageCD?

                > I agree about the misuse of the term "agile," however the main
                > context that spurred the development of agile methods like XP
                > wasn't programming in the small, it was development in an
                > environment where requirements were changing and rapid
                > development was needed. Agile methods are mostly oriented
                > towards moving fast and adapting to change. Simplicity,
                > providing feedback, close collaboration, avoiding debt, etc.
                > are strategies used to manifest rapid, adaptable development.

                I meant software engineering in the small and not programming in the
                small... There's a huge difference... Of course I agree that changing
                requirements are the key issue spurring agile development... The problem is
                that changing requirements happen in both small and large-scale SE!

                Interesting discussion...
                Nuno
                --
                Nuno Jardim Nunes
                Assistant Professor
                University of Madeira
                Mathematics Dep. - Computer Science Unit
                URL: http://math.uma.pt/njn/
              Your message has been successfully submitted and would be delivered to recipients shortly.