Hi Sam,
Interesting you should bring up the ownership/partnership question. There
is a related thread going on right now ("Who does design engineering"). This
is precisely where the agile approach to software really shines--it requires
regular, repeated collaboration to sort of keep each other in check with
reality as well as help each other see how we can do better.
In fact, there is a particular technique within the agile umbrella called
domain-driven design that I believe shares a lot of the values that UCD has,
but perhaps we approach it with a bit more humility than is suggested in the
"insurrection" that Alan Cooper advocated. One of the things you do in
domain-driven design is to establish the "ubiquitous language" that is used
throughout (all the way from the business to the code).
The thing is that doing this facilitates a clarification (not just
exposition) of domain concepts with the business. Business folks tend to
take a lot for granted (not a bad thing necessarily; it just is), and this
is often where the difficulties in building software for them comes into
play. In order to automate some portion of the business, we have to help
them comb out the intricacies of what they do in a sufficiently definite way
that software can be made based upon the language without a lot
of interpretation, translation, and subsequent breakdown.
Granted, the focus is on domain concepts and object oriented design to
automate the core domain of the business, but clarifying domain concepts can
only help the overall UX. I would think a similar process would be
effective in terms of designing the interfaces, and it seems to me that this
is in large part where personas can help in that they, too, provide a sort
of common language, at least a common referent, to help focus the interface
design efforts. Discovering and establishing the personas with the business
is a great opportunity to collaborate with the business at an early
enough stage to get the sort of early influence over vision that I think
you're driving at. In both cases, the key is that we're working with the
business stakeholders to help clarify the business in a way that can be
translated into great software the meets the business needs.
I can see how my descriptions seem passive. That's largely due to the way I
see most businesses operating in terms of software today, but it is
dangerous to generalize about how businesses run. :) I agree that we need
an active partnership in order to be effective in making great software. I
tend to think that the business stakeholders ultimately "own" the product
and product vision. My hope, though, is that by increasing the lines of
communication and understanding between UX folks and devs/architects, we
will be more understanding and open to each others' input and challenges so
that no matter who is "in charge" on a particular project, we work together
to come to the best solution.
A big first step in this is helping devs and architects to understand the
importance and value of UX, how they can incorporate it into what they do
today, and how they can work with UX folks when they're available. I
actually just recently prepared a talk on this very thing and will be giving
it to developer groups throughout the year (I'm an
INETA<http://ineta.org/DesktopDefault.aspx?tabindex=6&tabid=11>speaker,
which gives me lots of opportunities).
Another big part will be UX folks being understanding and flexible. As I
said before, I'd warn against coming into a dev organization and trying to
change the processes (particularly trying to push back to waterfall, which
has become a byword for many). If the org is using agile, figure out how
you can work with it. I'm making suggestions here, but they're just
suggestions on how/where I think UX folks can plug in.
All this and a healthy dose of patience, patience, patience. :)
--Ambrose
On Fri, Feb 15, 2008 at 12:30 PM, Sam Zaiss <[EMAIL PROTECTED]> wrote:
> Hi Ambrose,
>
> I've been following this thread with a lot of interest... as I mentioned
> in a similar thread with Brian Hoffman (Overall Web Development
> Process), I'm currently working with my company to create a
> User-Centered Agile process. I agree with you - finding the right way to
> incorporate UCD talent into the Agile process is really the way to go.
>
> One thing I mentioned in the other thread is the importance of hooking
> into the up-front vision - which, while a documented part of the Agile
> process, gets very little coverage from what I can tell. I think it's
> de-emphasized because requirements will always change, but a solid
> vision is still needed to know what it is you're going to build.
>
> I'm curious - have you seen (or do you have) any thoughts on what
> interaction designers can do in partnership with management or
> architects to proactively clarify the vision, rather than design around
> whatever vision they receive?
>
> While I like the ideas for how the various disciplines plug in to the
> agile process, it still strikes me as passive. Someone tells interaction
> designers what the product vision is, and they design around it. Maybe
> these are decisions of the architects - and I agree that they're smart
> people capable of making these decisions on their own - but a
> partnership with interaction designers and usability folks can only
> serve to arrive at a better, user-centered vision, right?
>
> Cheers,
> -Sam
________________________________________________________________
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
