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

Designer and usability roles pairing

Expand Messages
  • Jon Dickinson
    Hi, I am working on introducing agile methods to a project with a heavy focus on UCD. The team I am working with have worked with the following mini-phases in
    Message 1 of 7 , Mar 3, 2007
    • 0 Attachment
      Hi,

      I am working on introducing agile methods to a project with a heavy focus
      on UCD. 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)

      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.

      Thanks,

      --
      Jon Dickinson
      Accolade Consulting
      http://www.accolade-consulting.co.uk
    • 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 2 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 3 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 4 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 5 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 6 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 7 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.