OK, I was tricky when talking about XP and usability in the last post. If you know anything about eXtreme Programming you should were thinking “this guy doesn’t know what is saying”. Whether what I said makes sense or not is what we’ll try to figure out in this post.
As mentioned, XP has short iterative cycles (named weekly cycles). Every cycle starts with a Planning Game, where the functionalities are discussed with the clients and put on cards (named User Stories). Through the week the team implements these user stories and shows the working code back to the user on the “Friday”. Obviously, two things must be noticed, first is that the user stories usually are a very small piece of the whole functionality expected from the system, and second is that the user can experiment with a minimum cost of time and money.
To some authors user-centered design is basically cooperative design processes, tests with users and iterative design. Lets look at each one of these more carefully:
Many design approaches assume that the designer has enough knowledge to play the role of the customer instead of her, applying general concepts developed and validated through researches. The designer thus decides which, after all, will be the best for the customer, characterizing the approach as being design for the user.
Cooperative design came against that, saying that the design must be done with the user, instead of for the user. So it comes to be essential that the user actively interact with the design process, experimenting mockups and prototypes, sharing its subjective point of view (mostly that which underlie conscious requirements, like desires, culture, ambitions, emotions, etc.) with the design team. The overall result of this process is more acceptance by the user, for they will be using a system pretty much adapted to their vision.
Tests with users
User-centered process relies onto tests made with the very users of the system. Although guide-lines and evaluation from usability specialists helps to find problems within the interface, much more would be found if the interface was tested by the users. Tests give valuable feedback about the system, not only through comments from the user, but through physiognomy and usability problems (e.g., difficulty to accomplish a task) as well.
Tests must be done overly through the process, giving input to the next design cycle. The sample users, the conduction of the test and the collect and the analysis of results should be chosen accordingly to the purpose of the test, such as understanding of the context, statistical validation, etc. In any cases, there are a lot of tools provided by usability researches that are very suitable for doing these tests.
Getting all that things together, the idea of iterative design brings to usability, the old known of software engineering: iterative cycles. UCD must be done in cycles that goes from Design, to Prototyping, to Tests and then to design again; and the process of designing interfaces for the system intrinsically has many iterative cycles, each one a little bit better than the previous.
So an astute reader would say that XP do all of this, and I say that yes, at least for some. Lets see how: during the Planning Game the user/customer actively interact with the team not only to gather functionalities but to design interfaces as well, then all the work is done to pass the acceptance tests (That can be an Usability Test as well) and finally everything is done small and iterative (Including the interaction design). But I can recognize 3 major issues related to the way which XP address these main points of UCD, and they are:
- REALLY iterative design
- Customer and user recognition
- Usability engineering tools
The first is easy to notice, usability process believes that it must be come before coding and in XP there aren’t something before coding. UCD uses prototyping (notedly, paper prototyping) to shortcut the delay between design and test. XP do the same, I mean get user feedback as soon as possible, coding less scope. We can see an intersection as we understand that prototyping could be switched to coding in small scale. There is still the need for prototyping, but it’s done among the coding process. Design must make sense in a week length cycle, and for so it occurs in small pieces (during Planning Game) and drives the implementation through out the iteration.
The XP literature may lead the more hasty to think that the guy who writes user stories is the employer of the development team, but he is not always the same as the user of the system. Maybe those who will pay for the system don’t know exactly what the end user needs (as we saw in the previous post, even the user don’t know sometimes), and distinction between the stakeholders must be done correctly, gathering the roles of all the people involved with the project.
Last, but not least, among with the common XP practices, should be introduced the Usability practices, adapted to its new context. It means that when doing the Planning Game, the team should try to model the user context and roles, and when doing Acceptance Tests, the team should look for task analysis and video recording.
All of these are addressed in the Whole Team XP practice. In eXtreme Programming Explained 2nd Edition, Kent Beck talks about the Interaction Designer role, giving some clues about how UCD could be done within XP. As a non-prescriptive “methodology” XP wouldn’t say how you should do UCD or what else, but have an underlying structure where this and much more can be smoothly integrated. The team should pay attention to what is relevant to add to its “methodology”, and follow the Values and Principles while doing this.
The next post will be about Whole Team and how would we put UCD and XP really together.