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

FUBU

Expand Messages
  • Jeff Patton
    I m writing this from a room full of rocket-surgeon Ruby developers. Normally I d refer to myself as a developer also. But, in this room that would be
    Message 1 of 13 , Feb 15, 2006
    • 0 Attachment
      I'm writing this from a room full of rocket-surgeon Ruby developers.
      Normally I'd refer to myself as a developer also. But, in this room
      that would be laughable – these guys are that good.

      They're tool builders. That is to say that when they need a tool to
      do something, they just write it. Need to manage user stories in a
      distributed way? - write something. Need a new Ruby IDE? - write
      it. Normally writing a tool might delay or distract you from what
      you're doing, but these guys are really fast, and they don't get
      distracted long. They add a little to a tool they were working on to
      support what they want to do right now, then get back to work. Very
      pragmatic.

      Since I'm in the room they ask me usability questions. I'm generally
      surprised at the really remarkable things they've already done.
      There are generally not many refinement ideas I can offer that they
      haven't already considered.

      In other rants/posts I've used the term "self-centered design" [SCD]
      to describe software designed with one's self as the reference user.
      That's a bad idea if it's a manager designing for his staff, or a
      software developer designing for 68 year old retiree planning a
      European vacation. But, it's a pretty good idea if it's a seasoned
      developer designing for other seasoned developers. So, it occurred
      to me in those situations that this isn't self-centered design
      [because no one wants to be self centered – except possibly Paris
      Hilton] – this is FUBU [http://en.wikipedia.org/wiki/FUBU%5d. For
      those who don't know, FUBU is a brand of clothing – FUBU being short
      for "for us, by us."

      It also occurs to me that many Agile approaches focus on that FUBU
      principal – that is if you get the right user on sight, they could
      design software for their own use. Now adopting a philosophy like
      that isn't hard if you're a software developer – since you design and
      use a lot of FUBU – you've seen it work. But, thinking everyone can
      do it is an act of self substitution – self-centered design. – since
      most people don't write and use software 12 hours a day, they may be
      less comfortable with the wide variety of interaction design choices
      that exist to accomplish a specific goal using software.

      So, what's my point? I have none – at least no big point. Just
      these observations: developers often design good software for
      developers: FUBU. Other often design pretty good software for their
      own use: FUBU. Doing so can lead one to the false sense of belief
      that design is easy – and you can do it for anyone, or anyone else
      can do it for themselves: self-centered design.

      comments invited, and thanks for listening/reading.
      [I really should get a blog and stop using this list as one. ;-) ]
    • Elizabeth Whitworth
      Hello Jeff, Thanks for the comment. I can t speak for anyone else, but I enjoy being on this list exactly *because of this kind of random and valuable insight
      Message 2 of 13 , Feb 15, 2006
      • 0 Attachment
        Hello Jeff,

        Thanks for the comment. I can't speak for anyone else, but I enjoy being on this list exactly *because of this kind of random and valuable insight into agile usability from the people on it. Tell the truth, if this was posted on a blog, even with rss, the chances of my reading it would be significantly less.

        So thanks :-)
         - Elizabeth.

        On 2/15/06, Jeff Patton <jpatton@...> wrote:
        I'm writing this from a room full of rocket-surgeon Ruby developers. 
        Normally I'd refer to myself as a developer also.  But, in this room
        that would be laughable – these guys are that good. 

        They're tool builders.  That is to say that when they need a tool to
        do something, they just write it.  Need to manage user stories in a
        distributed way? - write something.  Need a new Ruby IDE? - write
        it.  Normally writing a tool might delay or distract you from what
        you're doing, but these guys are really fast, and they don't get
        distracted long.  They add a little to a tool they were working on to
        support what they want to do right now, then get back to work.  Very
        pragmatic.

        Since I'm in the room they ask me usability questions.  I'm generally
        surprised at the really remarkable things they've already done. 
        There are generally not many refinement ideas I can offer that they
        haven't already considered.

        In other rants/posts I've used the term "self-centered design" [SCD]
        to describe software designed with one's self as the reference user. 
        That's a bad idea if it's a manager designing for his staff, or a
        software developer designing for 68 year old retiree planning a
        European vacation.  But, it's a pretty good idea if it's a seasoned
        developer designing for other seasoned developers.  So, it occurred
        to me in those situations that this isn't self-centered design
        [because no one wants to be self centered – except possibly Paris
        Hilton] – this is FUBU [http://en.wikipedia.org/wiki/FUBU].  For
        those who don't know, FUBU is a brand of clothing – FUBU being short
        for "for us, by us." 

        It also occurs to me that many Agile approaches focus on that FUBU
        principal – that is if you get the right user on sight, they could
        design software for their own use.  Now adopting a philosophy like
        that isn't hard if you're a software developer – since you design and
        use a lot of FUBU – you've seen it work.  But, thinking everyone can
        do it is an act of self substitution – self-centered design. – since
        most people don't write and use software 12 hours a day, they may be
        less comfortable with the wide variety of interaction design choices
        that exist to accomplish a specific goal using software. 

        So, what's my point?  I have none – at least no big point.  Just
        these observations: developers often design good software for
        developers: FUBU.  Other often design pretty good software for their
        own use: FUBU.  Doing so can lead one to the false sense of belief
        that design is easy – and you can do it for anyone, or anyone else
        can do it for themselves: self-centered design.

        comments invited, and thanks for listening/reading. 
        [I really should get a blog and stop using this list as one.  ;-) ]







        SPONSORED LINKS
        Usability testing Usability Agile software development
        Agile development


        YAHOO! GROUPS LINKS




      • Desilets, Alain
        So, what s my point? I have none - at least no big point. Just these observations: developers often design good software for developers: FUBU. Other often
        Message 3 of 13 , Feb 15, 2006
        • 0 Attachment
          So, what's my point? I have none - at least no big point. Just
          these observations: developers often design good software for
          developers: FUBU. Other often design pretty good software for their
          own use: FUBU. Doing so can lead one to the false sense of belief
          that design is easy - and you can do it for anyone, or anyone else
          can do it for themselves: self-centered design.

          comments invited, and thanks for listening/reading.
          [I really should get a blog and stop using this list as one. ;-) ]

          -- Alain:
          I think if you have written good FUBU software, you might be able to
          write decent FOBU (For Others, By Us) software also, because you are
          already in the right frame of mind. In other words, you paid a lot of
          attention to yourself as an end user, so you will probably pay
          atttention to those Others as end users. In my view, once your whole
          team has assimilated the "pay attention to the end user" mentra, you are
          80% of the way there.

          Of course, a pitfall is that the developpers might not realise that
          these Other users are not like them... That's the "you are not the user
          (although you may be like them in many respects)" mentra. But I would
          think that this second mentra comes easily once you have assimilated the
          first one.
          ----
        • Jared M. Spool
          ... Jeff: Brilliant post -- I ll be stealing ideas from it for months to come! Alain: I worked in the Software Engineering groups for DEC and Symbolics for
          Message 4 of 13 , Feb 15, 2006
          • 0 Attachment
            At 03:54 PM 2/15/2006, Desilets, Alain wrote:
            >I think if you have written good FUBU software, you might be able to
            >write decent FOBU (For Others, By Us) software also, because you are
            >already in the right frame of mind. In other words, you paid a lot of
            >attention to yourself as an end user, so you will probably pay
            >atttention to those Others as end users. In my view, once your whole
            >team has assimilated the "pay attention to the end user" mentra, you are
            >80% of the way there.

            Jeff: Brilliant post -- I'll be stealing ideas from it for months to come!

            Alain: I worked in the Software Engineering groups for DEC and Symbolics
            for many years. I can speak volumes about the FUBU mentality, as that's how
            both of those organizations thrived and, ironically, died.

            These groups had some of the smartest people I've ever had the chance to
            work with. It was incredible.

            Yet, the FUBU mentality really ferments a mindset that makes it hard to
            step back and say, "Maybe we don't really know what makes sense here for
            the real users."

            I just finished reading this brilliant piece in this month's Harvard
            Business Review called "Defeating Feature Fatigue" which talks about how
            consumers choose products. In their study, consumers, when given the chance
            to design a custom digital video player, piled all sorts of features in,
            even though they were keenly aware it would hurt the usability of the design.

            In a FUBU space, where the act of design is part of the mental model
            development, little consideration is given to "how people are going to
            learn this." This makes the transition much harder, in my opinion.

            Both the DEC and Symbolics folks I worked with created some really
            innovative stuff. Stuff that was way ahead of what we still have today.
            But, it was packaged in such a complex environment that it was pretty much
            doomed to fail from the start.

            I don't think you can transition from FUBU to a FOBU environment without a
            major culture shift. (And probably an execution or two.)

            Jared


            Jared M. Spool, Founding Principal, User Interface Engineering
            4 Lookout Lane, Unit 4d, Middleton, MA 01949
            978 777-9123 jspool@... http://www.uie.com
            Blog: http://www.uie.com/brainsparks
          • klancaster1957
            ... user ... the ... I have to relate a quick story here. I do QA/usability on a large project and also have an extensive background in development. I was
            Message 5 of 13 , Feb 15, 2006
            • 0 Attachment
              --- In agile-usability@yahoogroups.com, "Desilets, Alain" <alain.desilets@...> wrote:

              >
              > Of course, a pitfall is that the developpers might not realise that
              > these Other users are not like them... That's the "you are not the user
              > (although you may be like them in many respects)" mentra. But I would
              > think that this second mentra comes easily once you have assimilated the
              > first one.
              > ----

              I have to relate a quick story here. I do QA/usability on a large project and also have an extensive background in development. I was talking to one of the developers about an error handling web page that they were using when severe (fatal) errors occurred. It had a somewhat understandable message, followed by the file name where the error occured, the name of the Java class that was the problem, and some trace statements. The conversation went something like the following:

              Me:  "The system already knows where the error occured and can alert the support or development staff to the problem via email."

              Developer: "We need this message for the end users."

              Me: "The end users? They are not going to understand this message, are they?"

              Developer: "Yes they are. I said its for the end users - the developers!"

              Me: "Sigh"

              BTW, the scheme here was that the real end users, policemen in this case, would call support and read the exception data to the support person, who would write it down and email it to the developer.

              Keith

            • Dave Churchville
              ... for ... pretty much ... without a ... Yes, I agree with this. One thing I ve been contemplating is that maybe it isn t as much a culture shift to get from
              Message 6 of 13 , Feb 15, 2006
              • 0 Attachment
                --- In agile-usability@yahoogroups.com, "Jared M. Spool" <jspool@...>
                wrote:
                > Yet, the FUBU mentality really ferments a mindset that makes it hard to
                > step back and say, "Maybe we don't really know what makes sense here
                for
                > the real users."
                >
                >
                > Both the DEC and Symbolics folks I worked with created some really
                > innovative stuff. Stuff that was way ahead of what we still have today.
                > But, it was packaged in such a complex environment that it was
                pretty much
                > doomed to fail from the start.
                >
                > I don't think you can transition from FUBU to a FOBU environment
                without a
                > major culture shift. (And probably an execution or two.)

                Yes, I agree with this.

                One thing I've been contemplating is that maybe it isn't as much a
                culture shift to get from FUBU to FOBU (are we really using these
                acronyms?) as much as the presence or absence of "emotional intelligence".

                In other words, in my experience, it takes a certain kind of person to
                really empathize and therefore effective role-play what "The Users"
                are like and what they need.

                You can *intend* to empathize all day long and still not get there. I
                think it's part training, but also part brain-wiring.

                There are developers who understand "users", not just because of FUBU,
                but because they have that empathy wiring. Move them to another
                field, and they'll figure out how to ask the right questions to
                understand those users. The majority I've worked with, unfortunately,
                aren't that way.

                Bill Clinton might have been an excellent UX professional (I feel your
                pain).

                --Dave

                Dave Churchville
                http://www.extremeplanner.com
              • Desilets, Alain
                There are developers who understand users , not just because of FUBU, but because they have that empathy wiring. Move them to another field, and they ll
                Message 7 of 13 , Feb 16, 2006
                • 0 Attachment
                  There are developers who understand "users", not just because of FUBU,
                  but because they have that empathy wiring. Move them to another field,
                  and they'll figure out how to ask the right questions to understand
                  those users. The majority I've worked with, unfortunately, aren't that
                  way.

                  -- Alain:
                  I think the reason why many developpers behave AS THOUGH they are
                  incapable of empathising with the user, is that they are NEVER EXPOSED
                  to them, and are given no information about them. How can you empathise
                  with someone you have never met and of whom you know nothing?

                  If I ask you to "empathise with Joe", will you be able to do it? Of
                  course not! How about if I tell you that he just lost his wife in a car
                  accident? It probably helps right? How about if I tell you that he has
                  five kids under 10 to care for single handedly? I'm sure you feel the
                  pain by now. How about if you meet Joe Bloe in person and hear his story
                  directly from him? At that point, you will probably feel an urge to help
                  him if you can.

                  Most of the programmers I meet that work in an agile environment where
                  they are directly exposed to the end user and the customer are pretty
                  good at empathising with them and understanding user needs. So I think
                  the reason why so many programmers behave differently is due to the
                  environment they work in, not to an inherent inability to empathise.
                  ----
                • Dave Churchville
                  ... Well, I agree that the environment is a necessary condition, but I don t think it s sufficient. Again, this may be limited to my own experience, but having
                  Message 8 of 13 , Feb 16, 2006
                  • 0 Attachment
                    --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                    <alain.desilets@...> wrote:
                    > Most of the programmers I meet that work in an agile environment where
                    > they are directly exposed to the end user and the customer are pretty
                    > good at empathising with them and understanding user needs. So I think
                    > the reason why so many programmers behave differently is due to the
                    > environment they work in, not to an inherent inability to empathise.


                    Well, I agree that the environment is a necessary condition, but I
                    don't think it's sufficient. Again, this may be limited to my own
                    experience, but having worked with many different types of developers
                    in varied environments over 15 years or so, my perspective is that
                    there's more to it than just default empathy. (Note: I am a developer
                    myself, and notwithstanding some bright moments, I have suffered from
                    this problem as well).

                    In fact, what has happened is that many people *believe* they are
                    empathizing, and they certainly do want to help the user - it's that
                    for some reason they are unable to truly see the goals of the user.

                    In other words, to take your example of Joe who has 10 kids, I might
                    empathize with that, and say, I really want to help Joe, let's build
                    an automatic diaper changer.

                    In reality, Joe's main goal is to have some alone time once in a
                    while, so he'd really like a babysitter.

                    So empathy and understanding may not be equivalent here. I don't know
                    how else to explain this, it's just my experience. Sounds like you've
                    had more luck.

                    --Dave

                    Dave Churchville
                    http://www.extremeplanner.com
                  • Desilets, Alain
                    In fact, what has happened is that many people *believe* they are empathizing, and they certainly do want to help the user - it s that for some reason they are
                    Message 9 of 13 , Feb 16, 2006
                    • 0 Attachment
                      In fact, what has happened is that many people *believe* they are
                      empathizing, and they certainly do want to help the user - it's that for
                      some reason they are unable to truly see the goals of the user.

                      In other words, to take your example of Joe who has 10 kids, I might
                      empathize with that, and say, I really want to help Joe, let's build an
                      automatic diaper changer.

                      -- Alain:
                      In an XP Environment, Joe would tell the developper that what he really
                      needs someone to babysit his kids while he takes some time off. So the
                      developper would never end up building an automatic diaper changer. He
                      might think that building an automatic diaper changer would be more fun
                      than babysitting, but by agreeing to work on an XP team he has accepted
                      the customer's bill of rights that says the customer gets to decide
                      exactly what gets built.

                      Maybe what you mean by "ability to empathise" you really mean "ability
                      to see the forest for the tree and interpret what the customer/user says
                      and come up with innovative designs that address their core needs". If
                      so, I would agree that this is a skill that UI types of people are more
                      likely to possess. But even there, that stereotype is not as strong as
                      you might think. I know LOTS of UI types who CAN'T see the forest for
                      the trees and who get bogged down in details like wording of dialogs,
                      colors, positioning etc... (and those guys aren't all "developper turned
                      UI-guy by accident" types). And I also know LOTS of developpers
                      (especially in the agile world) who are very good at seeing the forest
                      and coming up with the
                      SimplestThingThatCouldPossiblyAddressTheUser'sCoreNeeds.
                      ----
                    • Dave Churchville
                      ... Yes, that s exactly what I mean :-) But I wasn t making a statement that UI people are better at this than developers as a rule. Or that developers are
                      Message 10 of 13 , Feb 16, 2006
                      • 0 Attachment
                        --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                        <alain.desilets@...> wrote:
                        > Maybe what you mean by "ability to empathise" you really mean "ability
                        > to see the forest for the tree and interpret what the customer/user says
                        > and come up with innovative designs that address their core needs". If
                        > so, I would agree that this is a skill that UI types of people are more
                        > likely to possess.

                        Yes, that's exactly what I mean :-)

                        But I wasn't making a statement that "UI people" are better at this
                        than developers as a rule. Or that developers are universally bad at it.

                        Rather, I think this is a relatively rare skill, in any discipline.

                        Granted, an agile team is less likely to *overbuild* something
                        suboptimal, and with frequent iteration and feedback may come up with
                        a good solution over time. Again, I'm mainly talking about user
                        interfaces and interactions.

                        For example, as a long time agile practitioner, I think I've gotten
                        pretty good at "forest vision", and been able to come up with simple,
                        effective designs to solve core user needs.

                        But I'm still amazed when I run across someone who has a gift for this
                        kind of thinking, and can come up with a variety of alternatives, each
                        of which is easily as good as mine at solving the problem.

                        Again, I just think that's rare. Doesn't mean my solutions aren't
                        "good enough", but there's another level possible.

                        --Dave

                        Dave Churchville
                        http://www.extremeplanner.com
                      • Desilets, Alain
                        But I wasn t making a statement that UI people are better at this than developers as a rule. Or that developers are universally bad at it. -- Alain: No
                        Message 11 of 13 , Feb 16, 2006
                        • 0 Attachment
                          But I wasn't making a statement that "UI people" are better at this than
                          developers as a rule. Or that developers are universally bad at it.

                          -- Alain:
                          No worries. My buttons are pretty easy to push when it comes to
                          stereotypes about developpers.
                          ----
                        • Jon Kern
                          ... able to ... I am not so sure... (except for the might part) I would surmise the reason FUBU is easy for technical products is because of the intense
                          Message 12 of 13 , Feb 17, 2006
                          • 0 Attachment
                            > I think if you have written good FUBU software, you might be
                            able to
                            >write decent FOBU (For Others, By Us) software also, because you are

                            I am not so sure... (except for the "might" part)

                            I would surmise the reason FUBU is easy for technical products is because of the intense familiarity with
                                - the domain
                                - the user tasks
                                - the end user needs

                            Having worked with the brilliant TogetherSoft development team, the tool was FUBU in the early days and very well done.

                            As the feature list expanded to strange things like EJBs, the usability began to wane. The developers read the J2EE specs and technically did things correctly. But, since they had no idea what a J2EE developer needed -- though they expected they knew what was needed, this part of the tool fell short.
                            -- jon
                            
                            


                            Desilets, Alain said the following on 2/15/2006 3:54 PM:
                            So, what's my point?  I have none - at least no big point.  Just
                            these observations: developers often design good software for
                            developers: FUBU.  Other often design pretty good software for their
                            own use: FUBU.  Doing so can lead one to the false sense of belief
                            that design is easy - and you can do it for anyone, or anyone else
                            can do it for themselves: self-centered design.

                            comments invited, and thanks for listening/reading. 
                            [I really should get a blog and stop using this list as one.  ;-) ]

                            -- Alain:
                            I think if you have written good FUBU software, you might be able to
                            write decent FOBU (For Others, By Us) software also, because you are
                            already in the right frame of mind. In other words, you paid a lot of
                            attention to yourself as an end user, so you will probably pay
                            atttention to those Others as end users. In my view, once your whole
                            team has assimilated the "pay attention to the end user" mentra, you are
                            80% of the way there.

                            Of course, a pitfall is that the developpers might not realise that
                            these Other users are not like them... That's the "you are not the user
                            (although you may be like them in many respects)" mentra. But I would
                            think that this second mentra comes easily once you have assimilated the
                            first one.
                            ----
                          • Jon Kern
                            ...and I thought I did a good job... http://blogs.compuware.com/cs/blogs/jkern/archive/2006/02/23/mastering_a_skill.aspx -- jon
                            Message 13 of 13 , Feb 24, 2006
                            • 0 Attachment
                            Your message has been successfully submitted and would be delivered to recipients shortly.