The Value of Just-Enough User-Centered Design in an Agile Development Process
Continued from “What About the Big Picture – Part 1”…
Formative Testing vs. Summative Testing
Both methods I mention in my previous post include formative testing, or the testing that is done on low-fidelity prototypes before coding begins. Validating any new additions to the system, this type of testing is very beneficial to maintaining a good user experience.
If you have an existing project that has not been focusing on your end user’s experience, and you are looking to incorporate user-centered design, then Hurrah! Welcome Aboard! Unfortunately you will have to set aside time to conduct some summative usability testing on the existing system and be willing to take action on those results. The most effective type of testing to do would be moderated testing conducted on-site so that the users can be observed directly and probed for as much insight as possible. Creating the test wouldn’t take long after there was a good understanding of the system, but if user experience hasn’t been the main focus in the development process, then you may be in for a rude awakening. The actionable items coming out of those results could fill an iteration or more, or even a release. The best thing to do is to conduct usability tests on individual processes or tasks in the system and then act immediately on the findings. Try to keep the scope of the test as narrow as possible so scripting the test is quick and too many development tasks don’t result from the testing.
The Danger of Only Doing Just-In-Time-Design
The Agile development process boasts doing things just-in-time to mitigate waste and allow for requirements to change even while code is being written. Just-in-time design can work in cases where a high-level design or concept has been created and approved. It is easy to add an additional screen to an application with a well-thought-out user experience. To do true just-in-time design, there runs a huge risk of losing site of the big picture and creating a disjointed user experience or having to often rework several previously developed screens with the addition of a new one. I think just enough design work creates a better, more cohesive end user experience, saves time in development and ultimately saves the client’s money for adding in even more features.
As far as just-in-time usability is concerned, there is only so far we can go with time constraints. Formative testing can be conducted rather quickly and in-sync with shorter development cycles. There is no question that if the user is satisfied with the proposed system before it is built, then there will be less rework when the software is released. Summative testing requires a couple of weeks at least; especially if it is being conducted on a system that wasn’t user-centered in the first place. A system can be dramatically improved from the results of summative testing, especially the first few rounds. Summative testing must be done after development of a feature or task flow is complete so that the user experience is cohesive and able to be tested by end users. The only aspect of a summative usability test that I would even consider to be just-in-time would be acting on the results on the test in the next possible iteration, above any new features.
I have yet to discover a blanket strategy for seamless integration of design and usability into the agile development process. I think the best thing to do is understand the needs of your client and development team the best that you can and then start trying things until you find a good fit. Don’t be afraid to throw out an idea if it isn’t suiting everyone’s needs. The road will be bumpy, but don’t give up. Your users will thank you for thinking about their experience.