7331Process Entry Points...
- Mar 25, 2011I 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.
- Next post in topic >>