7332Re: Process Entry Points...
- Mar 26, 2011I am interested to hear this feedback as well.
I agree UX should be engaged as part of Discovery or Inception. The question is the level of engagement. At my current client, the push back is that UX tends to dominate the conversation with product managers. Ideas that are very difficult to deliver get baked into requirements.
I'm recommending the following approach of two distinct conversations.
First, the BA gets to a proposed feature set and a high level use case. UX, along with architects, can listen and ask clarifying questions but are mostly present to understand. So initially engagement is fairly low. They don't actually even have to be present.
Then BA presents the initial discovery and gets input from UX and architects to produce options: Good, Better, Best solution sets. The Ba will Gain agreement and present these options to product managers. This may be the place for conceptual mock-ups.
The BA intentionally iterates between these two conversations. The BA must hold the context of learning from the product manager/ business and then developing viable options with UX, architects and dev. These are distinctly different conversations. I call this dialog then discussion (my Peter Senge reference :).
I'm looking forward to hearing other approaches. Dean Stevens
--- In email@example.com, "Brando" <brandonpmitchell@...> wrote:
> I am currently working to implement a flexible, but consistent Agile UX process at a large enterprise-software development group. We typically have 4-10 large scale projects going at any one time.
> As I examine current processes and look at where projects went off-course, or progressed slowly, is because they did not get UX/Strategy involved early enough. Our current practices seem to put any UX involvment -AFTER- requirements have been generally collected.
> It seems that in an Agile/Iterative environment, it makes sense for the UX side of the project to:
> - Be engaged AT the time that Business Analsyts are assigned
> - This could be BEFORE any Product Backlog or Features List is officially complete.
> - Understand HIGH-LEVEL functionality (not necessarily details)
> - Create early 'customer journey' sketches / outlines
> - BEFORE the rest of the development team actually joins, have an early conceptual mockup/design so it also helps the project team have a quicker understanding of the project --- visually.
> It just seems that getting a requirements document 'dropped on my desk' is not the most effective way to design an application.
> I'm looking for opinions on the best place to inject into the project.
> Any opinions, trials, or suggestions are welcome.
- << Previous post in topic Next post in topic >>