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

RE: [agile-usability] Designer and usability roles pairing

Expand Messages
  • Peter Boersma
    ... I hate to say that it shows, but it does. Or, to put it milder: the designers may not be aware of the complexity either. ... First of all: The graphic
    Message 1 of 7 , Mar 4, 2007
    • 0 Attachment
      Jon wrote:
      > I am working on introducing agile methods to a project with a heavy focus
      > on UCD.
      and:
      > The problem is I am from a development background and perhaps not aware of
      > any issues or complexities this combination may create.

      I hate to say that it shows, but it does. Or, to put it milder: the designers
      may not be aware of the complexity either.

      > The team I am working with have worked with the following
      > mini-phases in the past:
      > - graphic design (graphic designer)
      > - verify graphic design (UX professional)
      > - static build (UX professional)
      > - integrate with developer code (Developer)

      First of all: The graphic designer is as much a UX professional as the other resource who, from your description, seems to come from the hard-core "all I do is evaluate" usability school of thought (although the static building activity suggests he/she may be an interface designer with some feeling for usability but without visual design skills).

      Then you seem to say that the visual design is the first mini-phase that designers are involved in. What do the designers use as input? Are they involved in gathering that input (user experience requirements, user profiles, business goals)? Even if that input is available, they should get a say in the user scenarios/use cases/stories that are being developed.

      And it may be a misinterpretation or simplification, but the graphic design is not the only end-result that user experience designers deliver. I hope they also develop some kind of interaction design; a specification of what functionality is available on what screens under what conditions. A systematic description of what visual element goes where under what condition is another end result. It is entirely possible that not one full screen (which could be your "static build") is designed to the pixel-perfect level, although it usually helps to explain the concepts, see the elements work together, and these may be used for paper-prototype evaluation purposes too.

      And please, have them consider adding some kind of evaluation with actual users to the project. Only if the all user types, their goals and preferences, problems with existing software, and appreciation of the concept and functionality that is developed here are all known (a *very* unlikely scenario!) I could see how a heuristic evaluation by an experienced usability expert can be sufficient.

      Now, to get to your question of pairing up a visual designer and an (if I may suggest) interaction designer: that's not a bad idea at all. Together they could work on understanding what the conditions are under which functional and visual elements are shown (which may or may not be indicated in use cases/scenarios) on the screens, to make appropriate design decisions that match. They could base their design documentation on the same underlying grid system to ease the job of the developer that has to match the two specifications to create one working system. They could use the same naming or numbering convention for elements that appear on screens, if there is a need for that.
      And finally, they could be a second and third pair of eyes on the results of subsequent work, inspecting the placement of elements and how they work together under a (limited) set of test conditions.

      Peter
      --
      Peter Boersma | Senior Interaction Designer | Info.nl
      http://www.peterboersma.com/blog | http://www.info.nl
    • Adrian Howard
      On 3 Mar 2007, at 23:26, Jon Dickinson wrote: [snip] ... [snip] Done both of these. Seen it work very well. Only problems I ve encountered are ones of
      Message 2 of 7 , Mar 4, 2007
      • 0 Attachment
        On 3 Mar 2007, at 23:26, Jon Dickinson wrote:
        [snip]
        > The graphic design and verification of the design seems to cause a
        > lot of
        > churn. I am suggesting for the graphic designer and UX professional to
        > pair on the graphic design and so get it out of the way as one task
        > rather
        > than the prolonged back and forth that seems to happen at the
        > moment. The
        > problem is I am from a development background and perhaps not aware
        > of any
        > issues or complexities this combination may create. Has anyone used
        > pairing between graphic designers and usability people before, or can
        > anyone see immediate problems with this approach?
        >
        > We are going to have the same back and forth churn with the static
        > build
        > and integration so the idea is to get some pairing going here and
        > get the
        > usability person and developer to focus on the same task at the
        > same time.
        [snip]

        Done both of these. Seen it work very well.

        Only problems I've encountered are ones of scheduling and perceived
        power games. The UX person wanted to be doing "other things" while
        the gfx person was working. The Gfx dude saw pairing and micro-
        management. However once they tried it they were convinced that it
        was a far more effective way of working.

        Adrian
      • Jon Dickinson
        On Sun, 04 Mar 2007 09:36:01 -0000, Peter Boersma ... Point taken about the UX professional comment. I ll take your Interaction
        Message 3 of 7 , Mar 4, 2007
        • 0 Attachment
          On Sun, 04 Mar 2007 09:36:01 -0000, Peter Boersma <peter@...>
          wrote:

          > First of all: The graphic designer is as much a UX professional as the
          > other resource who, from your description, seems to come from the
          > hard-core "all I do is evaluate" usability school of thought (although
          > the static building activity suggests he/she may be an interface
          > designer with some feeling for usability but without visual design
          > skills).

          Point taken about the UX professional comment. I'll take your Interaction
          Designer and convert him to an Information Architect.

          > Then you seem to say that the visual design is the first mini-phase that
          > designers are involved in. What do the designers use as input? Are they
          > involved in gathering that input (user experience requirements, user
          > profiles, business goals)? Even if that input is available, they should
          > get a say in the user scenarios/use cases/stories that are being
          > developed.

          I cut down the work already performed by the IAs to try and simplify the
          problem that I am dealing with, this doesn't appear to have worked. The
          IAs have already performed user research and the output was a wireframe
          document. The visual design is not the first phase, apologies for
          misleading you. This all happened before I was involved and I didn't want
          to get bogged down in the history of the project.

          The designer has the wireframe document, some brand guidelines and
          business goals as input. The designer was not involved in the user
          research or the creation of the wireframe document.

          > And it may be a misinterpretation or simplification, but the graphic
          > design is not the only end-result that user experience designers deliver.

          Agreed. Although perhaps I can't agree with all of your suggestions below
          when working on an agile project. Would you really create the following
          deliverables when working on an agile project?

          > a specification of what functionality is available on what screens under
          > what conditions.

          > A systematic description of what visual element goes where under what
          > condition is another end result

          That seems like a lot of work before the customer and users get to see
          anything to be able to provide real feedback. I realise that the wireframe
          document I have mentioned seems to cover what you have suggested above,
          but I personally would have recommended that the time and effort spent on
          creating this document would have been better spent creating prototypes or
          building something to get real feedback.

          So instead of the process looking like this:
          - wireframes (IA)
          - graphic design (graphic designer)
          - verify graphic design (IA)
          - static build (IA)
          - integrate with developer code (Developer)

          It would look more like this:
          - prototype then build and graphic design and build in parallel
          - get feedback, prototype, graphic design and build in parallel
          - get feedback, prototype, graphic design and build in parallel
          - get feedback, prototype, graphic design and build in parallel

          The prototyping would gather just enough information to be able to design
          and build somthing that can be released to some users for feedback.

          > Now, to get to your question of pairing up a visual designer and an (if
          > I may suggest) interaction designer: that's not a bad idea at all.
          > Together they could work on understanding what the conditions are under
          > which functional and visual elements are shown (which may or may not be
          > indicated in use cases/scenarios) on the screens, to make appropriate
          > design decisions that match. They could base their design documentation
          > on the same underlying grid system to ease the job of the developer that
          > has to match the two specifications to create one working system. They
          > could use the same naming or numbering convention for elements that
          > appear on screens, if there is a need for that.
          > And finally, they could be a second and third pair of eyes on the
          > results of subsequent work, inspecting the placement of elements and how
          > they work together under a (limited) set of test conditions.
          >
          > Peter

          Thanks for the feedback.

          --
          Jon Dickinson
          Accolade Consulting Ltd.
          http://www.accolade-consulting.co.uk
        • Adrian Howard
          On 4 Mar 2007, at 15:46, Jon Dickinson wrote: [snip] ... [snip] I find a bunch of those artifacts still exist, but they re produced just-in-time (sketched on a
          Message 4 of 7 , Mar 5, 2007
          • 0 Attachment
            On 4 Mar 2007, at 15:46, Jon Dickinson wrote:
            [snip]
            >> a specification of what functionality is available on what screens
            >> under
            >> what conditions.
            >
            >> A systematic description of what visual element goes where under what
            >> condition is another end result
            >
            > That seems like a lot of work before the customer and users get to see
            > anything to be able to provide real feedback. I realise that the
            > wireframe
            > document I have mentioned seems to cover what you have suggested
            > above,
            > but I personally would have recommended that the time and effort
            > spent on
            > creating this document would have been better spent creating
            > prototypes or
            > building something to get real feedback.
            [snip]

            I find a bunch of those artifacts still exist, but they're produced
            just-in-time (sketched on a white board or whatever) and move into
            the code a lot faster than normal.

            For example I find that I spend a lot of time in the planning game
            sketching out interface ideas on whiteboards, and a lot of time
            refining things when we're writing acceptance tests before
            implementing stories.

            Cheers,

            Adrian
          • Peter Boersma
            ... I m sorry, but do you mean you tried to simplify the problem in your description to us, or did you change the scope of the project making some of the work
            Message 5 of 7 , Mar 6, 2007
            • 0 Attachment
              Jon wrote:
              > I cut down the work already performed by the IAs to try and simplify the
              > problem that I am dealing with, this doesn't appear to have worked.

              I'm sorry, but do you mean you tried to simplify the problem in your description to us, or did you change the scope of the project making some of the work of the IA obsolete? If the latter is the case, I can see why they're making life hard for you ;-)

              > The
              > IAs have already performed user research and the output was a wireframe
              > document.

              Good, but that also means they've already done design work and hopefully some kind of evaluation of the conceptual design behind the (more or less) detailed wireframe work.

              > The designer has the wireframe document, some brand guidelines and
              > business goals as input. The designer was not involved in the user
              > research or the creation of the wireframe document.

              For a lot of projects, that should be enough to start on the first iteration.
              Note that the first iteration may not lead to anything more than a couple of moodboards indicating the style or the way the brand guidelines could be translated to the online world, rough sketches of pages made with markers and without a straight line, an initial grid system, a visual language of components without any screen being designed at all. There is a very good chance that there is not enough to prototype or build anything.

              > Would you really create the following
              > deliverables when working on an agile project?
              > > a specification of what functionality is available on what screens under
              > > what conditions.
              > > A systematic description of what visual element goes where under what
              > > condition is another end result

              Yes, and as Adrian (IIRC) indicated, these may be in the shape of (photographs of) wireframe sketches plus notes on whiteboards for the IA and glued-together cut-outs of prints of the visual language specification placed on a blow-up of the grid projected on the wall. I don't care how agile you get with these steps, as long as you perform them and evaluate the outcomes.

              > That seems like a lot of work before the customer and users get to see
              > anything to be able to provide real feedback.

              Define "real feedback" :-)
              Users can, in a concept test session, indicate preference, associations, applicability, brand-adherence, and more based on moodboards, sketches and visual language representations just as good or even better than on pixel-perfect representations or semi-functional prototypes with tempting (thus distracting) input fields, shiny links and throbbing buttons. And this method is likely to be cheaper than building potentially throw-away code and can be done before any code is written, integrated, tested and placed in a prototype environment.
              Similarly, for the IAs work, a wizard-of-oz style paper-prototype test can yield valuable information about the expected behaviour of users when confronted with the design before it is hardcoded. This might trump the results of a session where every other screen isn't available because the code didn't make in into the sprint.

              Trust me, I believe that agile methods for both the user experience as well as the software design aspects can be applied to a certain class of projects. All I am saying is that their outcomes don't *have* to be combined into working prototypes at all times, and that some of the work (on either aspect) can be done in a different order than that of the other. For example, I can see a visual designer develop a button style that is applicable to all fill out forms, but that doesn't mean that all fill-out forms need to be coded when she's done. Conversely, the code for processing the XML of all fill-out forms may be ready before the IA decides what forms need what elements in what order. But in my opinion this is true for non-agile projects too, right?

              Peter
              --
              Peter Boersma | Senior Interaction Designer | Info.nl
              http://www.peterboersma.com/blog | http://www.info.nl
            • Adrian Howard
              ... Yes. Not that scope reduction itself is a bad thing. But you need to involve everybody in the discussion. ... [snip] Yup. That s one of the big problems I
              Message 6 of 7 , Mar 7, 2007
              • 0 Attachment
                On 7 Mar 2007, at 06:38, Peter Boersma wrote:

                > Jon wrote:
                >> I cut down the work already performed by the IAs to try and
                >> simplify the
                >> problem that I am dealing with, this doesn't appear to have worked.
                >
                > I'm sorry, but do you mean you tried to simplify the problem in
                > your description to us, or did you change the scope of the project
                > making some of the work of the IA obsolete? If the latter is the
                > case, I can see why they're making life hard for you ;-)

                Yes. Not that scope reduction itself is a bad thing. But you need to
                involve everybody in the discussion.

                >> The
                >> IAs have already performed user research and the output was a
                >> wireframe
                >> document.
                >
                > Good, but that also means they've already done design work and
                > hopefully some kind of evaluation of the conceptual design behind
                > the (more or less) detailed wireframe work.
                [snip]

                Yup. That's one of the big problems I have with sort of handover
                arrangement. Those design concepts are in the IAs heads - not in the
                wireframes. The whole team needs to understand the whys.

                [snip]
                > Users can, in a concept test session, indicate preference,
                > associations, applicability, brand-adherence, and more based on
                > moodboards, sketches and visual language representations just as
                > good or even better than on pixel-perfect representations or semi-
                > functional prototypes with tempting (thus distracting) input
                > fields, shiny links and throbbing buttons. And this method is
                > likely to be cheaper than building potentially throw-away code and
                > can be done before any code is written, integrated, tested and
                > placed in a prototype environment.
                [snip]

                For what it's worth one of the things I've had to get my head around
                with doing usability related work in more agile teams is that the
                cost of getting a subset of the system up and running is a _lot_
                lower - and the more relevant feedback I can get from that subset is
                a lot more useful than some of the conceptual work that I did before.

                > Similarly, for the IAs work, a wizard-of-oz style paper-prototype
                > test can yield valuable information about the expected behaviour of
                > users when confronted with the design before it is hardcoded. This
                > might trump the results of a session where every other screen isn't
                > available because the code didn't make in into the sprint.

                Agree completely.

                > Trust me, I believe that agile methods for both the user experience
                > as well as the software design aspects can be applied to a certain
                > class of projects. All I am saying is that their outcomes don't
                > *have* to be combined into working prototypes at all times, and
                > that some of the work (on either aspect) can be done in a different
                > order than that of the other. For example, I can see a visual
                > designer develop a button style that is applicable to all fill out
                > forms, but that doesn't mean that all fill-out forms need to be
                > coded when she's done. Conversely, the code for processing the XML
                > of all fill-out forms may be ready before the IA decides what forms
                > need what elements in what order. But in my opinion this is true
                > for non-agile projects too, right?

                The problem is that if we don't go all the way from concept to code
                every time we lose the ability to get that rapid feedback from a
                running system. I've learned to value that feedback highly over the
                last few years so I try very hard to make it happen.

                Cheers,

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