Current Issue
Introduction to Agile Usability, User Experience Activities on Agile Development Projects - Part II - 13 April 2007
by Scott W. Ambler
This article was originally published at the website of Agile Modeling by Scott W. Ambler
Courtesy of Scott W. Ambler
Read this article in Chinese
(translated by Liang Zhang)
5. User Experience Modeling on an Agile Project
ASD practitioners are very pragmatic when it comes to modeling. The Agile Modeling (AM) methodology describes in detail how agilists approach both modeling and documentation. Figure 2 (at bottom) overviews the lifecycle of an Agile Model Driven Development (AMDD) approach to ASD, an approach which originally grew out of the XP community but which seems to capture the essence of the modeling approach on agile projects in general. Each box in the diagram represents a development activity. The initial modeling activity during Cycle 0 includes two main sub-activities, initial requirements modeling and initial architecture modeling which are done iteratively in parallel. The model storming and implementation activities potentially occur during any cycle, including Cycle 0 (yes, the rumors are true, agile practitioners will often implement working software the very first week of a project). The time indicated in each box represents the length of an average session: for example, during development you’ll often model storm for a few minutes with a stakeholder to explore a requirement and then code for several hours.
The initial modeling effort is typically performed during the first week of a project. For short projects (perhaps several weeks in length) you may do this work in the first few hours and for long projects (perhaps on the order of twelve or more months) you may decide to invest up to two weeks in this effort. There are two aspects to the initial modeling effort:
- Requirements modeling. You need to identify the high-level requirements as well as the scope of the current release. The goal is to get a good gut feel what the project is all about, and to do that you will likely need to create an initial usage model to explore how users will work with your system (e.g. use cases or usage scenarios), an initial domain model which identifies fundamental business entity types and the relationships between then, and optionally other important artifacts exploring technical requirements.
- Architectural modeling. The goal of the initial architecture modeling effort is to try to identify an architecture that has a good chance of working. 99% of the time agile practitioners simply gather around a whiteboard and create free-form diagrams as they discuss various architectural strategies. When the UI architecture is an important consideration, agile modelers will create a UI navigation diagram (see Figure 3 at bottom) which explores initial relationships between important screens/pages and reports (thereby giving you a birds-eye view of the UI, enabling you to ask fundamental usability questions).
In later cycles your initial models will evolve as you learn more, but during Cycle 0 the goal is to get something that is just barely good enough so that the team can get going. You don’t need to model a lot of detail, and I cannot stress this enough: the goal is to build a shared understanding, it isn’t to write detailed documentation.
During development cycles the vast majority of modeling sessions involve a few people, usually just two or three, who discuss an issue while sketching on paper or a whiteboard. These model storming sessions are “just in time” (JIT) efforts: you identify an issue which you need to resolve, you quickly grab a few team mates who can help you, the group explores the issue, and then everyone continues on as before.
Sometimes modeling storming isn’t enough. Perhaps you need to model complex requirements which require input from someone outside of your immediate team, or perhaps you need to model a legacy asset which can take a significant amount of time. In other words, you may need to model a bit ahead of actually implementing a requirement. This is actually a rare occurrence, regardless of what traditional modelers may hope for, but it does happen every so often.
All of this begs the question “how can UEX activities fit in to an agile project?” The easy answer is that agilists need to adopt usage-oriented requirements artifacts, such as personas, scenarios, or even use cases. The quickly explore user interface requirements, it is common to create abstract/low fidelity prototypes out of paper, such as the one in Figure 4 created from a flip chart sheet and sticky notes. This allows to you quickly explore the UI without doing a lot of up front work, and even enables agile usability testing. In fact several agile methodologies have done so, respectively Agile MSF, Agile Modeling, and the AUP. After this, it’s not so easy.
UEX practitioners can rail about the need for doing lots of design up front, but that message falls on deaf ears within the agile community. The bottom line is that from an agile perspective, traditional UEX techniques aren’t very usable for them, which is rather ironic when you stop and think about it. To make UEX techniques usable to agile practitioners, they must reflect the agile lifecycle. Luckily, this can be accomplished by:- Doing some UI modeling up front. You need to establish 3 things: Overall organization for the parts of the UI that fits with the structure of user tasks; a common scheme for navigation among all the parts; a visual and interaction scheme that provides a consistent look-and-feel to support user tasks. Yes, this takes some up-front work, but for the vast majority of systems this could easily be accomplished during Iteration 0. Remember that the amount of modeling that you need to do up front is dependent upon the context—some teams will need to do more than others.
- Using modeling tools which reflect agile practices. For example, XP teams prefer to work with index cards, not documents, and AUP teams prefer whiteboard sketches. Luckily paper and whiteboards are common tools with many UEX practitioners.
- Modeling a bit ahead when appropriate. If you need to, explore important aspects of the UI before you implement them. Conducting a user session often involves scheduling specialized facilities that are in high demand, and making appointments with the appropriate stakeholders. Therefore you need to model a bit ahead.
- Doing UI development on a JIT basis the majority of the time. The UI is important, but then again so are many other aspects of a system (such as the network, the database design, and so on) and therefore the UI should be treated differently only when appropriate. When the goal of design is limited to a single feature or small set of features it is effective to perform UEX activities as part of the development of those features during the iteration.
- Adopt UEX-friendly requirements artifacts. As I pointed out earlier, some agile methods such as AUP, DSDM, and Agile MSF already do this. This same philosophy could be applied in XP, and frankly many XP teams already capture the need to implement a UI view as a user story.
6. User Testing on an Agile Project
For the sake of this article, user testing encompasses:
- Acceptance testing
- Usability testing
- Usage testing
6.1 Acceptance Testing
The agile community has embraced the importance of acceptance testing, having built tools such as Fit (Mugridge and Cunningham 2005) to help automate it. The automated tests will be run often, at least daily if not several times a day. Manual user testing, on the other hand, is typically done an iteration behind. At the end of an iteration, many agile teams will deploy the working system into a QA/testing environment where user and system testing is performed. The team continues on, developing version N+1 of the system while obtaining defect reports pertaining to version N. Defect reports are treated just like any other requirement: they are estimated, prioritized, and put on the requirements stack to be addressed at some point in the future.
6.2 Usability Testing
Usability testing is considered optional, and I have no doubt that many UEX practitioners will find that frustrating. Agile teams are little different from traditional teams in this respect, they very likely don’t appreciate the need for usability testing (or other UEX practices for that matter). True usability testing requires repeated testing with numbers of users under controlled settings. Just like acceptance testing can be done regularly throughout development, so can usability testing. On agile projects usability testing should occur during the user testing effort after each iteration, assuming of course that someone on the team has those skills.
There is a range to usability testing. At the “agile end” of the spectrum is Jeff Patton’s agile usability testing. In a workshop at the Agile 2006 conference Patton described a technique where people simulate the system using abstract prototypes (see Figure 4 at bottom). Using this strategy one developer simulates the system. They’re not allowed to speak, only help the user navigate between “screens” (the paper prototypes). At least one user, although two seems to work well, works through a scenario via the paper prototype. For example, in a university system a scenario might be that they try to enroll in a seminar. The user(s) should narrate/discuss what they’re thinking as they use the system. One or more developers act as observers, taking notes but not fixing the paper prototypes as the users work with the system.
At the formal end of the spectrum is traditional usability testing where users are observed in a usability lab which is typically a room where a user can be observed working with the system. Usability labs often have one-way windows which enable people to watch the user, often a valuable learning experience for developers who mistakenly think that they’ve done a great UI design job. Some labs will even be outfitted with cameras so that you can record the exact interactions, in the hope of replaying the usage and hopefully acting to improve the design to support more effective usage.
There is nothing stopping you from taking an agile approach to usability testing at some points in your project and formal usability testing at other points. Nor is there anything stopping you from doing something in between.
6.3 Usage Testing
Usage scenario testing is a technique that can be used to test the logic captured within your design before you invest in implementing it. This is an inclusive technique which stakeholders can be actively involved with which can and should be performed in parallel with your modeling efforts to ensure that your model accurately reflects your business requirements. Using one ore more usage scenarios (a series of steps describing how someone works with your system) you walkthrough your class model and validate that it is able to support the scenario(s). If it does not, you update your model appropriately (or your code, as the case may be). Figure 5 (at bottom) presents usage scenario testing from the point of view of walking through a class model, although the same logic can also be followed to validate your user interface prototype (even if it is an abstract prototype).
7. A Call to Action
If the agile and UEX communities are going to work together effectively, they need to find a middle ground. I believe that middle ground exists, but that both communities need to adopt several changes in order to succeed. First, agile professionals must:
- Learn UEX skills. Developers should be trained in, and adopt into their practices, UEX techniques. This will enable developers to work more collaboratively and effectively with UEX practitioners.
- Accept that usability is a critical quality factor. Luckily, agile practitioners are “quality infected” – they understand the importance of doing high-quality work and have a proven track record of adopting techniques such as test-first programming, code refactoring, and database refactoring. Good usability of an end product can be ensured only by systematic usability engineering activities during the development cycles.
- Adopt UI and usage style guidelines. Developers must understand that not only should their code follow common guidelines, so should their UIs.
Similarly, UEX practitioners must make some changes. They need to:
- Go beyond UEX. I believe that many of the challenges experienced between programmers and UEX practitioners are due to overspecialization of roles and hand-offs between people in those roles. Agilists have mostly abandoning the concept of building teams of specialists and instead favor teams of generalizing specialists. The implication is that although UEX practitioners bring a critical skillset to a development team, they still need to learn a wider range of skills to become truly effective. Furthermore, agile practitioners have tightened the feedback loop on software projects, and thereby reduced both risk and cost, by increased collaboration which in turn results in decreased hand-offs.
- Become embedded in ASD teams. By embedding UEX practitioners on agile teams, not only will this increase the chance UEX issues are addressed, it will help to promote UEX skills within the agile community because people pick up new skills from one another as they collaborate.
- Give ASD approaches a chance. Kent Beck suggested to Alan Cooper that a week be invested at the beginning of a project to explore interaction issues, although Cooper believed that wasn’t sufficient. The easiest way to find out who is right is to actually try it in practice.
- Start looking beyond XP. I’ve said it before and I’ll say it again, there is more to ASD than XP. Agile methodologies are flexible, they’re not meant to be used “out of the box” but instead to be tailored to meet the exact situation which the project team finds itself in. To address UEX concerns you will very likely find that you need to tailor some of the principles and practices of Agile Modeling and/or the techniques of User-Centered Design into your base software process.
8. Potential Challenges
It is very easy to suggest that agile practitioners take the time to learn UEX skills, and to adopt appropriate guidelines, but the reality is that these skills are competing for attention along with other equally important skills such as database design and modeling. To make matters worse, few developer-oriented books cover UI/usability issues, and the few that do such as my own The Object Primer rarely seem to devote more than a chapter to it. I fear that many agile practitioners aren’t even aware of the issue.
Similarly, UEX practitioners receive mixed signals. Although I’m calling for them to become generalizing specialists, the industry still rewards specialization – UEX specialists are paid very well, and most organizations expect them to focus on doing that specific sort of work. Agile practitioners also suffer from this challenge: Why take an introductory UI design course when you can take a Java programming course which leads to certification and more pay?
It’s also easy to say that UEX professionals should be embedded into agile projects, but that only works when you have UEX professionals available. Few organizations have such people on staff, and worse yet believes that few organizations think in terms of interaction design as part of the requirements planning or project planning process. Therefore, many organizations may not see the need to hire anyone with these skills.
The lack of UI design ownership means that everyone wants to be involved with UI design, regardless of their skill level, which can lead to design by committee. Although a common philosophy throughout the agile community is that agile practitioners should have the humility to know their limits, and the respect of others with the appropriate skills to address a specific issue, it doesn’t always work out that way – apparently agile practitioners are still only human.
It is possible for UEX practitioners to make a valuable contribution on agile teams, and I suspect that there is a much greater chance of them succeeding as compared to working with traditional teams. Up until this point the UEX community has had little success in their attempts to become an active part of mainstream development teams, so it is time for a new approach. My suggestion is that UEX practitioners should work closely with the agile inmates to try to get the prison under reasonable control.
9. Acknowledgements
I’d like to acknowledge the input from Paul Oldfield and Tim Tuxworth on the Agile Modeling list which helped me to evolve this article.
Figure 2. The Agile Model Driven Development (AMDD) lifecycle.
Figure 3. A UI navigation model for a university system (hand drawn).
Figure 4. An abstract UI prototype created with paper.
Figure 5. The process of usage scenario testing (for a class model).
(End)
Comments made
Possible Related Articles:
Dave Roberts
Scott,
I appreciate your article(s). A very useful discussion of the problems involved. I’m going to recommend it to a few colleagues who are interested in this area.
Speaking as a former software developer who is now a UEX practitioner I can see how all the difficulties you mention might be overcome. The only difficulty I still have with this is the timetable issue. I wonder if you have come across any solutions in this are.
The problem comes when you have multiple users types involved in a project – several user roles. And when all of the people you might use for any user tests are busy people. To arrange for the right roles to be available at the right time becomes a problem. The UEX practitioner often has to work well ahead to ensure the users are available to participate – to get a slot in each person’s diary. However, most people I have spoken to about agile methods say that it is hard to predeict what functions will be available when. So matching up which users are available with the funtions that are needed to test their special use can be difficult – you don’t know what will be completed in 3 or 4 cycles from now.
Clearly this is not insurmountable. The user-based testing could lag behind the agile cycles so that users are not invited until function has been completed. But this then causes work on functions to have to skip over cycles.
Do you, or anyone else, have any comments on this issue?
Dave