This article presents the value of just-enough user-centered design (user experience or UX) in an Agile development process like the Scrum approach of Agile project management.
Author: Niki Dare, UX Manager, Asynchrony Solutions
We all know design is important in the development process, even in projects developed through Agile methodology. But how far will just-in-time design really get you in creating a great user experience? Integrating usability and design into the agile process is a hot topic right now. Many people have offered up opinions, including taking advantage of Iteration zero and infusing each story or task with user-centered design principles. But the big dilemma still remains. How much upfront design and usability is too much to be considered Agile?
As a designer, I have been fortunate enough to be a member of several development teams that each followed their own unique process. Although what works well for one team doesn’t necessarily suit another team’s needs, the principle of integrating just enough user-centered design can be applied successfully within almost any agile development project:
Truly embracing Iteration zero, I have found pre-iteration planning to be extremely effective. This tactic works great if you have a client that knows what they want about a week in advance and is willing to mostly stay committed. Essentially the user experience team works an iteration ahead of the development team. A short pre-iteration planning meeting is had with the client to determine their upcoming needs for the next iteration. Often we have had these meetings on Mondays and then the development team is able to estimate the upcoming iteration’s work that Friday based of the user experience that the design team envisioned. Depending on the client, guerilla usability testing or un-moderated, remote usability testing on low-fidelity wireframes fits in nicely with this method since both can be prepared for quickly and yield an immediate response.
This method is most successful when there is an overall understanding of the application and its functions that is agreed upon. It also helps when the stories that are slated for upcoming iterations are somewhat related so some thought can be put into the user experience of a given workflow.
Minimum Marketable Features
The idea here is that a succinct set of tasks are identified as a minimum marketable feature. This feature, that should take no more than a couple of months to complete, is then well-defined and understood by the user experience and development teams. Similar to using iteration zero, it is best to allow the user experience group to be a feature ahead of the development team. For the first feature it may be helpful to start with something that is development heavy.
During the couple of months that the development team is coding a feature, the user experience group has a bit more time to breathe and conduct moderated usability testing to drive the creation of their wireframes, walkthroughs and screen mock-ups. Since this method mitigates features from being partially implemented (because the development team can’t move on to the next feature until this one is complete), the whole user experience can be evaluated and summative testing can be conducted after development is complete. The results from the usability study can be slated as an upcoming, minimum marketable feature.
Formative Testing vs. Summative Testing
Both methods 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 method is moderated testing conducted on-site so that the users can be observed directly and probed for as much insight as possible. Creating a test won’t take long once there is a good understanding of the system, but if user experience hasn’t been the main focus in the software 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 activities 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. But doing true just-in-time design can run the risk of losing sight of the big picture and creating a disjointed user experience or having to rework previously developed screens when new ones are added. 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, we must operate within each project’s specific 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 of 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.