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

Office 12 prototypes

Expand Messages
  • Jade Ohlhauser
    http://blogs.msdn.com/jensenh/archive/2006/01/06/510069.aspx Jensen Harris writes an interesting blog on UI design in Office 12 and his latest post mentioned a
    Message 1 of 19 , Jan 6, 2006
    • 0 Attachment
       
      Jensen Harris writes an interesting blog on UI design in Office 12 and his latest post mentioned a familiar problem:
       
      "One of the conundrums of an iterative design process is how to get feedback early enough to impact the development process."
      Anyway if you don't already read that blog I recommend you check it out
       
      Jade Ohlhauser
      Product Manager
      RPM Software                                 
      www.rpmsoftware.com 403-265-6727 x704
       
    • Ron Jeffries
      ... Is he suggesting that a non-iterative process provides feedback sooner? That seems less than obvious ... Ron Jeffries www.XProgramming.com Ron Jeffries,
      Message 2 of 19 , Jan 6, 2006
      • 0 Attachment
        On Friday, January 6, 2006, at 11:04:27 AM, Jade Ohlhauser wrote:

        > Jensen Harris writes an interesting blog on UI design in Office 12 and
        > his latest post mentioned a familiar problem:
        >

        > "One of the conundrums of an iterative design process is how to
        > get feedback early enough to impact the development process."

        Is he suggesting that a non-iterative process provides feedback
        sooner? That seems less than obvious ...

        Ron Jeffries
        www.XProgramming.com
        Ron Jeffries, speaking for Boskone ... Out.
      • Larry Constantine
        Jade Ohlhauser quoted Jensen Harris s blog: One of the conundrums of an iterative design process is how to get feedback early enough to impact the development
        Message 3 of 19 , Jan 6, 2006
        • 0 Attachment
          Jade Ohlhauser quoted Jensen Harris's blog: "One of the conundrums of an
          iterative design process is how to get feedback early enough to impact the
          development process."

          Alas, it's all too common to think of feedback from real users or surrogates
          interacting with a prototype, paper or otherwise, as the only valid input
          for design iteration and refinement.

          Over the years, I have found structured inspections and reviews, guided by
          sound principles and conducted in a disciplined manner, to provide abundant,
          accurate, and useful feedback early in the design process. Even simpler
          techniques with yet faster turn-around can also work. Sometimes it is enough
          to set aside a design and return later to critically examine it with an eye
          to finding everything wrong with it. Sometimes it is enough to pass it
          around among trusted and able design colleagues for feedback.

          As more and more leading thinkers in usability are beginning to note,
          user-centered design has become hostage to the hegemony of users, singly and
          collectively, coupled with an often excessive reliance on user feedback to
          the exclusion of other refinement techniques. Just as you can find code bugs
          without running the code (and it is often cheaper if you find them before
          you do), you can find usability defects without putting designs or software
          in front of users.

          That is not to say user reviews and user testing are not useful
          techniques--I use them both--but there are other ways to assess and validate
          UI designs that can provide early feedback.

          --Larry Constantine, IDSA
        • Desilets, Alain
          Larry Constantine wrote: -- Over the years, I have found structured inspections and reviews, guided by sound principles and conducted in a disciplined manner,
          Message 4 of 19 , Jan 6, 2006
          • 0 Attachment
            Larry Constantine wrote:

            --
            Over the years, I have found structured inspections and reviews, guided
            by sound principles and conducted in a disciplined manner, to provide
            abundant, accurate, and useful feedback early in the design process.
            --

            And he added:

            --
            Just as you can find code bugs without running the code (and it is often
            cheaper if you find them before you do), you can find usability defects
            without putting designs or software in front of users.
            --

            -- Alain comments:
            As a developper, I can't really speak confidently (at least not when
            adressing Larry ;-)) about the relative benefits of inspecting designs
            for usability flaws, versus getting user feedback from paper prototyping
            or from an actual running prototype (i.e. the first point).

            But one thing I can say from experience, and which I will claim as being
            blatantly true, is that the cheapest and most effective way of finding
            bugs is to run the code as early as possible (i.e. Larry's second point)
            after it has been written.

            More precisely, I am talking about Test-First Development or Test-Driven
            Development (TDD) as it is being called nowadays. In other words, before
            you write or change a single line of code, you write an automated test
            (or modify an existing one) that will certify that you achieved what you
            wanted with that change. Then you add that test to your test suite. You
            run the whole suite of tests several times per hour, and fix problems as
            soon as they are identified.

            With this approach, I catch several bugs per hour, every single working
            hour of my day. The same goes for all developpers on my team. Many of
            those are non-trivial bugs that would otherwise go unnoticed for days
            (by which time they have become much harder to debug because you don't
            know what change among the ones you did in recent days, introduced the
            bug).

            I have often heard people quote studies which "showed" that code
            inspections are better at finding bugs than testing. But that is
            COMPLETELY contrary to my own experience. One of these days I will
            actually read those studies to figure out what's going on here. I
            suspect those studies compared apples with oranges, i.e. they compared
            early code inspections to late code testing. But if you do exhaustive
            early code testing TDD style, I can't see (and my experience confirms
            that) how inspection could be more efficient. After all, the frequency
            at which code inspections can be done is in the order of once a week at
            most, whereas the whole suite of automated unit tests can be run several
            times per hour times the number of developpers on the team. Moreover,
            code inspections can only only catch bugs that have happened in the
            past, whereas automated unit tests will also catch bugs that happen in
            the future.
            ----
          • Larry Constantine
            ... You are so right, and my analogy fails once TDD is introduced. However, as there is no analog to TDD in UI design, nor can user tests be turned into
            Message 5 of 19 , Jan 6, 2006
            • 0 Attachment
              Alain wrote:

              > As a developper, I can't really speak confidently (at least not when
              > adressing Larry ;-)) about the relative benefits of inspecting designs
              > for usability flaws, versus getting user feedback from paper prototyping
              > or from an actual running prototype (i.e. the first point).
              >
              > But one thing I can say from experience, and which I will claim as being
              > blatantly true, is that the cheapest and most effective way of finding
              > bugs is to run the code as early as possible (i.e. Larry's second point)
              > after it has been written.
              >
              > More precisely, I am talking about Test-First Development or Test-Driven
              > Development (TDD) as it is being called nowadays.

              You are so right, and my analogy fails once TDD is introduced. However, as
              there is no analog to TDD in UI design, nor can user tests be turned into
              automated regression suites, my point stands.

              As to the research on relative cost effectiveness of inspections over
              testing, I have read it, and taken collectively it is both pretty sound and
              consistent. (Inspections do not have to be week-delayed structured
              walkthroughs; pair programming is in large part a continuous inspection
              technique.) That said, the differences diminish as the unit size goes down
              and the turn-around on testing is cut, particularly within regression
              testing. Here too, the analogy breaks down because UI design in very small
              pieces with "user testing" in very rapid iterations is generally
              impractical, even with paper prototypes.

              That'll teach me to use a programming analogy! :-)

              --Larry Constantine, IDSA
            • Dave Churchville
              ... Yeah, I got the same impression, but reading the entry brought up something I ve struggled with as well. How do you get rapid feedback on aspects of a user
              Message 6 of 19 , Jan 6, 2006
              • 0 Attachment
                --- In agile-usability@yahoogroups.com, Ron Jeffries <ronjeffries@X...> wrote:

                > > "One of the conundrums of an iterative design process is how to
                > > get feedback early enough to impact the development process."
                >
                > Is he suggesting that a non-iterative process provides feedback
                > sooner? That seems less than obvious ...

                Yeah, I got the same impression, but reading the entry brought up something I've struggled with as well.

                How do you get rapid feedback on aspects of a user interface that are non-trivial to build?

                For a classic 2 week iteration on an agile project, does it make sense to just build the interface, then get feedback, and maybe redo the interface in an entirely different way? Or trust that you understood the customer goals well enough that any changes will be minor?

                Interaction design seems to point towards the latter - understanding your user goals and intentions well enough up front so that designs are likely to be "close enough" that you could actually build something with confidence.

                I've seen many Agile proponents suggest the former (just build it and let the customer make the decision of whether to improve the UI at some cost, or deal with a working but suboptimal implementation).

                In my opinion, you're better served doing something in between - get a good sense of the goals (maybe not at the level of rigor that a pure Interaction Design enthusiast might want), and build an initial UI that meets these goals, then get a customer review of what you've got so far.

                What do you guys think?

                --Dave

                -----------------------------------
                Dave Churchville
                ExtremePlanner Software
                http://www.extremeplanner.com
                Agile Project Management for Distributed Teams
              • Desilets, Alain
                In my opinion, you re better served doing something in between - get a good sense of the goals (maybe not at the level of rigor that a pure Interaction Design
                Message 7 of 19 , Jan 6, 2006
                • 0 Attachment
                  In my opinion, you're better served doing something in between - get a
                  good sense of the goals (maybe not at the level of rigor that a pure
                  Interaction Design enthusiast might want), and build an initial UI that
                  meets these goals, then get a customer review of what you've got so far.

                  What do you guys think?

                  -- Alain:
                  That is my opinion too.

                  But it doesn't really answer the "question" because there are still many
                  different points you could position yourself along the continuum, and
                  it's not clear to me where the sweet spot is. In other words, it's easy
                  to agree that you both need to do some upfront design to understand your
                  user's needs, and at the same get user feedback based on a running piece
                  of code as soon as possible. The hard part is agreeing on how much
                  upfront design is enough and how early is early enough for getting
                  feedback on a running prototype.
                  ----
                • Dave Churchville
                  ... Yes, agreed. I guess that s why they pay us the big bucks ;-) Seriously, as with most things, it depends . Some projects are not very sensitive to UI
                  Message 8 of 19 , Jan 6, 2006
                  • 0 Attachment
                    --- In agile-usability@yahoogroups.com, "Desilets, Alain" <alain.desilets@n...> wrote:
                    > -- Alain:
                    > That is my opinion too.
                    >
                    > But it doesn't really answer the "question" because there are still many
                    > different points you could position yourself along the continuum, and
                    > it's not clear to me where the sweet spot is. In other words, it's easy
                    > to agree that you both need to do some upfront design to understand your
                    > user's needs, and at the same get user feedback based on a running piece
                    > of code as soon as possible. The hard part is agreeing on how much
                    > upfront design is enough and how early is early enough for getting
                    > feedback on a running prototype.

                    Yes, agreed. I guess that's why they pay us the big bucks ;-)

                    Seriously, as with most things, "it depends". Some projects are not very sensitive to UI issues, so a minor bit of up front design, and periodic feedback are fine. For others, a lot more care is needed.

                    One example for me is an application I was responsible for that had "expert users" that were used to the current interface so that even minor changes were cause for concern. Consistency was also a problem when adding new features, since the development team wanted to "make it better" than previous approaches. So we needed a lot of user feedback to make sure we weren't improving things beyond the comfort level of the end users.

                    I could make up a rule of thumb, but it would still depend on the individual thumb in question. OK, I'll do it anyway as a straw man:

                    - Spend no more than half the required UI implementation time understanding user goals and preferences. For UI sensitive applications, get feedback at least once during an iteration using screenshots, prototypes, or whiteboard discussions.

                    --Dave

                    -----------------------------------
                    Dave Churchville
                    ExtremePlanner Software
                    http://www.extremeplanner.com
                    Agile Project Management for Distributed Teams
                  • Desiree Sy
                    ... A quick answer to this follows, but first I want to jump down ... You can t design without goals. Why? Because you won t know when your design works
                    Message 9 of 19 , Jan 6, 2006
                    • 0 Attachment
                      At 02:45 PM 1/6/2006, Dave Churchville wrote:
                      >How do you get rapid feedback on aspects of a user interface that are non-trivial to build?
                      >
                      >For a classic 2 week iteration on an agile project, does it make sense to just build the interface, then get feedback, and maybe redo the interface in an entirely different way?

                      A quick answer to this follows, but first I want to jump down
                      to a later part of Dave's post:

                      >In my opinion, you're better served doing something in between - get a good sense of the goals (maybe not at the level of rigor that a pure Interaction Design enthusiast might want), and build an initial UI that meets these goals, then get a customer review of what you've got so far.

                      You can't design without goals. Why? Because you won't know
                      when your design works unless you're designing towards
                      something. And if you don't know when it works, how will you
                      know when to stop?

                      Jumping back to the original question, the way that you get
                      rapid feedback during 2-week iterations on a complex UI is to:

                      - Separate the design iterations from the implementation iterations.
                      That is, design at least one cycle/sprint ahead of the current one.
                      - Chunk the design into smaller, prototypable pieces that address
                      subsets of your design goals.
                      - Iterate on the chunk as rapidly as possible until you hit the
                      goals for that piece.
                      - Move to the next chunk, and repeat. Make sure you test the full
                      re-assembled workflow.
                      - When you've got a verified design that allows a complete workflow
                      to be finished by the user, pass the design to the development
                      team to be moved into the code base.

                      This is an extreme compression of a paper I presented at UPA 2005
                      describing a case study of exactly this problem.

                      It's not easy, but it's possible. Some of the trickiest, most
                      magical parts of the process are to figure out:

                      - How to break the design into pieces (which relates to prioritizing
                      the design goals, and also having a good understanding of how small
                      a piece you break the big design into).
                      - What type of prototype to build -- what you want is to use the lowest
                      possible fidelity that will correctly verify the goals you're
                      checking for the chunk.
                      - As mentioned by Larry, you still cannot prototype everything -- it's
                      simply not efficient. So you have to have a very good understanding
                      of which design goals you can meet without this iteration process,
                      and for which goals it's critical that you get observable behavioural
                      feedback.
                      - Once you have a complete verified design for a big piece of UI, how
                      to break that design into implementable chunks (because of course
                      the implementation still has to be done in 2-week chunks). There's
                      an art in getting those implementation pieces into production code.
                      There's also a certain joy to it, because when our end-users start
                      using the half-done design, they *inevitably* ask for the other half.
                      Then when they get the complete UI in 2 or 4 weeks, they think we're
                      freakin' wizards, and the whole team gets to bask in glory. :)

                      Desirée

                      --
                      Desirée Sy Phone: 416-874-8296
                      Interaction Designer Email: dsy@...
                      Alias Fax: 416-369-6150
                    • Jeff Patton
                      ... To the TDD developers in the crowd this rational should sound pretty familar. Designers - those determining how the software should look and behave in
                      Message 10 of 19 , Jan 8, 2006
                      • 0 Attachment
                        --- In agile-usability@yahoogroups.com, Desiree Sy <dsy@a...> wrote:

                        > You can't design without goals. Why? Because you won't know
                        > when your design works unless you're designing towards
                        > something. And if you don't know when it works, how will you
                        > know when to stop?

                        To the TDD developers in the crowd this rational should sound pretty
                        familar.

                        Designers - those determining how the software should look and behave
                        in response to what a user is trying to accomplish - use user
                        understanding, goals and tasks to drive design. Understanding those
                        goals is the "writing the test first" bit. When a designer proposes
                        a design solution, it's validated against that user, goal, and task
                        understanding. If you don't have user, goal, and task understanding,
                        then you're _not_ designing test first. Developers who use TDD know
                        how queezy that makes them feel. Now you might get some
                        understanding of how queezy UCD people feel when people suggest
                        functional design without any tests - user goal and task
                        understanding - to validate that design.

                        As Larry suggests, you don't need real live users to do this
                        testing. If you have your "tests" in place - user/goal/task
                        understanding, then you can assume the role of the user engaged in a
                        task and inspect on their behalf, and with your own design
                        understanding engaged as well. Again, for the unit testing
                        developers in the audience, this is a bit like mocking the database.
                        Saying you absolutely must have a user to test functionality is like
                        telling a good developer that their code absolutely must talk to the
                        Oracle database to be tested. True, at some point in time you'll
                        need to connect the the expense, slow, constrained resource to test -
                        be it a big database, external service, or lab of hand-selected
                        users. But, in the mean time you can increase test-cycle time
                        by "mocking" the users in a UI inspection. [I'm referring to mock-
                        object style testing here not making fun of the users - which I know
                        no one does. ;-) ]

                        > Jumping back to the original question, the way that you get
                        > rapid feedback during 2-week iterations on a complex UI is to:
                        >
                        > - Separate the design iterations from the implementation iterations.
                        > That is, design at least one cycle/sprint ahead of the current
                        one.
                        > - Chunk the design into smaller, prototypable pieces that address
                        > subsets of your design goals.
                        > - Iterate on the chunk as rapidly as possible until you hit the
                        > goals for that piece.
                        > - Move to the next chunk, and repeat. Make sure you test the full
                        > re-assembled workflow.
                        > - When you've got a verified design that allows a complete workflow
                        > to be finished by the user, pass the design to the development
                        > team to be moved into the code base.

                        The important thing to unerstand about moving from user
                        understanding, goals, and tasks through to a good prospective
                        functional design is that it is /design/ - just like writing code is
                        design. Start with tests, propose solutions, run tests, adjust
                        design or add more, run tests, rinse and repeat.... UCD is very
                        iterative, and very test driven. The protyping is done on paper or
                        sometimes with throw-away spiked code. And, sadly the testing isn't
                        automated - at least until we can come up with some cool robots with
                        artificial intelligence and emotions that can simulate people with
                        goals. [But if you've seen iRobot, you know what goes wrong
                        there....]

                        Not iterating over the design prior to handing it develpers to build
                        seems to me to be a bit negligent. [that's not to say I don't do it
                        myself. But it's also true that not 100% of my code is covered by
                        unit tests either.] I can iterate over a dozen UI choices on paper
                        in a couple hours. It's hard for any developer, including me, in any
                        programming environment to outperform that.

                        Thanks all for your posts on this thread!

                        -Jeff
                      • Larry Constantine
                        Elegantly framed, Jeff. Gaining a clear understanding of your users, their intentions, and tasks *is* the UI design equivalent of TDD. I just never thought of
                        Message 11 of 19 , Jan 8, 2006
                        • 0 Attachment
                          Elegantly framed, Jeff.

                          Gaining a clear understanding of your users, their intentions, and tasks
                          *is* the UI design equivalent of TDD. I just never thought of it that way
                          before. In practice, we usually "test" trial designs against the task cases
                          (essential use cases) to verify that the tasks can be performed with the
                          design and to compare interaction efficiency to the ideal (essential form).

                          --Larry Constantine, IDSA
                        • Dave Churchville
                          ... Actually, that s a good analogy...and another way to frame the question. To summarize, the original question centered around how to effectively get rapid
                          Message 12 of 19 , Jan 8, 2006
                          • 0 Attachment
                            --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@a...> wrote:
                            > > You can't design without goals. Why? Because you won't know
                            > > when your design works unless you're designing towards
                            > > something. And if you don't know when it works, how will you
                            > > know when to stop?
                            >
                            > To the TDD developers in the crowd this rational should sound pretty
                            > familar.

                            Actually, that's a good analogy...and another way to frame the question.

                            To summarize, the original question centered around how to effectively get rapid feedback (iterate) on a non-trivial UI design during a typical agile sprint/iteration of 2 weeks.

                            One of the suggestions was to do the design one iteration in advance of the implementation with designers handing it over to developers.

                            Jeff, yours seems to be to apply a TDD style to UI design (Test Driven Design), where you can determine the goals and scenarios first, then iterate possible UIs internally against those goals before showing it to the real users (which is a relatively slow exercise). I resonate with that approach and it's consistent with what's actually worked for me in the past (since I've never worked with dedicated interface/iteraction designers).

                            Obviously, many developers don't practice TDD as such, and many software teams don't test their UI designs with end users or even internal stakeholders until after a development cycle. Are they wrong?

                            I'd suggest that any approach that produces good results repeatably is probably good enough from a pure business standpoint, although a craftsman might cringe at this. In fact, I'd argue that TDD done right is actually rather difficult, and requires an experienced and skilled practitioner to get a good result. Rather like good UI design.

                            So that kind of suggests that a team is better off with a skillful UI designer that does very little external usability research than with a poor UI designer and substantial research.

                            Maybe that explains why so much software suffers from barely usable interfaces, that only improve after several revisions of real world customer feedback.

                            Can anyone tell me why I might be wrong about this?

                            --Dave

                            -----------------------------------
                            Dave Churchville
                            ExtremePlanner Software
                            http://www.extremeplanner.com
                            Agile Project Management for Distributed Teams
                          • Desiree Sy
                            ... Well, sure -- but that s just getting back to the definition of good results, which is just getting back to how you define your goals. So I feel my
                            Message 13 of 19 , Jan 9, 2006
                            • 0 Attachment
                              At 12:04 AM 1/9/2006, Dave Churchville wrote:
                              > I'd suggest that any approach that produces good results repeatably
                              > is probably good enough from a pure business standpoint, although a
                              > craftsman might cringe at this.

                              Well, sure -- but that's just getting back to the definition of
                              "good results," which is just getting back to how you define
                              your goals. So I feel my original point about the impossibility
                              of designing well without goals still holds.

                              > In fact, I'd argue that TDD done
                              > right is actually rather difficult, and requires an experienced and
                              > skilled practitioner to get a good result. Rather like good UI design.
                              >
                              > So that kind of suggests that a team is better off with a skillful
                              > UI designer that does very little external usability research than
                              > with a poor UI designer and substantial research.

                              I'm not going to argue that a team with someone competent is not
                              better off than one with incompetent staff. That seems self-evident.

                              However, there are two catches:

                              1. Here's a nice piece of dogmatism, but I'll stick it out there,
                              anyway, because I truly believe it: There is no such thing as
                              a skilled UI designer that does very little external usability
                              research.

                              I know that seems to contradict what I said earlier, when I stated
                              that you cannot prototype everything, nor can you test everything
                              with end-users, but actually it doesn't....

                              2. ... because the shortcuts that a very good UX person uses (empirically
                              drawn guidelines, a deep understanding of the domain for which she
                              designs, and even the depth of UI solutions available to her, etc.)
                              are drawn from her experience of having seen hundreds of users
                              testing interfaces. That's the Catch-22: you can't skip the
                              iterative design process until you've built enough knowledge to
                              know when to skip it, which you can't do until you've logged hundreds
                              of hours of iterative design, prototyping, and testing.

                              Even if you're lucky enough to hire a skilled UI designer that
                              built up that knowledge somewhere else, I would be very wary of
                              any UI designer that wouldn't insist on "external usability research"
                              for *some* aspects of UI design.

                              Which is just a long way of saying that a competent User Experience
                              practitioner will do usability investigations because for most
                              (consumer, at least) products, it's something that's required from
                              a "pure business standpoint," as you say. That's not to say that
                              we can't and shouldn't do it faster, and with much less documentation.

                              Desirée
                              Alias
                            • Jared M. Spool
                              ... ... Actually, I don t believe that statement to be true. I have seen, with my own eyes, people who intuitively can design an ideal solution without
                              Message 14 of 19 , Jan 9, 2006
                              • 0 Attachment
                                At 02:39 PM 1/9/2006, Desiree Sy wrote:
                                >There is no such thing as a skilled UI designer that does very little
                                >external usability research.

                                <snip>

                                >...because the shortcuts that a very good UX person uses (empirically
                                >drawn guidelines, a deep understanding of the domain for which she
                                >designs, and even the depth of UI solutions available to her, etc.) are
                                >drawn from her experience of having seen hundreds of users testing interfaces.

                                Actually, I don't believe that statement to be true.

                                I have seen, with my own eyes, people who intuitively can design an ideal
                                solution without having conducted any external research. They approach the
                                problem, think about it for a while, and arrive at a solution that is as
                                good or better than any I could have arrived at with all the data I'd
                                collected. (In one case, one such designer arrived at a solution that
                                encapsulated 2 years of hard research -- about 70 user interviews and 50
                                field visits -- with 'a few hours of thinking about it on his deck.' I was
                                stunned at how he hit the nail on the head so accurately.)

                                There are those who walk among us who can do this. But not the majority of
                                us. Desiree is right that most skilled UI designers need to have external
                                research to guide their knowledge and decisions. *Most*, but not *all*.

                                I wish I had the talent to create designs without the external research,
                                but alas, I'm not nearly that good. Hell, I'm not even that good at
                                creating designs when I *do* have the research. I leave that to the
                                professionals...

                                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
                              • Larry Constantine
                                ... I had intended to jump in with this point, but Jared beat me to it. I agree about the special few gifted intuitive (nonempirical?) designers. I have had
                                Message 15 of 19 , Jan 10, 2006
                                • 0 Attachment
                                  Jared wrote:

                                  > I have seen, with my own eyes, people who intuitively can design an ideal
                                  > solution without having conducted any external research....
                                  > There are those who walk among us who can do this. But not the majority of
                                  > us. Desiree is right that most skilled UI designers need to have external
                                  > research to guide their knowledge and decisions. *Most*, but not *all*.

                                  I had intended to jump in with this point, but Jared beat me to it. I agree
                                  about the special few gifted "intuitive" (nonempirical?) designers. I have
                                  had the privilege of working with and learning from some of the best visual
                                  and interaction designers on the planet, pros who can hit the target square
                                  on without benefit of external research and minimal reliance on user
                                  testing. I have noticed a few things about those among us who can design
                                  well in this manner. (You know me, I always want to understand what is going
                                  on when I see someone doing magic.) The term "intuitive" is appealing, but I
                                  think there may be some specific talents and techniques behind the widget
                                  wizardry, and maybe we can learn from what such magicians do.

                                  Most of them are strong visual thinkers. They not only can visualize designs
                                  quickly, even without putting pencil to paper or marker to board, but they
                                  are able to carry out gedanken experiments to evaluate their designs,
                                  rapidly walking through imaginary interaction scenarios in their heads. I
                                  have been on teams where the group struggled to come up with alternatives
                                  while a star designer sat quietly constructing and testing mental prototypes
                                  before describing a brilliant combination.

                                  They are also good at what social psychologists refer to as role taking,
                                  that is, they can easily take on the role of or put themselves in the
                                  position of particular users. Often they seem to be able literally to see
                                  how something might look to someone else. These role-taking designers often
                                  make strikingly good guesses about how particular kinds of users will act
                                  and react even in arenas in which they have little or no subject matter
                                  expertise or experience.

                                  It may be a related faculty that they tend to be good at what Meilir
                                  Page-Jones calls "dereferencing." They can consciously step out of the
                                  frame, as it were, to get a new perspective on a problem. This serves them
                                  well not only in creative idea generation, but also in being able to step
                                  back and look with a fresh and critical eye at their own ideas to see where
                                  there will be problems.

                                  Indeed, many of the best are fanatically persistent problem solvers who
                                  worry away at working through toward that ideal solution. They are far more
                                  invested in finding the best solution than most designers I have known, yet
                                  they have less ego-investment in their own ideas or in any particular
                                  approach.

                                  There is probably much more to it--could be a good topic for an article
                                  sometime--but these are a start in terms of what might be going on with the
                                  best intuitive/nonempirical designers: visual thinking, gedanken
                                  experiments, role taking, dereferencing, and fanatical focus on solutions.
                                  Some of these are possibly largely matters of brain wiring (such as visual
                                  thinking), but others might be learnable skills to some degree.

                                  --Larry Constantine, IDSA
                                • kauerrolemodel
                                  ... an ideal ... taking... ... Hello Larry, et al... I m new to this group at the invitation of Mr. Patton. Some of you may know who RoleModel Software is
                                  Message 16 of 19 , Jan 18, 2006
                                  • 0 Attachment
                                    --- In agile-usability@yahoogroups.com, "Larry Constantine"
                                    <lconstantine@f...> wrote:
                                    > Jared wrote:
                                    > > I have seen, with my own eyes, people who intuitively can design
                                    an ideal
                                    > > solution without having conducted any external research....
                                    >
                                    > [snip]
                                    > Most of them are strong visual thinkers...
                                    > They are also good at what social psychologists refer to as role
                                    taking...
                                    > It may be a related faculty that they tend to be good at what Meilir
                                    > Page-Jones calls "dereferencing."...
                                    > Indeed, many of the best are fanatically persistent problem solvers...

                                    Hello Larry, et al...

                                    I'm new to this group at the invitation of Mr. Patton. Some of you
                                    may know who RoleModel Software is (http://rolemodelsoftware.com), as
                                    we were the first custom software development company that I know of
                                    that committed themselves to building software with XP. We made that
                                    decision in 1998 and have been doing it ever since (though we were
                                    doing very little of it several years ago when software gigs were hard
                                    for anyone to come by).

                                    I've been doing custom software development for years in an agile way
                                    (before we knew that we should call it agile), first in Smalltalk
                                    (where I pair-programmed as often as anyone would let me and had my
                                    most successful projects in team rooms). When I started my business,
                                    I was trying to figure out how to market what I believed was the best
                                    way to develop software, and Kent finally convinced me that if you do
                                    all of the practices all of the time - or at least make them the rule
                                    rather than the exception - you had a viable sustainable process and
                                    there was data to prove it... he didn't tell me that the proof was
                                    left to the adopter :-).

                                    I've had teams with "usability" people on them, and I've had some
                                    without. Generally, the teams with the usability people on them had
                                    more pleasant user interfaces and bigger budgets to get there. I've
                                    seen software developers have a pretty good intuitive feel for
                                    usability issues, and have certainly become more sensitive to it
                                    myself over time. When you have developers like that talking to
                                    customers/end-users who don't have blinders on, I really haven't seen
                                    the value (relative to cost) for a usability expert to be brought in.
                                    Sometimes, access to end-users are hard to get for a variety of
                                    reasons (almost never good ones, in my book, but they are reasons
                                    nonetheless). It takes a special kind of person who I'm still looking
                                    for to get enough input from end users who are hard to get access to
                                    when project sponsors are the ones blocking your access.

                                    Unfortunately, in my world, it's VERY difficult to know ahead of time
                                    what I'm going to face until we're into the project awhile. And I
                                    have to quote a price for a project before I have enough data to know
                                    whether I can get away with little outside usability help or need a
                                    lot (or need a new project sponsor).

                                    So, I have two questions:

                                    1. How do you work around this problem realistically? (I'd prefer
                                    input from people who have tried things and been successful... I've
                                    gotten pretty good at assessing new clients/projects with very little
                                    introduction... I'm not talking about hypothetical situations, I'm
                                    talking real ones).

                                    2. Having learned how to negotiate projects where I have SOME slack to
                                    bring in usability experts when my development team is either weak in
                                    this area or just needs more concentrated help, I currently find
                                    myself in a situation where I have some budget to bring in the right
                                    kind of help for one or more projects I have going right now that are
                                    either in their early stages or just getting started. Is there anyone
                                    out there that thinks they might have the right skills and time
                                    available in the next few months to work through this with me in North
                                    Carolina? If so, please respond to me privately and we can talk about
                                    possibilities.

                                    Ken
                                  • Peter Boersma
                                    ... Welcome! ... Isn t this true for both the usability work and the software development costs? Or do you need an expert at estimating the usability
                                    Message 17 of 19 , Jan 19, 2006
                                    • 0 Attachment
                                      Ken wrote:

                                      > I'm new to this group at the invitation of Mr. Patton.

                                      Welcome!

                                      > Unfortunately, in my world, it's VERY difficult to know ahead of time
                                      > what I'm going to face until we're into the project awhile. And I have
                                      > to quote a price for a project before I have enough data to know
                                      > whether I can get away with little outside usability help or need a lot
                                      > (or need a new project sponsor).

                                      Isn't this true for both the usability work and the software development
                                      costs? Or do you need an expert at estimating the usability complexities of
                                      the project, just like you estimate the complexity of the software required?

                                      > [..] How do you work around this problem realistically? (I'd prefer
                                      > input from people who have tried things and been successful... I've
                                      > gotten pretty good at assessing new clients/projects with very little
                                      > introduction... I'm not talking about hypothetical situations, I'm
                                      > talking real ones).

                                      At my previous employer we developed a use-csase based estimation model with
                                      complexity scales for software and usability. As soon as a first use case
                                      model could be drafted, an estimate for the workload of several competences
                                      (software architects, developers, QA-staff, front-end developers and user
                                      experience designers) could be derived.
                                      The model was built using historical data; we could compare the data over
                                      projects because most of our projects were the same (transactional
                                      applications for government agencies). It was evaluated and updated annualy
                                      by feeding the data from the year's projects into it.

                                      Peter
                                      --
                                      Peter Boersma | Consultant User Experience | User Intelligence
                                      Vlaardingenlaan 9d | 1059 GL | Amsterdam, The Netherlands
                                      p: +31-20-4084296 | m: +31-6-15072747 | f: +31-20-4084298
                                      mailto:boersma@... | http://www.peterboersma.com/blog
                                    • Larry Constantine
                                      Ken, Good to see you checking in here. ... Developers with insight and some skills and willingness to collaborate with both end-users and customers can
                                      Message 18 of 19 , Jan 19, 2006
                                      • 0 Attachment
                                        Ken,

                                        Good to see you checking in here.

                                        > I've had teams with "usability" people on them, and I've had some
                                        > without. Generally, the teams with the usability people on them had
                                        > more pleasant user interfaces and bigger budgets to get there. I've
                                        > seen software developers have a pretty good intuitive feel for
                                        > usability issues, and have certainly become more sensitive to it
                                        > myself over time. When you have developers like that talking to
                                        > customers/end-users who don't have blinders on, I really haven't seen
                                        > the value (relative to cost) for a usability expert to be brought in.
                                        > Sometimes, access to end-users are hard to get for a variety of
                                        > reasons (almost never good ones, in my book, but they are reasons
                                        > nonetheless). It takes a special kind of person who I'm still looking
                                        > for to get enough input from end users who are hard to get access to
                                        > when project sponsors are the ones blocking your access.

                                        Developers with insight and some skills and willingness to collaborate with
                                        both end-users and customers can certainly turn out decent user interfaces.
                                        Indeed, Lucy and I have made our marks in part by training developers in
                                        interaction design and usability. So, there is no magic that people with one
                                        set of initials after their names can have that is unavailable to those with
                                        a different set.

                                        But, yes, enhanced usability does not come free (at least not usually)
                                        anymore than does any of the other "ilities" of software. One could reverse
                                        your assertion by noting that projects with lower budgets did not have
                                        usability people and ended up with less "pleasant" user interfaces.
                                        Actually, that choice of adjective says a lot about what was being purchased
                                        by having usability people involved. I aim a lot higher in my work. Indeed,
                                        "pleasant" design and user satisfaction rarely figure high in my agenda,
                                        which is dominated by reducing training time, cutting errors, speeding up
                                        task completion, and the like. And that's why one should include usability
                                        (people, process,...) in the budget.

                                        > Unfortunately, in my world, it's VERY difficult to know ahead of time
                                        > what I'm going to face until we're into the project awhile. And I
                                        > have to quote a price for a project before I have enough data to know
                                        > whether I can get away with little outside usability help or need a
                                        > lot (or need a new project sponsor).

                                        A perennial problem for all of us. That is why I only work on a
                                        time-and-travel basis.

                                        As with programming, one tends to get what usability one pays for. If you
                                        only budget for a day of some outside expert's time to "look over" the UI
                                        and "make some recommendations" you will not get a lot to show for it--but
                                        you should get something. On the other hand, if you bring in a good
                                        interaction designer to become part of your team and work through the whole
                                        contract, you should get a whole lot, including some "technology transfer"
                                        as your team learns more about usability and how to improve it.

                                        As to real world experience with agile usability, I've had a fair amount of
                                        it, some better than others. On one project for McKesson, we invested in
                                        heavy BDUF, then went into a classic XP iterative development. That project
                                        went swimmingly well and has been written up in two papers at foUSE 2002 and
                                        forUse 2003. (I'll send .PDFs to anyone who asks for them.) But it doesn't
                                        address your dilemma, as UI was a major budget item because the whole name
                                        of the game was cutting training for nurses, reducing medical mistakes, and
                                        speeding up patient management.

                                        Larry Constantine, IDSA
                                      • Jeff Patton
                                        ... Let me see if I can connect Larry s comments above and yours. Ken you mentioned a sensitivity to usability issues, and I m not sure I ve seen it as that -
                                        Message 19 of 19 , Jan 20, 2006
                                        • 0 Attachment
                                          --- In agile-usability@yahoogroups.com, "kauerrolemodel"
                                          <kenauer@r...> wrote:
                                          >
                                          > --- In agile-usability@yahoogroups.com, "Larry Constantine"
                                          > <lconstantine@f...> wrote:
                                          > > Jared wrote:
                                          > > > I have seen, with my own eyes, people who intuitively can design
                                          > an ideal
                                          > > > solution without having conducted any external research....
                                          > >
                                          > > [snip]
                                          > > Most of them are strong visual thinkers...
                                          > > They are also good at what social psychologists refer to as role
                                          > taking...
                                          > > It may be a related faculty that they tend to be good at what Meilir
                                          > > Page-Jones calls "dereferencing."...
                                          > > Indeed, many of the best are fanatically persistent problem solvers...
                                          >
                                          > I've had teams with "usability" people on them, and I've had some
                                          > without. Generally, the teams with the usability people on them had
                                          > more pleasant user interfaces and bigger budgets to get there. I've
                                          > seen software developers have a pretty good intuitive feel for
                                          > usability issues, and have certainly become more sensitive to it
                                          > myself over time. When you have developers like that talking to
                                          > customers/end-users who don't have blinders on, I really haven't seen
                                          > the value (relative to cost) for a usability expert to be brought in.

                                          Let me see if I can connect Larry's comments above and yours. Ken you
                                          mentioned a sensitivity to usability issues, and I'm not sure I've
                                          seen it as that - not exactly. I find myself fairly insensitive to
                                          usability issues at times. In my current role I've been dubbed the
                                          "human factors person" which means developers and business analysts
                                          come up to me a dozen times a day and ask me how something should
                                          look, or "is this better that that?" I find I can't really answer
                                          their questions - I just don't know. But, I then begin to ask them a
                                          bit about the person using the software. "Who are they? what do they
                                          know? What are they trying to accmplish when they'd see this on the
                                          screen?" As soon as I can build a mental model in my head of the
                                          person, then I can answer the questions. I've never seen it as being
                                          good at usability so much as being good at empathy. Larry's comments
                                          about role taking and de-referencing hit home there.

                                          I believe the ability to do that comes naturally to some people. This
                                          may be the type of developer you're describing Ken. Of course there's
                                          also the visual thinking thing, and bit of visual design aptitude
                                          doesn't hurt either. But the role-taking thing I think is essential.

                                          [I've got prior rants on self-centered design vs. user centered design
                                          - basically people with design opinions that can't or won't role take
                                          are self-centered designers since all design decisions they make are
                                          made from their own perspective.]

                                          While the ability to role-take may come naturally to some, it doesn't
                                          mean that if you don't have it you're out of luck. Asking questions
                                          about users, observing them, talking with them - all of this is user
                                          research. If you write all that stuff down, represent it some way,
                                          you've built a model that represents your understanding of the user.
                                          If, as you make evaluations about good and bad UI, you try to make
                                          them from the perspective of what you know about that user, you're
                                          starting to do that role taking.

                                          Building these types of models repeatedly strengthens your role-taking
                                          muscles. My assertion here is that if you don't naturally have
                                          strong role-taking muscles, you can exercise to strenthen them. If
                                          you're already strong at it, exercising makes you even stronger.

                                          Pretend for a moment you had a couch to move up a flight of stairs and
                                          you just didn't have the strength to do it. I'd go find a big strong
                                          person to move it. Pretend you moved couches for a living, and you
                                          didn't have the strength to do it. You can't have a big strong guy
                                          follow you around, so you'll have to do a bit of weight lifting to get
                                          that strength.

                                          If you're in the business of building software, building up that
                                          end-user empathy helps you make the dozens of day to day decisions
                                          that affect the product features it has, and how it looks and works.
                                          You can hire a person already strong at it - a usability expert - a
                                          strong couch-mover. Or you could give everyone on the team a bit of
                                          understanding on how user centered design works, and some exercises to
                                          help them do a little usability strength training. You may not need a
                                          heavyweight usability person if a few of your people can double up on
                                          problems and work together.

                                          Ken I'm hearing that you've observed that when you have developers
                                          with those skills, you don't need the expert. I'll second Larry's
                                          suggestion that training rank and file developers is a good way to go.
                                          I'm a victim of that strategy. Five years ago now Larry & Lucy
                                          trained this rank and file developer.

                                          > Sometimes, access to end-users are hard to get for a variety of
                                          > reasons (almost never good ones, in my book, but they are reasons
                                          > nonetheless). It takes a special kind of person who I'm still looking
                                          > for to get enough input from end users who are hard to get access to
                                          > when project sponsors are the ones blocking your access.

                                          Strong couch movers can get that sofa up the stairs fast. Weeklings
                                          can't. You've got to make the most of yout time with user. Those
                                          experienced with doing UCD stuff have a few more tools in their
                                          toolbelt to make the best use of that time. If they're good they can
                                          come away from a little user exposure with understanding and models
                                          that help the rest of the team empathize or role-take.

                                          One final note on end users: I very often see users as self-centered
                                          designers [reference the comment above]. By that I mean they make
                                          decisions purely from their own perspecive. This can be dangerous if
                                          you're asking one type of user to speak, give information, or make
                                          decisions on behalf of another type of user. What you're really doing
                                          is asking them to role-take. And, I suspect they're no better at it
                                          than the average developer is.

                                          Being able to understand and assume the role of a user of the software
                                          and make judgments on their behalf seems like a cornerstone of user
                                          centered design approaches - at least some of them. For me, it's the
                                          only thing that allows me to make the day to day decisions I need to
                                          about the look, feel, and behavior of the software.

                                          Thanks for posting Ken.

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