Second and last part of this article that addresses one of the main challenges facing User Experience professionals: how to convince our customers to work under a process of user-centered design instead of a waterfall methodology. Based on the same case proposed in the first part of this article here I describe where lies the greater efficiency of the UCD and why.
The user-centered design approach proposes an iterative process for interface development. Each iteration consists of three stages: analysis, elaboration and testing. A project may consist of n number of iterations depending on its complexity. In the center of this process are business representatives and users from whom we obtain and prioritize objectives for each iteration.
Unlike the waterfall development process where a single instance of analysis (at the beginning of the project) will feed the whole process (with the risks involved as we saw in the first part of this article) the UCD contains as many instances of analysis as iterations. At the beginning of each one of them, during the analysis phase, it is define the interface elements to be addressed and they are analyzed in detail.
In the analysis stage of successive iterations, it is possible to review what was found under the light of results obtained in the testing stage. Thus, it creates a virtuous circle of feedback where each assumption is developed, tested and refined.
The User-Centered Design in Action
Returning to our imaginary project for a mobile application that we have to develop in five weeks (see project assumptions in the first part of this article) we will define each iteration with a duration of two weeks, using one for the design phase and two iterations for the programming phase. The project would take the following form:
Unlike the waterfall approach, UCD includes measuring performance of the application during each iteration, tackling deviations and therefore reducing project risk. Test instances would be planned at the end of week two (end of design iteration) and then at the end of week three (end of first iteration of programming). However, given that between the first and second test would have only a week and the first test would already be testing some functional elements developed during the first week of programming, we could plan the second test at the end of the second iteration, that is to say in week five.
According to this plan U$S 6000 (U$S 4000 for the two weeks of design and U$S 2000 for the first week of programming) and only two weeks will be required to get a first measurement of the interface performance which is half what was required by the waterfall methodology in terms of budget and 60% less in terms of time.
Three weeks later would be possible to conduct a new round of tests with users before launching the product to the market. This would be the same instance for the waterfall methodology to conduct its own test but in this case it would be the first one.
The quantity of errors and the level of deviation that could be discovered in the second round of test (in the case of UCD) would respond to a maximum of three weeks, while in the case of the waterfall methodology would be five weeks, because no test was performed before.
It could be argued that the project plan we are using is not taking into account the time and cost required for testing and subsequent adjustments. But likewise, none of these things were contemplated in the case of the waterfall methodology, since it is required time and cost to perform the preliminary analysis and documentation that is normally generated in such cases.
The Risk in the Process of User-Centered Design
Let's see what happens with risk. The two variables we choose to measure risk are, as in the case of the cascade methodology:- Requirements Specification: the requirements definition for the UCD is performed during the first stage of the iteration and is focused in the items that will be developed during that particular iteration. Each iteration has its stage of analysis and since the iterations are successive, the information that feeds each iteration is every time more precise and accurate as it has gone through a validation process during the previous testing stage.
- Development time: the time needed to do a measurement of performance and, therefore, to identify potential problems and correct them could be done in the second week of the project, leaving three weeks ahead to make adjustments before launching the application.
The image depicts how the risk is reduced in instances of user testing, where the assumptions considered in the analysis stage and development process are tested and, if necessary, adjusted.
This prevents that the risk curve grow upward in a straight line from project inception to completion. Instead, it does so in a spasmodic way in each iteration, falling dramatically during test instances.
Waterfall Methodology Vs. User-Centered Design in Brief
- Cost: user-centered design process is on average 35% more efficient than the waterfall methodology due to a better requirements definition and better control on deviations.
- Time: UCD allows project development without or reduced deviations. In the case of the waterfall methodology time deviation can reach 35% on average.
- Risk: user testing is an effective risk reducer. Implementing tests during iterations prevents that the risk exceeds the investment required for each iteration (usually two weeks). In our example, the risk was halved in relation with the risk manifested using a waterfall methodology.
- Measuring performance: UCD requires half the budget that the waterfall methodology to perform a first measurement of performance, which is critical to prevent that the project risk grows as a linear progression.
Surely this comparative analysis is not complete but the goal of this article is just trying to make a simple analysis looking at the main project variables (scope, time, budget and risk) providing basic arguments that show the advantages of working with a user-centered design process.
