Re: Process Entry Points...
I may be commenting too early on since I have not read the rest of the posts after this...
But there is only one comment related to UX/ usabiity starting ahead of the game where it needs to be... it is all about user research... which is a completely different understanding and viewpoint of a BA. I feel it is missing the whole point of finding the best way to integrate usability into the process. It is rare to find usability as any lead of discussions and that is where the problem is and I don't see these approaches helping but only reinforcing what is wrong with the current development processes... but this may be me projecting my own personal frustration I deal with day and out so I apologize if it is.
BAs need to work hand in hand with usability, not separate. Demos serve a minimal purpose and utility. Where is the usability testing... rapid iterations?? I may be speaking too soon but I find these posts missing the point.
--- In email@example.com, ElMohanned Ahmed <elmohanned@...> wrote:
> This is exactly how we do it.
> The business analyst are involved together in business requirements sessions
> at the beginning of each sprint\release. They can demo some mock-ups or
> paper sketches to the customer to help elicit his needs and help him
> visualize the expected system. By the end of the requirements a storyboard
> is built either on paper or using any mock-up tool. The input to the team is
> the stories and the storyboard. The usability guy may actually build some
> sample pages to the team too.
- First, let me say how much i enjoy reading posts to this group. I've learned a great deal lurking here. Thanks. Back to topic...
It seems to me that there is one artifact that BAs, UXDs and Devs can and should collaborate on early on, and that is the object model or ontology of the domain.
It amazes me how often the metaphor used to generate the object model is wrong, and how significant a difference fixing it makes to not only code quality, but also usability.
We call this different things, but I do think that the same model is expressed in an IA, or navigational structure, as in a data model, or more or less implicitly in the business requirements.
Interestingly, a focus on capturing all the user stories or paths through the system does not help with clarifying this model (though testing the relative priority of user stories with actual users may help to reveal a better domain metaphor, by shifting the primary context of objects users act on)
Maybe what's required to complement the more user-centred approach of agile development is a more object-orientated approach to user experience?
I could be wrong about this, but it's also tempting to suggest that the object model is particularly hard to improve iteratively. I think this is because the kind of stories you tell about users are restricted by it. Actions are like judgements, while object types are the ontology within which those judgements are formed. Worse, users will themselves adopt the implicit ontology of the system they are using, which often makes it difficult to tell when their difficulties are catastrophic, in the sense of compromising the entire conceptual scheme.
And for that very reason, it's best not to leave the definition of that model to any one of UX, BA or Dev - they all bring different sorts of constraints and intuitions that must be reconciled in the domain model, and they all need to buy into the same metaphor to ensure that they can validate it within user, business and system contexts.
Experience Architect, Profero Sydney