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

Don Norman on Agile Development

Expand Messages
  • Jeff Patton
    This from Don Norman finally reached me [thanks Marjorie] - orginally posted April 2 according to my rss reader: Why doing user observation first is wrong
    Message 1 of 13 , Apr 17, 2006
    • 0 Attachment
      This from Don Norman finally reached me [thanks Marjorie] - orginally
      posted April 2 according to my rss reader:
      Why doing user observation first is wrong
      http://www.jnd.org/dn.mss/why_doing_user_obser.html

      A quote from the wrap up on this essay:

      "We need to embrace rapid, iterative methods. We need to fit the new
      procedures used by the programming teams, we need to become team
      players. What's especially nice about these new methods is that they
      have made room for us: they explicitly acknowledge the importance of
      HCI design. Everyone wants us on the team, but only if we won't slow
      down the work. More power to them."

      I couldn't ask for a statement I could agree with more. I came to this
      field later than most seeking approaches to designing the outside of
      the product as well as the inside. At that time, the trouble I
      observed and still observe is that HCI/UCD/Interaction Design/Ux as an
      an explicit concern entirely left out of most software development
      processes - agile or not.

      I know there are companies out there working to install agile
      approaches with concerns about time for user research - what do you
      think of Norman's comments? Is he just getting cranky as he gets
      older, or is this essay really just a sign of changing times?

      Oh - and for CHI attendees who want to hear more about this subject:
      http://www.chi2006.org/sessiondetail.php?sessionid=2414

      thanks,

      -Jeff
    • Desilets, Alain
      I couldn t ask for a statement I could agree with more. I came to this field later than most seeking approaches to designing the outside of the product as
      Message 2 of 13 , Apr 17, 2006
      • 0 Attachment
        I couldn't ask for a statement I could agree with more. I came to this
        field later than most seeking approaches to designing the outside of
        the product as well as the inside. At that time, the trouble I
        observed and still observe is that HCI/UCD/Interaction Design/Ux as an
        an explicit concern entirely left out of most software development
        processes - agile or not.

        I know there are companies out there working to install agile
        approaches with concerns about time for user research - what do you
        think of Norman's comments? Is he just getting cranky as he gets
        older, or is this essay really just a sign of changing times?

        -- Alain:
        I agree with him completely.

        I especially liked his analysis of the contradiction in U* as it has
        been traditionally "preached" (and still seems to be by many outside of
        this mailing list). The contradiction is that all the while the field of
        usability was arguing for iterative and high bandwidth face-to-face
        communication for the process of designing the user experience, it was
        arguing for a waterfall approach for the project as a whole. In other
        words, "We, usability specialists do our U* stuff in a highly iterative
        high bandwidth communication fasion, then we throw our design over the
        wall to developpers who do their developper thing in whatever way they
        see fit".

        Norman's plea for U* professionals to: "Become an essential part of the
        team, so our input is provided simultaneously with everyone else's" is
        also something I think is right on. I have long believed that U*
        professionals can have the most impact down in the trenches. If they are
        not part of the decision process during development, their beautiful
        designs will inevitably get messed up when the reality of fixed deadline
        and budget hits. At the same time, customers and developers need their
        expertise to make good decisions about how to deliver the best possible
        software within those constraints.

        Note that this does not mean that there should not be any upfront U*
        design. In my view, for a 9 month project, a 1-2 week requirements
        workshop involving representatives from all stakeholders (customers,
        users, developers, sales) is definitely money well spent and it should
        not be hard to convince management to invest in this. What's wrong is
        not the idea of doing U* design upfront, it is the idea of doing 2
        months of design before you even start on your 9 month project.
        ----
      • Ash Donaldson
        ... Actually, Don never said doing user observation first was wrong (he wouldn¹t be a Human Factors Engineer if he did). He simply said that it should be
        Message 3 of 13 , Apr 17, 2006
        • 0 Attachment
          Re: [agile-usability] Don Norman on Agile Development On 18/4/06 2:23 AM, "Jeff Patton" <jpatton@...> wrote:

          This from Don Norman finally reached me [thanks Marjorie] - orginally
          posted April 2 according to my rss reader:
          Why doing user observation first is wrong
          http://www.jnd.org/dn.mss/why_doing_user_obser.html


          Actually, Don never said doing user observation first was wrong (he wouldn’t be a Human Factors Engineer if he did).  He simply said that it should be done to determine the human needs and therefore the project, not as part of the actual product project.    

          “Field studies, user observations, contextual analyses, and all procedures which aim at determining true human needs are still just as important as ever – but they should all be done outside of the product process. This is the information needed to determine what product to build, which projects to fund. Do not insist on doing them after the project has been initiated. Then it is too late, then you are holding everyone back.
          [..]
          So let’s separate the field and observational studies, the conceptual design work, and the needs analyses from the actual product project. We need to discover what users need before the project starts, for once started, the direction has already been determined...”

          As such, I wholeheartedly agree.  There are very few companies out there enlightened enough to do this sort of research up front.  I have a couple of clients that were recently frustrated with the results of my research.  We revealed that what they were proposing as a project would merely be a band aid for the root of the problem they were trying to solve.  This of course, was a pain for them as they could either:
          1. Soldier on and knock out a product that wouldn’t really solve their problem; or
          2. Scrap the project early and submit a new business case.

          Funnily enough – both went for the first option with the intention of going back to actually solve the problem with the next bucket of money.  So yes – user research *should* be done before a project is initiated – not once it is kicked off.  That said, the last 10 years has been a hard slog just to get people thinking about usability.  Perhaps true user needs that inform projects will take the next ten?

          Cheers,

          Ash Donaldson
        • Jeff Patton
          ... wouldn¹t ... should be ... part of ... I worry sometimes about quoting text from an article out of context, but I usually don t worry about quoting the
          Message 4 of 13 , Apr 17, 2006
          • 0 Attachment
            --- In agile-usability@yahoogroups.com, Ash Donaldson <ash@...> wrote:
            > Actually, Don never said doing user observation first was wrong (he
            wouldn¹t
            > be a Human Factors Engineer if he did). He simply said that it
            should be
            > done to determine the human needs and therefore the project, not as
            part of
            > the actual product project.

            I worry sometimes about quoting text from an article out of context,
            but I usually don't worry about quoting the title of the article out of
            context. ;-) So, you may be right that he never said that - rather
            just titled his article that. Obviously trying to be provacative.

            -Jeff
          • Ash Donaldson
            ... Understandably so. A couple of years back, I think Don took a leaf out of Jakob¹s book and started using titles that would also be Œprovocative¹ and
            Message 5 of 13 , Apr 17, 2006
            • 0 Attachment
              Re: [agile-usability] Re: Don Norman on Agile Development On 18/4/06 9:36 AM, "Jeff Patton" <jpatton@...> wrote:

              I worry sometimes about quoting text from an article out of context,
              but I usually don't worry about quoting the title of the article out of
              context.  ;-)  So, you may be right that he never said that - rather
              just titled his article that.  Obviously trying to be provacative.  

              Understandably so.  A couple of years back, I think Don took a leaf out of Jakob’s book and started using titles that would also be ‘provocative’ and start ‘religious debates’ as the title caught the eye - micro-content at its finest. ;)  

              Cheers,

              Ash Donaldson
            • Desilets, Alain
              Actually, Don never said doing user observation first was wrong (he wouldn t be a Human Factors Engineer if he did). He simply said that it should be done to
              Message 6 of 13 , Apr 18, 2006
              • 0 Attachment
                Message
                Actually, Don never said doing user observation first was wrong (he wouldn’t be a Human Factors Engineer if he did).  He simply said that it should be done to determine the human needs and therefore the project, not as part of the actual product project.     
                 
                -- Alain:
                But he also said that if user research was NOT done before the project was started, you should just take a deep breath and go with the flow, which I think is a lot more controversial.
                 
                I'm not sure I agree with him on this (this coming from a guy who is not big on upfront design). If my every instinct told me that the product concept was wrong, I probably wouldn't just go with the flow. I would probably want to do a small amount of user research  to see if I can shoot it down in 2 weeks. If I was not able to shoot it down that quickly, then I would interpret this as a sign that the product concept is not completely off-track after all.
                ---- 
              • Jeff Patton
                ... not ... Let s assume that Don is making another polarizing statement here as well. But, this one concerns me too. One misconception I see from the
                Message 7 of 13 , Apr 18, 2006
                • 0 Attachment
                  --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                  <alain.desilets@...> wrote:
                  > -- Alain:
                  > But he also said that if user research was NOT done before the project
                  > was started, you should just take a deep breath and go with the flow,
                  > which I think is a lot more controversial.
                  >
                  > I'm not sure I agree with him on this (this coming from a guy who is
                  not
                  > big on upfront design). If my every instinct told me that the product
                  > concept was wrong, I probably wouldn't just go with the flow.

                  Let's assume that Don is making another polarizing statement here as
                  well. But, this one concerns me too.

                  One misconception I see from the usability community on agile
                  development is that it's all or nothing - big research or no research,
                  exhaustive design effort, or no design effort. I'm uncomfortable with
                  both of these opposites.

                  I believe it's important to understand and capture what who we believe
                  our users are, and what we believe our business goals are - right or
                  wrong. Use some type of model to hold this information - a persona,
                  user profile, role model, whatever your skills allow you to most easily
                  create. I like some of Cooper's terms here [which I know I've
                  mentioned before]. Referring to these artifacts created early based on
                  assumptions or little research as a persona "hypothesis" or
                  a "provisional" persona. These become _design targets_ - not sure if
                  that term came from Cooper, but they use it as well. Basically we
                  design to those models.

                  It's OK to backfill user research - by that I mean do the research as
                  time allows and adjust your models accordingly. Of course this means
                  that if you're adjusting your design target that any design done so far
                  may now be off-target. But that's OK too. It just means you'll need
                  to make changes to software already built - but hopefully not yet
                  released.

                  To some this may sound inefficient - but to me this is the heart of
                  agility. The ability to learn, adapt, and change as your information
                  increases - coupled with a steady forward momentum to keep moving and
                  make the best decisions we can based on the information we have today.
                  If it's a risky decision because we have little information to make it
                  on, just say so. Let stakeholders decide to move forward or not. Then
                  make plans to mitigate risk - plans like backfilling user research if
                  necessary.

                  I worry that U* people might interpret Don's comment as a suggestion
                  that building even provisional user models isn't important. I think it
                  is, isn't big or time consuming, and it helps every design to the same
                  goals. -See previous comments I've made about the test-firsty-ness of
                  this way of approaching UI design. Basically no user models makes it
                  tough to validate the quality of early design work.

                  thanks,

                  -Jeff
                • Ron Jeffries
                  ... I m uncomfortable as well. But I question the extent to which these are misconceptions . To my reading, Alan Cooper is very clear that he intends no
                  Message 8 of 13 , Apr 18, 2006
                  • 0 Attachment
                    On Tuesday, April 18, 2006, at 12:50:41 PM, Jeff Patton wrote:

                    > One misconception I see from the usability community on agile
                    > development is that it's all or nothing - big research or no research,
                    > exhaustive design effort, or no design effort. I'm uncomfortable with
                    > both of these opposites.

                    I'm uncomfortable as well. But I question the extent to which these
                    are "misconceptions". To my reading, Alan Cooper is very clear that
                    he intends no development to be done while he's doing his magic on
                    usability. Larry is less so in person, but it's not hard to read his
                    writings as saying much the same thing.

                    When a large number of readers get the wrong impression from what I
                    write, I question whether it's appropriate to blame anyone but
                    myself.

                    I hope this isn't one of those cases. ;->

                    Ron Jeffries
                    www.XProgramming.com
                    Don't confuse more precise with better. -- Brian Marick
                  • Jeff Patton
                    ... research, ... with ... Of course you re right. [and you know a but but is coming] I m starting to take anything that anyone writes with a grain of salt.
                    Message 9 of 13 , Apr 18, 2006
                    • 0 Attachment
                      --- In agile-usability@yahoogroups.com, Ron Jeffries
                      <ronjeffries@...> wrote:
                      >
                      > On Tuesday, April 18, 2006, at 12:50:41 PM, Jeff Patton wrote:
                      >
                      > > One misconception I see from the usability community on agile
                      > > development is that it's all or nothing - big research or no
                      research,
                      > > exhaustive design effort, or no design effort. I'm uncomfortable
                      with
                      > > both of these opposites.
                      >
                      > I'm uncomfortable as well. But I question the extent to which these
                      > are "misconceptions". To my reading, Alan Cooper is very clear that
                      > he intends no development to be done while he's doing his magic on
                      > usability. Larry is less so in person, but it's not hard to read his
                      > writings as saying much the same thing.
                      >
                      > When a large number of readers get the wrong impression from what I
                      > write, I question whether it's appropriate to blame anyone but
                      > myself.

                      Of course you're right. [and you know a "but" but is coming]

                      I'm starting to take anything that anyone writes with a grain of
                      salt. By that I mean the hard black and white edges of opinions in
                      printed text seem to always express a polarized opinion. I find that
                      when I meet some of these folks in person, as I've been lucky enough
                      to do throughout the years, that their actual opinions are a lot more
                      gray - a lot more pragmatic. For example, I suspect few people would
                      guess strictly from your writing that your as sweet and reasonable as
                      you actually are. ;-)

                      But, I started this by saying you were right - which I believe you
                      are. The opinions expressed over the past several years within the
                      usability community, I believe, are changing. So to some degree
                      what's been written is dated. I'll predict over the next few years
                      you'll see see written opinions expressing a more collaborative agile
                      friendly face on the usability community - and explicit process
                      adjustments to support those opinions. In fact you already see them
                      in books such as Rapid Contextual Design.

                      Thanks for listening in Ron,

                      -Jeff
                    • Larry Constantine
                      ... Actually, I find that most of the time that I get misread it s because what I intend and write is actually more nuanced than the position people want to
                      Message 10 of 13 , Apr 18, 2006
                      • 0 Attachment
                        Ron Jeffries wrote:

                        > I'm uncomfortable as well. But I question the extent to which these
                        > are "misconceptions". To my reading, Alan Cooper is very clear that
                        > he intends no development to be done while he's doing his magic on
                        > usability. Larry is less so in person, but it's not hard to read his
                        > writings as saying much the same thing.
                        >
                        > When a large number of readers get the wrong impression from what I
                        > write, I question whether it's appropriate to blame anyone but
                        > myself.

                        Actually, I find that most of the time that I get misread it's because what
                        I intend and write is actually more nuanced than the position people want to
                        attribute to me. People want the simple, hard-edged, black-and-white
                        position. I have never been good at sound bites (which may be part of why
                        Jakob and Alan are so much better known and wealthier) because I am always
                        aware of the complexities and tradeoffs. As we consultants are wont to say,
                        "It depends."

                        (Of late I have become more aware of those who deliberately misread because
                        of their own agenda or biases. Present company excepted, of course.)

                        What I will readily acknowledge is that I have a preferred style of working
                        that definitely favors a deeper upfront process, but that doesn't mean I
                        think this is the right way or the only way. In truth, the luxury of working
                        that way has been the exception not the rule, and more often than not I have
                        found ways to fit into more iterative or on-the-fly approaches.

                        We should also keep in mind that there are many ways to mix agile methods
                        and interaction design, and I have personal experience with a number of
                        variants across the spectrum. I think there are often good reasons to chose
                        one method over another. In what might be called user-interaction-critical
                        applications (medical informatics, power systems control, industrial
                        automation,...) I have become convinced that thorough upfront modeling and
                        interaction design are best practices--which can then feed an iterative
                        XP-style development process with the designers serving as customer. Along
                        the way, the design can and does evolve, but it evolves from a well
                        conceived baseline within a carefully planned architecture. Other kinds of
                        applications may evolve more smoothly and efficiently from an altogether
                        different kind of mix.

                        I have corresponded with Don, and I do not believe he is trying to be
                        polarizing, although his titles are often provocative--no doubt
                        deliberately. (You have to get people to read what you are writing if there
                        is to be any communication at all.) But his positions are actually more
                        complex on closer analysis. (How much complexity and subtlety can one put
                        into a one-line title anyway?)

                        I do not see, as some have, that his recent and more controversial writing
                        is some kind of reversal or recantation of his earlier positions. I actually
                        think that many may have been misreading Norman for a very long time. For
                        example, the Encyclopedia of Human-Computer Interaction credits Norman with
                        originating the term "user-centered design" and then cites his original four
                        principles: (1) Make it easy to determine possible actions at any moment.
                        (2) Make things visible, including the conceptual model of the system, the
                        alternative actions, and the results of actions. (3) Make it easy to
                        evaluate the current state of the system. (4) Follow natural mappings
                        between intentions and the required actions; between actions and the
                        resulting effect; and between [visible information and the system state].
                        The encyclopedia entry then states, "These recommendations place the user at
                        the center of the design." This is a blatant non sequitur. The principles
                        actually place user actions, not users, at the focal point, a distinction of
                        no small consequence, as I have been arguing for years. The entry then
                        contradicts itself in continuing by stating, "The role of the designer is to
                        facilitate the task for the user and to make sure that the user is able to
                        make use of the product as intended and with a minimum effort to learn how
                        to use it." Which, again, is actually about action, task, and activity more
                        than about users.

                        Which is why I am working to make activity theory more systematic and
                        accessible to designers: to enable them to model and understand activity as
                        quickly and agilely as practical so they can collaborate better with agile
                        developers like you. :-)

                        --Larry Constantine, IDSA
                        Director, Laboratory for Usage-centered Software Engineering (Lab-USE)
                        Professor, Department of Mathematics & Engineering
                        University of Madeira, Funchal, Portugal
                      • Ron Jeffries
                        ... Yes ... often it seems to me that people want those simple statements. Unlike you, I am more inclined to start with the simple statements, on the
                        Message 11 of 13 , Apr 18, 2006
                        • 0 Attachment
                          On Tuesday, April 18, 2006, at 3:04:27 PM, Larry Constantine wrote:

                          > Actually, I find that most of the time that I get misread it's because what
                          > I intend and write is actually more nuanced than the position people want to
                          > attribute to me. People want the simple, hard-edged, black-and-white
                          > position. I have never been good at sound bites (which may be part of why
                          > Jakob and Alan are so much better known and wealthier) because I am always
                          > aware of the complexities and tradeoffs. As we consultants are wont to say,
                          > "It depends."

                          Yes ... often it seems to me that people want those simple
                          statements. Unlike you, I am more inclined to start with the simple
                          statements, on the assumption that people will be smart enough to go
                          beyond the simple as they discover the need.

                          Unfortunately, some do not, just doing the same old thing that
                          doesn't work, and others conclude that since they went beyond the
                          simple, the simple advice was altogether wrong.

                          It's a puzzlement ...

                          > (Of late I have become more aware of those who deliberately misread because
                          > of their own agenda or biases. Present company excepted, of course.)

                          One fondly hopes ...

                          > ...
                          > What I will readily acknowledge is that I have a preferred style of working
                          > that definitely favors a deeper upfront process, but that doesn't mean I
                          > think this is the right way or the only way. In truth, the luxury of working
                          > that way has been the exception not the rule, and more often than not I have
                          > found ways to fit into more iterative or on-the-fly approaches.

                          Yes ... both your preference, and your knowledge of how to fit into
                          more iterative approaches, have come clear to me through my
                          attendance at your conference, through our occasional chats, and
                          through notes on the lists. And of course there were a number of
                          attendees at the conference who are doing quite interactive
                          approaches. We're fortunate to have Jeff here as one example.

                          > Which is why I am working to make activity theory more systematic and
                          > accessible to designers: to enable them to model and understand activity as
                          > quickly and agilely as practical so they can collaborate better with agile
                          > developers like you. :-)

                          And perhaps even good ones, too. ;->

                          Ron Jeffries
                          www.XProgramming.com
                          If another does not intend offense, it is wrong for me to seek it;
                          if another does indeed intend offense, it is foolish for me to permit it.
                          -- Kelly Easterley
                        • Adam Sroka
                          ... I have been reading the Pragmatic Programmers new title Practices of an Agile Developer by Venkat Subramanian and Andy Hunt, which I heartily recommend.
                          Message 12 of 13 , Apr 18, 2006
                          • 0 Attachment
                            Larry Constantine wrote:
                            > What I will readily acknowledge is that I have a preferred style of working
                            > that definitely favors a deeper upfront process, but that doesn't mean I
                            > think this is the right way or the only way. In truth, the luxury of working
                            > that way has been the exception not the rule, and more often than not I have
                            > found ways to fit into more iterative or on-the-fly approaches.
                            >
                            > We should also keep in mind that there are many ways to mix agile methods
                            > and interaction design, and I have personal experience with a number of
                            > variants across the spectrum. I think there are often good reasons to chose
                            > one method over another. In what might be called user-interaction-critical
                            > applications (medical informatics, power systems control, industrial
                            > automation,...) I have become convinced that thorough upfront modeling and
                            > interaction design are best practices--which can then feed an iterative
                            > XP-style development process with the designers serving as customer. Along
                            > the way, the design can and does evolve, but it evolves from a well
                            > conceived baseline within a carefully planned architecture. Other kinds of
                            > applications may evolve more smoothly and efficiently from an altogether
                            > different kind of mix.
                            >
                            I have been reading the Pragmatic Programmers' new title "Practices of
                            an Agile Developer" by Venkat Subramanian and Andy Hunt, which I
                            heartily recommend. Recently, I was reading a section where the brought
                            up the idea of upfront design and the oft quoted building construction
                            analogy.

                            My own thoughts: If you ask a building contractor they will tell you
                            that the plan is never half of the final solution. There are always
                            mistakes in production that require creative fixes and mistakes in the
                            plan that require it to be rewritten or ignored. Most builders think
                            that architects are strange folk who live in a world of mathematical
                            constructs that almost resemble reality in a sort of humorous way. It is
                            probably not a coincidence that most computer users think of programmers
                            the same way. At the same time, the idea of constructing a building
                            without a plan, going to customers and other experts periodically to ask
                            questions that help to elucidate the solution sounds completely
                            ridiculous to a builder. Of course you need a plan. It is just that the
                            plan is *going* to be wrong and you will have to adapt or you will lose
                            your shirt.

                            I am not an expert in interaction design, although as a consultant I do
                            my best to advocate for it in environments where it is often completely
                            ignored. It does not surprise me that interaction design feels a lot
                            like building. Putting together a screen without a plan often leads to
                            screens that are functional but not usable. Like a building that is
                            structurally sound but without windows. Still, the plan rarely gives you
                            even half of the real solution. Inevitably customers will want things
                            that aren't in the plan, or they will see something in the plan that the
                            do not want or are not willing to pay for. We have to respond to our
                            customer, but if we want a usable application we also have to design
                            something usable.

                            I think that in XP and other agile methodologies we often focus on
                            emergent design which is a property of domain modeling not of
                            interaction design. The key difference is that the domain model is a
                            means of communicating the business to the machine with programmers as
                            the translators between these two superficially incompatible worlds.
                            Like any interpreter programmers don't know what the customer needs to
                            say to the machine, but they do know how to talk to it, which the
                            customer does not. Still, to be successful they must listen to the
                            customer, because communication requires understanding.

                            On the other hand, interaction design is about giving the user the
                            ability to interact with the domain model in a way which insulates them
                            from the details. This is a more complex task, because the programmers
                            won't be there when the user interacts with the system, and they won't
                            be able to clear up the misunderstandings. In a perfect world the domain
                            model has been designed to capture the business. So, the interface must
                            only provide access to a (mostly) correct model. Consistency and
                            comprehensibility, which often masquerades as "intuitiveness," are the
                            keys here not adaptability to change which is the key to human-human
                            interaction ;-)

                            Anyway, it's not my intent here to get off on a rant. Suffice to say: I
                            believe that adaptability to change, which is the principle
                            characteristic of agile methods, is the principle idea in domain
                            modeling. I also believe that interaction design must remain adaptable
                            enough to respond to the needs and desires of the customer. But, I
                            believe that a patterned design based on principles of consistency and
                            comprehensibility is more important than agility when it comes to
                            human-machine interaction. Agility can be a close second ;-)
                          • Robin Dymond
                            Interesting thread. I am glad that this view is starting to be taken by thought leaders in the U* community. I hope this quote gets widely circulated. I know
                            Message 13 of 13 , Apr 19, 2006
                            • 0 Attachment
                              Interesting thread. I am glad that this view is starting to be taken by thought leaders in the U* community. I hope this quote gets widely circulated.
                               
                              I know that in companies where U* is important, the UX component is often iterative, but the implementation is waterfall (over the wall). This situation leads to all the many failure modes of waterfall, including:
                              • Too long, too much time and $$ spent in design, resulting in reduced, or in some cases no functionality being released.
                              • Design that is not implementable, or has major flaws in logic.
                              • Missed requirements
                              • Difficulty accommodating change as the team and customer learn about their needs
                              • Emphasis on Project artifacts (requirements, user flows, photoshop) instead of working
                              • Developers on a death march to build the system
                              • Testers with literally no time to test
                              • Poor quality code released into production
                              • Angry customers
                              • Systems that don't meet the business needs of the customer
                              If the UX is perfect is the system is implementable? For example, in one case, the UX design for a reservation system called for non-smoking to specified as a room filter, but that data was not available at that stage from the database. This is a small example but this kind of issue occurred very often.
                               
                              Agile is delivering working systems much much more effectively, and with time to market that is 1/3 that of conventional projects. This ROI means there is a much heavier business driver to use Agile over UX. Getting UX in the door is a key passion for me, but as a complement to, not at the expense of agile methods.
                               
                              cheers,
                              Robin Dymond
                               
                            Your message has been successfully submitted and would be delivered to recipients shortly.