7334Re: [agile-usability] Process Entry Points...
- Mar 27, 2011Brando,
I completely agree that having requirements dropped on your desk is hardly the right way to do anything.
I also have to say I'm not a big fan of doing a protype so the devs can get up to speed faster -- this is pretty much an illusion in my experience. The logic of "things went wrong because the right people weren't involved early enough" doesn't stop with UX.
Instead of "injecting" yourself into the process, your organization needs to figure out how the product owner, the designers and the developers are all equally responsible for delivering functionality.
-ccOn Fri, Mar 25, 2011 at 1:53 PM, 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 >>