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

Re: [agile-usability] Patterns and Design

Expand Messages
  • Ash Donaldson
    Tim, There have been many attempts at adapting patterns to UI and even usability. These are great to a limited extent, but will never replace field studies and
    Message 1 of 7 , Sep 22, 2005
    • 0 Attachment
      Re: [agile-usability] Patterns and Design Tim,

      There have been many attempts at adapting patterns to UI and even usability.  These are great to a limited extent, but will never replace field studies and typical HCI/Human Factors requirements gathering exercises for successful UCD.  

      To design something properly, UCD practitioners first need to understand the context of use, then the motivations, goals and tasks required by the users.  The resulting designs are then evaluated against the requirements with iterative user testing and stakeholder sessions.

      The actual framework for  the “human-centred design of interactive systems”, as specified in ISO 13407:1999 is:
      1. Understand and specify the context of use;
      2. Specify the user and organisational requirements;
      3. Produce design solutions;
      4. Evaluate designs against requirements; and iterate until
      5. System satisfies specified user and organisational requirements.

      This is great for encompassing in <insert agile methodology>, but some research first has to be done up-front and in context if the system is going to really be “user-centred”.

      Cheers,

      Ash Donaldson
      OZCHI 2005 Conference Chair
      chair@...

      OZCHI 2005
      Citizens Online: Considerations for today & the future
      www.ozchi.org

      On 23/9/05 11:06 AM, "Tim Wright" <sambo.shacklock@...> wrote:


      Hi,

      I was thinking this morning (it doesn't happen often:). It occurred to me that one of the reasons agile developers can forgo big design upfront is because we know about OO design patterns: patterns that give us hints how to structure our programs for extendability, flexibility, and reusability.

      Has anyone considered using user-interface patterns to help do less user-interface requirements gathering and design? An agile UI designer could piece together the user interface from the bottom up using patterns to structure the design.

      UI patterns are at: http://time-tripper.com/uipatterns/

      Hmm. If no-one is doing that, then I guess I just found myself a research area!






    • Ron Jeffries
      ... I thought that a rather important reason is that we know how to design all the time, not just at the beginning. So we can do just as much (or more) design,
      Message 2 of 7 , Sep 22, 2005
      • 0 Attachment
        On Thursday, September 22, 2005, at 9:06:33 PM, Tim Wright wrote:

        > I was thinking this morning (it doesn't happen often:). It occurred to me
        > that one of the reasons agile developers can forgo big design upfront is
        > because we know about OO design patterns: patterns that give us hints how to
        > structure our programs for extendability, flexibility, and reusability.

        I thought that a rather important reason is that we know how to
        design all the time, not just at the beginning. So we can do just as
        much (or more) design, while reducing the amount at the beginning.

        Ron Jeffries
        www.XProgramming.com
        Do we learn more through cynicism, or through some other mental posture?
      • Dharmendar
        We never spend a lot of time at the beginning stage, evaluating, analysing whether a design provides 100% solution or not. Usually we start with a simple
        Message 3 of 7 , Sep 22, 2005
        • 0 Attachment
          We never spend a lot of time at the beginning stage,
          evaluating, analysing whether a design provides 100%
          solution or not. Usually we start with a simple design
          that answers most of the requirements. During the
          development phase, the issues are fixed and other
          tweaks are implemented on the fly. So, after 2 or 3
          minor iterations, the design reaches about 80% to 90%
          perfection. This works well for us.

          Very rarely, we end up re-designing the whole!

          -Rajesh



          --- Ron Jeffries <ronjeffries@...> wrote:

          > On Thursday, September 22, 2005, at 9:06:33 PM, Tim
          > Wright wrote:
          >
          > > I was thinking this morning (it doesn't happen
          > often:). It occurred to me
          > > that one of the reasons agile developers can forgo
          > big design upfront is
          > > because we know about OO design patterns: patterns
          > that give us hints how to
          > > structure our programs for extendability,
          > flexibility, and reusability.
          >
          > I thought that a rather important reason is that we
          > know how to
          > design all the time, not just at the beginning. So
          > we can do just as
          > much (or more) design, while reducing the amount at
          > the beginning.
          >
          > Ron Jeffries
          > www.XProgramming.com
          > Do we learn more through cynicism, or through some
          > other mental posture?
          >
          >
          >
          > ------------------------ Yahoo! Groups Sponsor
          > --------------------~-->
          > Fair play? Video games influencing politics. Click
          > and talk back!
          >
          http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/dpFolB/TM
          >
          --------------------------------------------------------------------~->
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          > agile-usability-unsubscribe@yahoogroups.com
          >
          >
          >
          >
          >




          __________________________________
          Yahoo! Mail - PC Magazine Editors' Choice 2005
          http://mail.yahoo.com
        • Ash Donaldson
          Rajesh, How do you evaluate ³80% to 90% perfection²? Is this qualified against the specified requirements, UAT metrics, or based on some other metrics? I
          Message 4 of 7 , Sep 23, 2005
          • 0 Attachment
            Re: [agile-usability] Patterns and Design Rajesh,

            How do you evaluate “80% to 90% perfection”?  Is this qualified against the specified requirements, UAT metrics, or based on some other metrics?  

            I only ask because I’ve come across so many systems that make such claims, and rightly so (under the circumstances, and subject to the types of metrics used), but when implemented are:
            Functionally excellent, but frustrating to use and so are avoided where possible;
            Not used, even though they scored brilliantly in UAT (typical of self-report (UAT measures) – people are not capable of accurately articulating behaviours i.e. How they currently use things or what they will use in the future and/or why/why not); or
            Extremely usable, but realistically useless (common for systems designed and tested without taking into account context of use, motivations, subsequent goals and resulting tasks).

            There are plenty of things that can be measured in a quantitative sense, but without qualitative AND contextual measurements, these metrics can prove to be ineffective in determining the true success of a system.

            Best regards,

            Ash Donaldson
            OZCHI 2005 Conference Chair
            chair@...

            OZCHI 2005
            Citizens Online: Considerations for today & the future
            www.ozchi.org

            On 23/9/05 4:18 PM, "Dharmendar" <dharma_in@...> wrote:


            We never spend a lot of time at the beginning stage,
            evaluating, analysing whether a design provides 100%
            solution or not. Usually we start with a simple design
            that answers most of the requirements. During the
            development phase, the issues are fixed and other
            tweaks are implemented on the fly. So, after 2 or 3
            minor iterations, the design reaches about 80% to 90%
            perfection. This works well for us.

            Very rarely, we end up re-designing the whole!

            -Rajesh



            --- Ron Jeffries <ronjeffries@...> wrote:

            > On Thursday, September 22, 2005, at 9:06:33 PM, Tim
            > Wright wrote:
            >
            > > I was thinking this morning (it doesn't happen
            > often:). It occurred to me
            > > that one of the reasons agile developers can forgo
            > big design upfront is
            > > because we know about OO design patterns: patterns
            > that give us hints how to
            > > structure our programs for extendability,
            > flexibility, and reusability.
            >
            > I thought that a rather important reason is that we
            > know how to
            > design all the time, not just at the beginning. So
            > we can do just as
            > much (or more) design, while reducing the amount at
            > the beginning.
            >
            > Ron Jeffries
            > www.XProgramming.com
            > Do we learn more through cynicism, or through some
            > other mental posture?
            >
            >
            >
            > ------------------------ Yahoo! Groups Sponsor
            > --------------------~-->
            > Fair play? Video games influencing politics. Click
            > and talk back!
            >
            http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/dpFolB/TM
            >
            --------------------------------------------------------------------~->
            >
            >
            >  
            > Yahoo! Groups Links
            >
            >
            >     agile-usability-unsubscribe@yahoogroups.com
            >
            >  
            >
            >
            >



                        
            __________________________________
            Yahoo! Mail - PC Magazine Editors' Choice 2005
            http://mail.yahoo.com




             
             

            YAHOO! GROUPS LINKS


             







          • Ron Jeffries
            ... I took the 80 to 90 to be metaphoric for good enough . And I m OK with that. People don t have any trouble deciding whether to buy the lobster or the
            Message 5 of 7 , Sep 23, 2005
            • 0 Attachment
              On Friday, September 23, 2005, at 9:39:28 AM, Ash Donaldson wrote:

              > How do you evaluate ³80% to 90% perfection²? Is this qualified against the
              > specified requirements, UAT metrics, or based on some other metrics?

              I took the 80 to 90 to be metaphoric for "good enough". And I'm OK
              with that. People don't have any trouble deciding whether to buy the
              lobster or the scrod for dinner, deciding whether to spend the extra
              $15,000 for that hot sports car, deciding whether to get their suit
              off the rack, or custom made.

              And people don't have much trouble deciding whether the next feature
              is worth the cost, or if the system is "good enough". The issues
              come along when we can't, or won't, tell them how much things will
              cost.

              Now below, you're describing some bad systems, and systems that
              should have been better. I'm not sure that the focus should be on
              defining the 80-90 for those: I think I'd want more concrete "tests"
              of the matters you mention:

              > I only ask because I¹ve come across so many systems that make such claims,
              > and rightly so (under the circumstances, and subject to the types of metrics
              > used), but when implemented are:

              > Functionally excellent, but frustrating to use and so are avoided where
              > possible;

              It could happen. I suspect that when it does happen, the technical
              people were not in touch with, or not listening to, the users.

              > Not used, even though they scored brilliantly in UAT (typical of self-report
              > (UAT measures) ­ people are not capable of accurately articulating
              > behaviours i.e. How they currently use things or what they will use in the
              > future and/or why/why not); or

              UAT = User Acceptance Testing? How could a system be frustrating to
              use and worthy of avoiding, and get good UAT scores? I don't
              understand that.

              And it is very much counter to my experience that people can't
              accurately articulate how they use things. Not to mention that we
              can just watch them. I think the more common issue is that no one
              asked.

              Thinking about it, I have NEVER encountered a system where people
              could honestly say "We gave it to real users and they said they
              liked it but they really don't like it." I've encountered systems
              where technical people -- including allegedly very capable human
              factors people -- designed the system and actual humans didn't like
              it.

              > Extremely usable, but realistically useless (common for systems
              > designed and tested without taking into account context of use,
              > motivations, subsequent goals and resulting tasks).

              Yes ... again, seems to me like no one asked ...

              > There are plenty of things that can be measured in a quantitative sense, but
              > without qualitative AND contextual measurements, these metrics can prove to
              > be ineffective in determining the true success of a system.

              I don't know what those things would be, but I'm probably even less
              interested in measuring them than you are. I'm interested in putting
              real users together with the people who build their software, and
              showing them software every week. They manage to figure a lot out.

              Ron Jeffries
              www.XProgramming.com
              To follow the path:
              Look to the master; Follow the master; Walk with the master;
              See through the master; Become the master. -- Modern Zen Poem
            • Ash Donaldson
              Ron, You bring up some excellent points and perhaps I¹m going a bit too deep, too early for this stage of UCD discussion. Nonetheless, I¹ll add my rationale
              Message 6 of 7 , Sep 23, 2005
              • 0 Attachment
                Re: [agile-usability] Patterns and Design Ron,

                You bring up some excellent points and perhaps I’m going a bit too deep, too early for this stage of UCD discussion.  Nonetheless, I’ll add my rationale at a high level for those that are interested.

                On 23/9/05 11:57 PM, "Ron Jeffries" <ronjeffries@...> wrote:
                >
                I took the 80 to 90 to be metaphoric for "good enough". And I'm OK
                > with that. People don't have any trouble deciding whether to buy the
                > lobster or the scrod for dinner, deciding whether to spend the extra
                > $15,000 for that hot sports car, deciding whether to get their suit
                > off the rack, or custom made.
                Great!  But how do we determine what’s “good enough”?  Is what I think good enough the same as what my competitor thinks is good enough?  What you bring up is looking at motivations (your examples are mostly to do with certain vanities of social status), but how do you design that sports car that someone will pay the extra $15,000 for?  Could it be any sports car?  No.  Many fail in the market.  Some seemingly bad ones do really well.  Why?  These are the some of the things we are interested in, and aren’t as simple to determine as some may think.

                Some good starting points in investigating this area are:
                Zaltman (2003), “How Customers Think”;
                Trappl et al (2003), “Emotions in Humans and Artifacts”;
                Norman (2004), “Emotional Design”;   and
                Vincente (2004), “The Human Factor”.

                >> Functionally excellent, but frustrating to use and so are avoided where
                >> possible;
                >
                >It could happen. I suspect that when it does happen, the technical
                >people were not in touch with, or not listening to, the users.
                That’s one case, but
                it also can happen as a result of listening to users.  If we don’t understand user needs (i.e. their motivations, goals and tasks in a specified context of use), all we can rely on is what they ask for – and that can prove to be very misleading.  

                If you ask people what they want – well, they want everything.  Give them everything and they get confused – and the more choice they have, weirdly enough, the more dissatisfied people become with what they choose and the task at hand (see Schwartz (2005), “The Paradox of Choice”).  The real difference between user-centred design and simply filling out functionality wish lists is considered research that uncovers actual user needs.  

                Also, people often don’t actually know what they want.  An old anecdote from marketing goes along these lines:
                Sony had a focus group to determine the direction of their new ‘boom boxes’.  They used several groups of 8 participants, with skilled facilitators to determine the new look of these machines.  The choice was between a plain black version and a yellow and red version.  Overwhelmingly, people loved the yellow and red version, saying that it was ‘more exciting’, ‘trendy’ and ‘cutting edge’.  At the end of the session, as compensation for attending the session, they were all given the opportunity to choose either of the boom boxes to take home.  They all chose the black one.

                Moral of the story: What people say and what people do are often two different things.

                > UAT = User Acceptance Testing? How could a system be frustrating to
                > use and worthy of avoiding, and get good UAT scores? I don't
                > understand that.
                It all depends on the style of UAT I suppose.  If artificially tested against the user requirements spec (common in both UAT and ‘discount usability testing’) – then it’s only as valid as the requirements spec (which is often not-so-good).  If beta tested, then you can only go on the problems that people perceive (and thus report) they are having or the subjective feedback they provide.  This can be misleading as the actual problem may be with an earlier part in a flow, or a different aspect of the interface, but that problem then becomes insurmountable or intolerable, and so only noticed at another point further down the track.  

                > And it is very much counter to my experience that people can't
                > accurately articulate how they use things. Not to mention that we
                > can just watch them. I think the more common issue is that no one
                > asked.
                Unfortunately, people often can’t *accurately* articulate how they use, or why they do things (in short, they can’t report their actual their behaviour).  Everyone can and does report their behaviour, but more often than not it is inaccurate or even completely incorrect.  Why?  We have no direct access to higher order thoughts, and memory doesn’t work like a filing system.  If we don’t know why we did something or our brain can’t recall it, it quickly fills the gap (without us realising) and provides what seems to be a perfectly reasonable rationale.  There’s been plenty of research on this along similar lines to the following two experiments:
                “Maier had people try to solve the problem of tying together two strings that hung down from the ceiling too far apart to be grabbed at the same time (Maier, N.R.F. "Reasoning in humans: II. The solution of a problem and its appearance in consciousness." Journal of Comparative Psychology, 12 (1931), pp. 181-194). One solution is to tie some kind of weight to one of the strings, set it swinging, grab the other string, and then wait for the swinging string to come close enough to reach. It's a hard problem, and few people come up with this or any other solution. Sometimes, when people were working, Maier would "accidentally" brush against one of the strings and set it in motion. The data showed that when he did this people were much more likely to find the solution. The point of interest for us is, what did these people say when Maier asked them how they solved the problem? They did NOT say, "When you brushed against the string that gave me the idea of making the string swing and solving the problem that way," even though Maier knows that's what really happened. So they could not and did not tell him what feature of the situation really helped them solve the problem.

                Nisbett and Wilson set up a market survey table outside a big shopping center and asked people to say which of three pairs of panty hose they preferred, and why (Nisbett, R.E., and Wilson, T.D. "Telling more than we can know: Verbal reports on mental processes." Psychological Review, 84 (1977), pp. 231-259). Most people picked the rightmost pair of the three, giving the kinds of reasons you'd expect: "I think this pair is sheerer" or "I think this pair is better made." The trick is that the three pairs of panty hose were IDENTICAL. Nisbett and Wilson knew that given a choice among three closely- matched alternatives there is a bias to pick the last one, and that that bias was the real basis for people's choices. But (of course) nobody SAID that's why they chose the pair they chose. It's not just that people couldn't report their real reasons: when asked they made up reasons that seemed plausible but are wrong.”
                 - Lewis & Reiman (1994)

                What you say about watching them is a better way, and watching them use the system in their usual context much better still.  And yes, in many organisations, the biggest problem is that users simply aren’t involved.  

                > I don't know what those things would be, but I'm probably even less
                > interested in measuring them than you are. I'm interested in putting
                > real users together with the people who build their software, and
                > showing them software every week. They manage to figure a lot out.
                As I said, perhaps I’m going a little deep for this stage of the discussion.  My points are more for those interested in delving a bit deeper, or designing complex or mission critical systems.  However, some people do measure these things and come to certain percentages or metrics (such as 80% to 90% perfect) with some form of rationale or methodology.  This in turn, makes the metrics seem concrete, so others may be misled.  

                What you say is very true.  The mere act of involving users is a great step forward in software design and it’s encouraging to see so many people interested in it.

                Best regards,

                Ash Donaldson
                OZCHI 2005 Conference Chair
                chair@...

                OZCHI 2005
                Citizens Online: Considerations for today & the future
                www.ozchi.org


              Your message has been successfully submitted and would be delivered to recipients shortly.