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

RE: [agile-usability] What is the the One UX book to read?

Expand Messages
  • Jim Kauffman
    ... That s a good suggestion, but for such a mixed audience I d recommend: Don t Make Me Think: A Common Sense Approach to Web Usability (2nd Edition) by Steve
    Message 1 of 15 , Sep 1, 2006
    • 0 Attachment
      > -----Original Message-----
      > From: agile-usability@yahoogroups.com
      > [mailto:agile-usability@yahoogroups.com] On Behalf Of haimhirsch
      > Sent: Friday, September 01, 2006 1:25 PM
      > To: agile-usability@yahoogroups.com
      > Subject: [agile-usability] What is the the One UX book to read?
      >
      > (I apologize for the cross-posting)
      >
      > I have a unique opportunity - we are kicking off a UX program
      > to raise awareness and increase involvement with UX
      > activities within our organization, and I have been asked -
      > what one book could we give to everyone to get them excited
      > about focusing on the UX, and UCD?
      >
      > There are about 300 people who will be part of this initial
      > launch, comprised of Heavy IT (programmers, software
      > engineers) running through Project managers and analysts of
      > various types, and also including business representatives
      > (people who work with sales and marketing and represent their
      > needs to the web development groups). We all, in some
      > fashion, develop the web site/s for a single company.
      >
      > One suggestion was, "The Design of Everyday Things."

      That's a good suggestion, but for such a mixed audience I'd recommend:

      Don't Make Me Think: A Common Sense Approach to Web Usability (2nd Edition)
      by Steve Krug


      -Jim Kauffman
    • Fred Beecher
      ... I strongly second that recommendation. - Fred
      Message 2 of 15 , Sep 1, 2006
      • 0 Attachment
        On 9/1/06, Jim Kauffman <jkauff@...> wrote:
        >
        > > One suggestion was, "The Design of Everyday Things."
        >
        > That's a good suggestion, but for such a mixed audience I'd recommend:
        >
        > Don't Make Me Think: A Common Sense Approach to Web Usability (2nd Edition)
        > by Steve Krug

        I strongly second that recommendation.

        - Fred
      • billpawlak
        ... Edition) ... Third(ed). bill
        Message 3 of 15 , Sep 1, 2006
        • 0 Attachment
          > On 9/1/06, Jim Kauffman <jkauff@...> wrote:
          > >
          > > > One suggestion was, "The Design of Everyday Things."
          > >
          > > That's a good suggestion, but for such a mixed audience I'd recommend:
          > >
          > > Don't Make Me Think: A Common Sense Approach to Web Usability (2nd
          Edition)
          > > by Steve Krug
          >
          > I strongly second that recommendation.
          >

          Third(ed).

          bill
        • Adrian Howard
          ... Why? It s one of the ones I often recommend to and people seem to manage to separate the message from the rhetoric pretty well. Sure there s a lot in the
          Message 4 of 15 , Sep 2, 2006
          • 0 Attachment
            On 1 Sep 2006, at 20:38, Desilets, Alain wrote:

            > If you have lots of IT people in your crowd, then definitely DON'T use
            > "The inmates are running the asylumn" ;-).

            Why?

            It's one of the ones I often recommend to and people seem to manage
            to separate the message from the rhetoric pretty well.

            Sure there's a lot in the anti-developer message that get from the
            book I disagree with - but there's also a heck of a lot of useful
            stuff in there too.

            Also - shaking people up a bit can sometimes be useful :)

            Adrian
          • Adrian Howard
            On 1 Sep 2006, at 18:24, haimhirsch wrote: [snip] ... [snip] I d second that. Don t Make Me Think is also good, but I think misses some of the broader message
            Message 5 of 15 , Sep 2, 2006
            • 0 Attachment
              On 1 Sep 2006, at 18:24, haimhirsch wrote:
              [snip]
              > One suggestion was, "The Design of Everyday Things."
              [snip]

              I'd second that.

              Don't Make Me Think is also good, but I think misses some of the
              broader message of DOET.

              Adrian
            • Desilets, Alain
              It s one of the ones I often recommend to and people seem to manage to separate the message from the rhetoric pretty well. Sure there s a lot in the
              Message 6 of 15 , Sep 5, 2006
              • 0 Attachment
                It's one of the ones I often recommend to and people seem to manage
                to separate the message from the rhetoric pretty well.

                Sure there's a lot in the anti-developer message that get from the
                book I disagree with - but there's also a heck of a lot of useful
                stuff in there too.

                -- Alain:
                I agree that there is a lot of useful stuff in there. The problem is, as
                you point out, that there is also much anti-programmer rhetoric in
                there, and that makes it hard to focus on the useful stuff if you are a
                programmer. I'm a pretty open-minded kind of guy, and am very
                sympathetic to the usability-matters message. Yet, I had trouble
                focusing on the content. I suspect developers who are not so sensitive
                to usability will simply discard the message altogether.

                But maybe you have a different experience. When you say that you often
                recommend this to people, does that include programmers who not already
                pre-conditioned to the message of the book?
                ----

                Also - shaking people up a bit can sometimes be useful :)

                -- Alain:
                I agree. But you have to shake them in the right way.

                For example, putting developers behind a 1-way mirror, to witness
                otherwise intelligent users struggle with the software is a good way of
                shaking them up.

                Telling them that they are a bunch of immature geeks turned prima-donna
                is NOT the right way to shake them up.
                ----
              • Frank Maurer
                Theinmatesbookcertainlyisanicereadbutitheavilystepsonthetoesofdevelopers.Thenthereisthe messagethatusersdonotknowwhattheyneedbutneedthehelpofinteraction
                Message 7 of 15 , Sep 5, 2006
                • 0 Attachment
                  The inmates book certainly is a nice read but it heavily steps on the toes of developers. Then there is the 
                  message that users do not know what they need but need the help of interaction designers/usability specialists to
                  tell them that. I'm always surprised how a community that is so much focused on people interactions
                  can so strongly stump on the feet of the two key stakeholder groups of the software development process ;-)
                  Maybe that is the reason why usability approaches take so long to be adopted in industry while agile methods
                  seem to be very quick to cross the chasm.
                   
                  Frank


                  From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Desilets, Alain
                  Sent: Tuesday, September 05, 2006 7:53 AM
                  To: agile-usability@yahoogroups.com
                  Subject: RE: [agile-usability] What is the the One UX book to read?

                  It's one of the ones I often recommend to and people seem to manage
                  to separate the message from the rhetoric pretty well.

                  Sure there's a lot in the anti-developer message that get from the
                  book I disagree with - but there's also a heck of a lot of useful
                  stuff in there too.

                  -- Alain:
                  I agree that there is a lot of useful stuff in there. The problem is, as
                  you point out, that there is also much anti-programmer rhetoric in
                  there, and that makes it hard to focus on the useful stuff if you are a
                  programmer. I'm a pretty open-minded kind of guy, and am very
                  sympathetic to the usability-matters message. Yet, I had trouble
                  focusing on the content. I suspect developers who are not so sensitive
                  to usability will simply discard the message altogether.

                  But maybe you have a different experience. When you say that you often
                  recommend this to people, does that include programmers who not already
                  pre-conditioned to the message of the book?
                  ----

                  Also - shaking people up a bit can sometimes be useful :)

                  -- Alain:
                  I agree. But you have to shake them in the right way.

                  For example, putting developers behind a 1-way mirror, to witness
                  otherwise intelligent users struggle with the software is a good way of
                  shaking them up.

                  Telling them that they are a bunch of immature geeks turned prima-donna
                  is NOT the right way to shake them up.
                  ----

                • Jim Kauffman
                  In my 15 years of working with users, I ve found they usually DON T know what they need. That doesn t mean there aren t users who think about how they do what
                  Message 8 of 15 , Sep 5, 2006
                  • 0 Attachment
                    In my 15 years of working with users, I've found they usually DON'T know what they need. That doesn't mean there aren't users who think about how they do what they do, and how it could be improved, but I've come across them only rarely.
                     
                    Problem One is that most users have adapted to the shortcomings of the software they must use (Windows is a case in point) and have a hard time envisioning what improvements could be made. In interviewing users, I typically have to dig for this information by having them explain and demonstrate their daily tasks to me, in excruciating detail, as if I were the dumbest person on earth. Only then do I find out that it takes four clicks to get information that he/she needs to look at several times an hour. When I ask if it wouldn't be better if that information were one click away, or always visible, they tell me "Oh, yes, that WOULD help a lot." That's not telling users what they need, it's discovering what they need in a collaborative, guided way.
                     
                    Problem Two is that sometimes it's not the software that needs to be changed (at least not right away), but the business process and the task flow that supports it. That involves more probing investigation, usually with stakeholders who are at the level of management just above the end users. You need to find out exactly what shortcomings of the process or the system are causing them to get hammered by their bosses. After all, management is spending money on usability specialists because there's a problem somewhere, and if the users and their supervisors could identify the problem and offer solutions, they surely would.
                     
                    The point of all this is that Yes, we are very focused on people interactions, but not in a passive way. Developers sometimes give us a hard time because making usable software often creates more work for them, and slows the development process. You have to get their buy-in by stressing that if it's done right the first time, it's not going to come back to them as re-work. I've also found over the years that the vast majority of developers take tremendous pride in their work, and want to do right by the users. They're truly shocked and dismayed when they sit in on a usability testing session and see the users struggle with their software. 
                     
                    -Jim Kauffman


                    From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Frank Maurer
                    Sent: Tuesday, September 05, 2006 10:41 AM
                    To: agile-usability@yahoogroups.com
                    Subject: RE: [agile-usability] What is the the One UX book to read?

                    The inmates book certainly is a nice read but it heavily steps on the toes of developers. Then there is the 
                    message that users do not know what they need but need the help of interaction designers/usability specialists to
                    tell them that. I'm always surprised how a community that is so much focused on people interactions
                    can so strongly stump on the feet of the two key stakeholder groups of the software development process ;-)
                    Maybe that is the reason why usability approaches take so long to be adopted in industry while agile methods
                    seem to be very quick to cross the chasm.
                     
                    Frank
                  • Desilets, Alain
                    Sure there s a lot in the anti-developer message that get from the book I disagree with - but there s also a heck of a lot of useful stuff in there too. --
                    Message 9 of 15 , Sep 5, 2006
                    • 0 Attachment
                      Sure there's a lot in the anti-developer message that get from the
                      book I disagree with - but there's also a heck of a lot of useful
                      stuff in there too.

                      -- Alain:
                      Actually, even if you are able to make abstraction of the anti-developer
                      rethoric, the actual message is also very irritating to developers,
                      especially agile ones.

                      For example, Cooper is very clear that:

                      - Developers should take NO part in designing the interaction or
                      gathering requirements. They should not even be present in the room when
                      U* people do their stuff with clients.

                      - Once U* people have designed the interaction structure of the system,
                      developers should implement it EXACTLY AS IS.

                      That's about as anti-agile as you can get. Not surprisingly, Cooper
                      complains bitterly in the introduction to his book that most of his
                      team's beautiful designs never get implemented. That tends to happen
                      when you design things without consulting thowe who will eventually have
                      to build it.

                      Alain
                      ----
                    • Pascal Roy
                      Alain, As a developer with very little U* knowledge, I wasn’t really shocked by Cooper’s frustration with developers when I read the book a while back.
                      Message 10 of 15 , Sep 5, 2006
                      • 0 Attachment

                        Alain,

                         

                        As a developer with very little U* knowledge, I wasn’t really shocked by Cooper’s frustration with developers when I read the book a while back. Actually, I felt I did learn a great deal while reading it and a lot of what he said made perfect sense to me. However, I’m not surprised his approach of dumping the U* people designs on the developers doesn’t work the same way that dumping the architect’s system designs on the developers doesn’t really work either. What I took out of this book is that developers should probably pay a little more attention to what the users are trying to achieve and how they view (their mental image) the system rather than build the system according to what they think the users need or what is easiest to build.

                         

                        I do think that any developer will be a  better developer with at least some U* knowledge. We can’t be experts in everything, but knowing a little bit of everything (generalists) makes you appreciate the value of having the expert around. I don’t think developers currently have enough U* knowledge to be able to gage the value of U* people.  

                         

                        In an agile team where U* people are fully integrated, the U* design would come from the whole team like everything else, with most likely greater input from the U* people. Of course, for that to work, the team has to be aware and respect what the U* people bring to the equation. Otherwise, it will likely not even let the U* people contribute.

                         

                        Pascal Roy, ing./P.Eng., PMP

                        Vice-Président/Vice President

                        Elapse Technologies Inc.

                         

                        [url]    http://www.elapsetech.com

                        [email]  pascal.roy@...

                        [cell]   514-862-6836

                         

                         


                        From: agile-usability@... m [mailto: agile-usability@... m ] On Behalf Of Desilets, Alain
                        Sent: 5 septembre 2006 14:32
                        To: agile-usability@... m
                        Subject: RE: [agile-usability] What is the the One UX book to read?

                         

                        Sure there's a lot in the anti-developer message that get from the
                        book I disagree with - but there's also a heck of a lot of useful
                        stuff in there too.

                        -- Alain:
                        Actually, even if you are able to make abstraction of the anti-developer
                        rethoric, the actual message is also very irritating to developers,
                        especially agile ones.

                        For example, Cooper is very clear that:

                        - Developers should take NO part in designing the interaction or
                        gathering requirements. They should not even be present in the room when
                        U* people do their stuff with clients.

                        - Once U* people have designed the interaction structure of the system,
                        developers should implement it EXACTLY AS IS.

                        That's about as anti-agile as you can get. Not surprisingly, Cooper
                        complains bitterly in the introduction to his book that most of his
                        team's beautiful designs never get implemented. That tends to happen
                        when you design things without consulting thowe who will eventually have
                        to build it.

                        Alain
                        ----


                        __________ Information NOD32 1.1740 (20060905) __________

                        Ce message a ete verifie par NOD32 Antivirus System.
                        http://www.nod32.com

                      • Desilets, Alain
                        What I took out of this book is that developers should probably pay a little more attention to what the users are trying to achieve and how they view (their
                        Message 11 of 15 , Sep 5, 2006
                        • 0 Attachment
                          Message
                          What I took out of this book is that developers should probably pay a little more attention to what the users are trying to achieve and how they view (their mental image) the system rather than build the system according to what they think the users need or what is easiest to build.

                           

                          I do think that any developer will be a  better developer with at least some U* knowledge. We can’t be experts in everything, but knowing a little bit of everything (generalists) makes you appreciate the value of having the expert around. I don’t think developers currently have enough U* knowledge to be able to gage the value of U* people.  

                           

                          In an agile team where U* people are fully integrated, the U* design would come from the whole team lik

                          (Message over 64 KB, truncated)

                        • hetenpost
                          Hello everybody it is my firs post here I really like the group so far I m looking for a good book as well but not necessary a book that is readable for
                          Message 12 of 15 , Sep 20, 2006
                          • 0 Attachment
                            Hello everybody it is my firs post here I really like the group so far

                            I'm looking for a good book as well but not necessary a book that is
                            readable for anyone. there are some books like

                            Prioritizing Web Usability
                            Interaction Design
                            Designing Interfaces
                            etc

                            are they any good or is the same info in"

                            The Design of Everyday Things and Don't make me think

                            Stefan

                            --- In agile-usability@yahoogroups.com, Adrian Howard <adrianh@...>
                            wrote:
                            >
                            >
                            > On 1 Sep 2006, at 18:24, haimhirsch wrote:
                            > [snip]
                            > > One suggestion was, "The Design of Everyday Things."
                            > [snip]
                            >
                            > I'd second that.
                            >
                            > Don't Make Me Think is also good, but I think misses some of the
                            > broader message of DOET.
                            >
                            > Adrian
                            >
                          • Scott Rippon
                            G day Haim I think Don Norman s The Design of Everyday Things and Steve Krug s Don t Make Me Think are both excellent books. Another book that I m a really big
                            Message 13 of 15 , Nov 15, 2006
                            • 0 Attachment
                              G'day Haim

                              I think Don Norman's The Design of Everyday Things and Steve Krug's Don't Make Me Think
                              are both excellent books.

                              Another book that I'm a really big fan of is Jesse James Garrett's The Elements of User
                              Experience (http://www.jjg.net/elements/). I think it's an excellent introductory text which is
                              very accessible and does a really good job in explaining how the different elements all piece
                              together. I've leant my copy to a number of managers and developers and gotten positive
                              feedback from them.

                              Sorry for the tardiness of this reply. If the launch has already been I hope it went well :)

                              All the best with it all.

                              Kind regards,
                              Scott.
                            Your message has been successfully submitted and would be delivered to recipients shortly.