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.
>> IAs have already performed user research and the output was a
> 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.
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.
> 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.
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.
> 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.