Why User-Centered Design is more efficient than waterfall development methodologies. (Part 1/2).

One of the main challenges user experience professionals face is how to convince our customers to work under a process of user-centered design instead of the traditional waterfall methodology. In this article I propose a simple comparative exercise to analyze the economic efficiency of one process and the other.

 

Assumptions 

Suppose we receive a request to develop a mobile application in five weeks. According to the preliminary analysis we have done the project will require two weeks of design that will feed four more weeks of development. The second week of design will overlap with the first development week so the project will last five weeks as requested by our imaginary customer.

The cost of each hour of a designer and a programmer is U$S50 (fifty american dollars) each one of them, so the total project cost could be estimated as follows:

• Design Tasks: 80 (hours) x 50 (dollars) = U$S 4000 .- (four thousand dollars) 
• Programming Tasks: 160 (hours) x 50 (dollars) = U$S 8000 .- (eight thousand dollars) 
• PROJECT TOTAL: U$S12.000 (twelve thousand dollars) 

Risk Estimation 

The risk can be estimated in many ways. For the purposes of this exercise was calculated from two variables:

• Risk = accurate requirements definition x development time 

Considering that inaccurate requirements and longer development time result in higher risk.

Waterfall Development Process 

A waterfall development process consists of a series of consecutive stages of work (in this case design and development) until the completion of the project which ends with the delivery of the application according to the requirements defined at the beginning of the project. If we have to draw it in a simple way It will consist of three stages: 

This methodology does not contemplate the possibility of measuring the performance of the application until the end of the project. It is in part because just at that time there will be a deliverable that can be measured and in part because waterfall methodology considers no necessary to measure the performance of a product before the launch of it. In any case, the results may then be estimated by measuring the product performance in the real market once it was launched.

With this in mind we can say that a cascade process for this project would require an investment of U$S12.000 dollars and five weeks of development to know how the application performs. 

The Risk in a Waterfall Development Process

When we add the risk component, previous estimation in terms of time and costs changes substantially. Let's see what happens with the two variables in our analysis that compound risk:   

• Requirements specification: the requirements definitions made ​​before starting a project and not revised later as development progresses contain a number of assumptions that make them inaccurate and sometimes directly wrong. In this regard, Jason Fried and David Heinemeier Hansson quite rightly raised this issue in their book Rework. They pointed out that the moment in which a development team knows less about how to solve a given problem is just before start to solving it. However in a waterfall process is that precise moment when all requirements are defined and after that they will guide the entire development process leveraging risk of deviations because of defective product requirements definition. 
• Development time: The elapsed time to measure the performance of the application and, therefore, to identify potential problems and made adjustments would be during the fifth week of the project, that is in the end, having already consumed all budgeted hours of design and development. 

Considering these two factors, the risk of deviation in a waterfall development process is high. In fact, a recent study by IAG Consulting says that companies defined as immature in requirements definition fail half of the times to reach goals set for an application and require 35% more time and budget to achieve them.

Returning to our example, if the application is under the expected performance (which has 50% possibilities of be the case) the project will require 35% more development time and budget to make the necessary adjustments in order to be successful. This would carry the total investment to US$16.200 dollars and nearly seven weeks rather than the five originally estimated.

This whole process could be drawn like this: 

Now we see the difference between the initial estimates and what really happen as a result of increased risk during the development process as a consequence of decisions taken based on poorly defined requirements.

In the second part of this article we describe how the User-Centered Design avoids these deviations, reduces risk, time and development costs.

Five things you should consider when testing with children.

In one of the last projects I worked on I had the opportunity to conduct usability testing with children between 6 and 12 years old. In this article I present five things you should consider when working with children.  

1. Neutralize preconditions. 

The conditions or biases that children bring to the testing sessions tend to come from two main sources: from their own ability to fantasize and from their parents’ influence. The former is a normal behavior for certain ages, especially for children between 6 and 12. With regard to parents, we must have in mind that they are usually the ones who tell the children what they will be doing during the test and while doing this they might build up expectations or distort the concept of a usability test. 

In order to prevent these I often ask users at the beginning of the test, what they had been told about what they will be doing during the session. Then I tell them my story and try to neutralize the distortions and focus the user on what really matters.      

2. Avoid the word "test".

When explaining to children what they will be doing and what is expected of them during the session you should avoid using the word "test" because it has a very specific meaning for school-aged children. They might relate this with an instance in which they are being evaluated.

To avoid this, we must communicate explicitly that the goal is to help us discover those things we can improve, that their opinion is very important to us and there is no right or wrong answer. We are testing the interface not the users.   

3. Start the routine tests with questions that help to build rapport.

While it is also a good practice when testing with adults, in the case of children, generating empathy is critical. Kids can take more time until they build trust with you, which is needed so that the technique of "thinking aloud" yields its full potential.

To accomplish this you can ask general questions like: what grade they are in, what classes they like and dislike in school, what they do in their spare time or what sports they like the most. Questions should change and should be adjusted according to the child’s age and answers. The goal is to forget for a few minutes that we're doing a usability test and just have a nice chat with them. 

4. Adapt the furniture to the physical conditions of children.

Something that seems a minor detail and is often disregarded is having chairs and tables suitable for children. This has the purpose of making them feel comfortable while using the mouse, keyboard and viewing the entire screen.

This is usually resolved with a good adjustable chairs with armrests.

5. Snacks for breaking the ice.

It is strange to imagine a group of happy children running through the halls of an office or playing at an oval table in a meeting room. Offices are clearly not meant for kids .They are very formal, monochromatic and, in some cases, cold. If tests are performed in a usability lab with mirrors and video cameras, the feeling of being watched can generate even greater self-consciousness.

     

In order to create a friendlier environment for children you can decorate the room with toys, posters and offer snacks. This last item has a special power to get a smile out of children and to break the ice.

How to overcome resistance to the implementation of User-Centered Design.

Incorporating usability techniques and processes of User-Centered Design (UCD) in companies that are not used to working with them can become a daunting task. Over and over again we hear arguments that justify the rejection and invalidate the possibility of change, even if this is minimal. This article describes the most common arguments we hear, and proposes concrete actions to refute the negatives.

Common barriers and excuses to implementing UCD

Over the past ten years, I have had the opportunity to work for companies of different markets and I find that the difficulties and barriers to implementing UCD are quite similar, regardless of the type of company or sector in which they operate.

However, the problems are different depending on the degree of maturity of each company in relation to usability and user-centered design. Taking the maturity model developed by Keikendo (link in Spanish), an IT and UX training company, it is possible to address barriers and common excuses that the design and development teams typically use, and present each one of them with arguments and concrete actions that neutralize them:

Stage of maturity	Common barriers and excuses	Arguments and courses of action
1. Unintentional User experience is not designed intentionally.	Ignorance: Usability and UX discipline is unknown.	Training.
	Rejection: Experience design is considered unnecessary.	Do nothing. They will discover the UX value on their own.
	Incompatibility: The methodology does not allow user testing.	Do usability testing with the finished product to expose the problems.
2. Self-reference Interface is designed as if users were members of the design and development team.	Cost constraints.	With 10% of the total budget of a project you can achieve an 83% improvement.
	Time constraints.	A round of user testing can be completed in one week.
	Lack of specialized resources.	Outsourcing, hire new resources or train existing ones.
3. Expert Based on the experience of one person. There is no method.	No formalized methodology.	Design and implement a feasible methodology, not an ideal one.
	Perception of uncertainty on results.	Quantitative and qualitative assessments during the test.
4. Centralized There is person in charge of experience design. There is a method.	Usability and user experience is required for certain projects, not for all of them.	Use metrics from projects based on UCD and compare them with projects that used other methodologies.
5. Distributed All teams are aware of usability and UCD. There is a method.	Resistance from senior management.	ROI is the keyword: Take metrics and show how the UCD boosts ROI.

Table: The five maturity levels, the barriers and the actions to take.

Specific arguments and courses of action to fight resistance:

Training : Some of the actions you can take when your client doesn’t know anything about usability and user-centered design are providing introductory courses, invite them to professional meetings or even explain the main concepts at informal meetings.

Choose your battles: The arguments heard rejecting UCD range from “boring” to “not necessary”. Whatever the case, it is not worth spending too much time convincing naysayers. The impact of UCD on business, the final quality achieved for a given product, and improvements in customer satisfaction are explicit benefits. Being against UCD is based mainly on dogma than reason.

User testing: In addition to being one of the main techniques of UCD, user testing is a powerful realization tool. It is important to involve design and development team members, and even invite managers and stakeholders to the usability sessions.  Watching and listening to users has a magical effect on those who continue to oppose to this methodology.

Comparing costs: In order to dissolve the excuse about costs, just demonstrate what the cost of not using a user-centered design methodology would be. The UCD is more efficient than other methods and reduces costs in development, maintenance, training, and support.

Prioritizing with time constraints: UCD allows for prioritization initiatives.  When time is short it is very important to decide which tasks should be carried out within the time available to obtain the best possible results. A round of user testing with just five users allows identifying most of the usability problems of any interface and can be done in one week. At the end of just one round, valuable information is gathered to support future design and development decisions.

Relying on experts: If the project is important for the company don’t hesitate to hire a consultant o a UX agency. In addition to solving the problem, the company can learn from them during the process.

Remove barriers related to the methodology: The process of UCD is not dogmatic.  In fact, it is considered one of the so-called agile methodologies, defined as a process rather than a structured methodology. This allows greater flexibility and adaptability to the requirements of each specific project.

Reducing uncertainty: The best way to generate certainty and reduce resistance to the adoption of user-centered design is to show quantitative and qualitative results from using this method. This involves measuring key variables of each project. The three most common variables are: effectiveness, efficiency and user satisfaction.

Break the resistance of stakeholders: From a business perspective it is more convincing to use metrics that feed into the traditional equation of a successful Web site: I = V x C x R, where:

• I: Income
  V: Number of unique visitors
  C: Conversion rate
  R: Return rate