The second and last part of this article addresses one of the main challenges that User Experience professionals face: how to convince our customers to work under a process of user-centered design (UCD) instead of a waterfall methodology. Based on the same case proposed in the first part of this article I describe where the greater efficiency of the UCD lies 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 the 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 each iteration, during the analysis phase, we define the interface elements to be addressed and they are then analyzed in detail.
In the analysis stage of successive iterations, it is possible to review what was found from the results obtained in the testing stage. Thus, it provides constant 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 iteration 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 for 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 there would only be a week between the first and second test, and the first one 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 $6,000 ($4,000 for the two weeks of design and $2,000 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 of what was required with the waterfall methodology in terms of budget, and 60% less in terms of time.
After three weeks it would be possible to conduct a second round of tests with users before launching the product to the market. With the waterfall methodology this would be the first round.
The quantity of errors and the level of deviation that could be discovered in the second round of tests (in the case of UCD) would arise at most after three weeks, while in the case of the waterfall methodology they would only show up after five weeks, because no test was performed before then.
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 time and cost to perform the preliminary analysis and documentation that is normally generated in such cases is required.
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 on the items that will be developed during that particular iteration. Each iteration has a stage of analysis and since the iterations are successive, the information that feeds each iteration is more precise and accurate every time as it has gone through a validation process during the previous testing stage.
- Development time: Measurements of performance and identification and correction of potential problems could be done in the second week of the project, leaving three weeks ahead to make adjustments before launching the application.
Given these variables, we could draw the risk behavior during the project as follows:
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 in a straight line from project inception to completion. Instead, it does so in an irregular way in each iteration, falling dramatically during each test instance.
Waterfall methodology vs user-centered design in brief
- Cost: a user-centered design process is on average 35% more efficient than the waterfall methodology due to better requirements definition and better control of deviations.
- Time: UCD allows project development with reduced or no deviations. In the case of the waterfall methodology time deviation can reach up to 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 to the risk manifested using a waterfall methodology.
- Measuring performance: UCD requires half the budget than the waterfall methodology to perform a first measurement of performance, which is critical to prevent that project risk growth in a linear progression.
Surely, this comparative analysis is not complete but the goal of this article is 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.