In this thinking, turn things around: while you might have a QA
engineer or two who provide great input on design ideas, would you put
QA in charge of the design process? Probably not: their expertise may
sometimes approach or overlap those needed for design, but there will
be holes, gaps, and so forth. Unless you are truly cross-training,
you're going to end up with ultimately inferior results.
Which isn't to say that having QA involved in the design process, or
Design in the QA process, isn't a great idea. It most certainly is.
Watch out as well for asking designers to do QA work on the items they
designed. They can easily be way too picky and/or unable to look at
the pieces they designed with a fresh eye, to see interactions and
different angles. Better to use their designer eye to look at other
aspects of the product.
-- Jim Drew
Seattle, WA
Software QA for 18 years
On Oct 27, 2008, at 7:36 AM, Damon Dimmick wrote:
The company I work for is a very lean, fast moving company, and we're
constantly looking for ways to tighten our product life cycle
timelines.
One thing we've noticed in the last few months is that IxDA (and
general
design practitioners) have been extremely valuable not just during the
design phase of a product, but also during the ongoing Quality
Assurance
/ Quality Control phases as well as the final Quality Acceptance
phases
of the product lifecycle.
This being the case, we're experimenting with the idea of putting IxDA
people in charge (or in review positions within) the QA process. I've
been playing around with this model myself on a couple of projects
with
very strong results. The net benefit seems to derive from the fact
that
there is really no one better to certify that a product meets QA
requirements than the very people that identified the necessary
interactions, UI results, and full design elements to begin with.
So far, this also seems to fit in nicely with the fact that our design
team tends to be very busy at the start of the project (front loading
interaction design and then visual design) and then gets much less
busy
as the development cycle begins and ends. It seems a really good use
of
our time to swoop back in after the design phase and act as part of
the
QA process, making sure that developers are conforming to our
specifications via a formal testing structure.
I was wondering if anyone else has had experience with this kind of
structure, and if so, what challenges, results, and tips can you
share?
We're sort of excited about the idea on our end, as our initial forays
into this model have really helped projects move along faster and with
better results. Being a small/midsized team, we don't have a large QA
department, so this allocation of resources seems to fill a lot of
gaps.
Any thoughts out there among my colleagues?
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [EMAIL PROTECTED]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
