Here are some of 5AM’s best practices for incorporating User Experience (UX) design into your agile software development process.
5AM Solutions' Glassbox Process
Determine the Scope
Bottom line first - what scope, time or cost constraints does your project have? Is it a major refactoring of the whole application or are you targeting whatever can be done within a sprint? Which pages generate the most customer support requests? What features do the user personas need to use most often (and least often)? Knowing this type of information is critical to determining where to focus your UX design efforts and how much time can be spent on it.
Start with UX
Generally speaking, it’s best to work on UX improvements at least one sprint ahead. Confine your up-front UX work to user research tasks such as card sorting, testing concepts with low-fidelity wireframes or paper prototyping, persona development and user interviews. Also, make sure UX resources are involved right from the outset (not brought in late, when development is commencing) so that there is minimal delay - this enables “one sprint ahead.”
Rapid Prototyping
Focus on lightweight artifacts. Balsamiq is perfect for rapid prototyping that can be easily distributed for review. Or, true to the spirit of agile, simply whiteboard your ideas and take a picture. Regardless of your design approach, try to get in as many rounds of review as possible to increase confidence in your solution. Eliciting incremental quality user feedback is key. A shared Google doc could work for this, but if you have the budget, we highly recommend giving Usabilla a try.
Seeing is Believing
It’s possible that the low-fidelity solution is all that’s needed for the requirements to be approved and the developers to move forward with development. However, in our experience most folks want to see the “real thing” to get a better sense of the solution. In this case you should jump on creating high fidelity assets. If you have a UI designer involved, then starting with Adobe Photoshop is expected -- but if the application style guide is already set in stone, there’s no issue with having a UI developer jump right into creating static HTML/CSS.
There is no one size fits all method to gain final consensus. Try different approaches to see what works best for your team!
- by Rob Offutt
