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

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

Expand Messages
  • 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 1 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 2 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.