Triangulation: Navigating the Stormy Seas of Project Requirements

May 21, 2012

I often reflect on how privileged I am to be in the field of user experience, because we always have the trump card: the user. Let me explain. As UX professionals, we generally have an abundant breadth of experience across different industries and businesses. Our clients, on the other hand, have great depth of knowledge in their own domain. However, only users themselves can intimately appreciate their own needs, and user experience is the only field that considers the user’s perspective at every stage of a project.

Why is this such an awesome novelty?

Champion Advertisement
Continue Reading…

The Triangulation Principle

There is a social science research approach called triangulation, which is “the combination of multiple perspectives in the study of the same phenomenon.” [1] Social science borrowed the triangulation metaphor from navigation systems that, given basic principles of geometry, use multiple reference points to locate an object’s exact position. [2]

By combining multiple perspectives, social science researchers hope to overcome the limitations and intrinsic biases of any one perspective and thereby obtain confirmation of their findings. They consider the point at which the different perspectives converge to represent reality. [3] Some argue that triangulation thus not only validates, but actually deepens and broadens our understanding of reality. [4]

Similarly, within the context of a UX project, we can triangulate the perspectives of the UX professional, the client, and the user, as shown in Figure 1, to filter out the limitations and intrinsic biases of any single perspective and thereby obtain objectively true project outcomes.

Figure 1—Triangulating three perspectives on a UX project
Triangulating three perspectives on a UX project

Triangulation on UX Projects

UX projects generally have three distinct phases: definition, design, and delivery, as follows:

  • definition phase—The purpose of the definition phase is to determine the vision and scope for the project. We do this by answering the questions: what are we trying to achieve, and how far can we go in trying to achieve it? This usually involves articulating the project’s mission statement, then deriving a set of project requirements that we anticipate will collectively achieve the mission.
  • design phase—The purpose of the design phase is to imagine what a solution that meets the requirements and thereby achieves the vision might look like. In practice, we typically accomplish this work by creating sketches, wireframes, or prototypes that depict the expected functionality and interactions of the imagined solution.
  • delivery phase—Finally, the purpose of the delivery phase is to produce the form and function of the working product. The product must implement the needed functionality and interactions to actually meet the requirements and thereby achieve the mission. For digital projects, the deliverables could be anything from a series of mockups to fully developed code and databases.

Figure 2 provides an overview of the three phases that are typically part of a UX project: definition, design, and delivery.

Figure 2—Overview of the three typical phases of a UX project
Overview of the three typical phases of a UX project

In the early days of the UX industry, it was often necessary to explain to our clients that, for every dollar you invest in solving challenges during the design phase, which is relatively flat and fluid, you would likely save ten dollars—the cost of rectifying the resulting issues during the project’s delivery phase, which is more layered and rigid.

Arguably, we could apply that same type of reasoning to project requirements—thus, for every dollar you invest in filtering out any subjective limitations and biases from requirements, which are still in the realm of ideas, you would likely save ten dollars—the cost of solving the challenges that would have resulted—during the design phase and, in turn, one hundred dollars—the cost of rectifying the resulting issues during the delivery phase. It’s like trying to influence the growth of a tree when it’s a small sapling, like that shown in Figure 3, versus a two-foot tall, flexible young tree versus a fully grown, twenty-foot tall tree with a massive hardwood trunk!

Figure 3—A young sapling
A young sapling

Applying the triangulation principle can be equally useful at each project phase: helping to filter requirements limitations and biases, solving design problems, and rectifying delivery issues. In this article, I’ll focus on the application of this principle during the definition phase of a project, in the hope that making improvements at this stage would naturally make the design and delivery phases go more smoothly.

Objective Requirements

The initial spark for a UX project can come from a number of sources—for example, a client stakeholder who has had a big idea or market research that suggests there is a customer need that is not being fulfilled. Clients often simply extrapolate project requirements from their initial idea, thereby incorporating only one perspective—the client’s—in the requirements.

Clients who have come to value a second, divergent perspective might bring in a business analyst or consultant to help them further refine the requirements from two perspectives. However, according to the triangulation principle, this method of requirements validation still lacks a confirmation, which you can achieve only when you solicit and reconcile three or more perspectives. The risk of not confirming project requirements by considering a third perspective is that some subjective limitations or intrinsic biases of either the client or the consultant could entangle the requirements, which would then adversely affect the design and possibly delivery phases in increasingly significant ways, as I described earlier.

A methodical way of identifying requirements impurities such as subjective limitations and intrinsic biases is to test each requirement against an accepted standard. One such standard suggests that a good requirement has the characteristics of being

  • understandable—A requirement is understandable if it is clear, concise, and unambiguous—that is, it states what the solution must do in a simple, straightforward way, with just enough detail to leave no room for misinterpretation.
  • verifiable—A requirement is verifiable only if you can ultimately inspect, test, or demonstrate the final solution to confirm that it meets the requirement.
  • achievable—You can consider a requirement attainable only if, after investigation, you believe that your organization can build it within the budget, timeline, and technical limitations of the project.

If any of these three characteristics is not present, you can assume that there is some subjective limitation or bias that has obscured the objectively true requirement. [5]

Perspectives on Requirements

In theory, once you’ve gathered and compared two or more perspectives on what a project’s requirements should be, each identified requirement should fall into one of three categories: conflicting, disjointed, or convergent, as shown in Figure 4. To illustrate each of these categories of requirements, I’ll provide some examples. (For simplicity, in my examples, I’ve assumed that you would solicit each of three perspectives in order—starting with the client, continuing with users, and concluding with a UX professional. Of course, in actual practice, it could happen in any order.)

Figure 4—Conflicting, disjointed, and convergent requirements
Conflicting, disjointed, and convergent requirements
  • conflicting requirements—These requirements are seemingly mutually exclusive. Therefore, it is not possible to meet all of them simultaneously. A UX professional might look at two requirements side by side and reflect, If we design for this one, we certainly won’t be able to design for that one. A client may say “white,” while users say “black,” when talking about the very same functionality. Here is an example of conflicting requirements: a client might want to receive payment from users before confirming their bookings, while users might want confirmation of their bookings before they are willing to pay anything for them.
  • disjointed requirements—These requirements might seem to be unrelated on the surface, but if we were to try to address them independently, there would be an uncomfortable competition between them. A UX professional would likely look at two such requirements side by side and reflect, If we design for this one and for that one, how can we reconcile them? A client may say “grey over here,” while users say “grey over there,” when talking about the very same functionality. Here is an example of disjointed requirements: a client might want users to type their available time slots, while users might want to see available time slots from which they can select the time slot they want.
  • convergent requirements—These requirements ask for the same thing from the same functionality. A UX professional would instantly understand how to design a solution that addresses both perspectives simultaneously. Here both the client and users concur and say “grey over here.” Here is an example of convergent requirements: a client might want to track the progress of an order, while users want to have status updates on their order.

Requirement Distillation

According to the triangulation principle, the key to distilling objectively true requirements is to bring in a third perspective to systematically work through any points that are either in conflict or disjointed to find ways of bringing them into convergence. This process provides a means by which to filter out any subjective limitations and biases.

Taking my earlier example of conflicting requirements, the client presumably wants to make sure that they get paid for every booking rather than possibly making a booking for someone who doesn’t pay, then drops the booking. Meanwhile, users simply don’t feel comfortable giving over any money until they’re confident that the company will reserve a booking for them. In this case, a UX professional might say, “Why don’t we confirm a tentative booking before asking users for payment? If a user chooses not to pay, we’ll release the booking, but if they follow through and make payment, we’ll guarantee the booking.”

Looking again at my example of disjointed requirements, a client might feel that it’s easier to find an available time slot after a user has told them their constraints. Meanwhile, a user might feel that it’s easier to see their options, then simply select one. In this case, a UX professional might say, “Why don’t we offer both options, asking users to provide their available time slots by default. This way, we could encourage users to make it easier for the client, but give them the other option should they want it.”

That’s it for the theory. Now, let’s take a look at a real-life case study in detail.

Triangulation in Action

Stamford Interactive was conducting a series of workshops with business stakeholders to gather the requirements for a transactional Web site that would support tradespeople. During one of the workshops, the client stated that they wanted to base the payment process on 48-hour payment terms. The UX professional on the project understood that there could be issues with this requirement, such as

  • the fidelity with which it would be possible to measure the time lapse between the moment a customer became obligated to pay and the time when they actually made payment
  • the existence of a de-facto standard of 30-day payment terms in most industries

The client, however, insisted that they didn’t want to continue having to wait for payments from their customers, so wanted to take the opportunity of building this new site to change their payment terms. They believed that, if they asked for payment within 48-hours, they could hope to actually get paid within 7 days, which is what they truly wanted.

Stamford tested the requirements with a number of potential customers to gain insights into their perspective and gauge the target market’s willingness to embrace the proposed business innovations. They did this using a semi-open, one-on-one interview format, in which they walked participants through the imagined new process, asking for their thoughts on various aspects of it along the way. When discussing the proposition of 48-hour payment terms, participants’ unanimous and resounding response was “No way.” On the other hand, for the sake of comparison, when Stamford asked participants whether they would accept 7-day payment terms, their responses were: “I would expect 30 days, but would accept 14.” “If they said 7, I would just pay when I’m ready.” “I think 14 is a nice compromise.” “I don’t believe anyone gets paid in 7 days, so I'd pay in 14 anyway.”

During a follow-up workshop to review the research data with the client, Stamford contemplated the three-way tension around the issue of payment terms: The UX professional knew that 48 hours was impractical; and 30 days, quite common across industries. The customers thought 7 days was asking too much, but 14 days would be reasonable. The client actually wanted to be paid in 7 days. In the end, they came up with an awesome idea for reconciling these divergent points of view: Make 14 days the official payment terms, but give a discount to customers who pay within 7 days. Miraculously, they found a solution that satisfied all three perspectives equally. Once the client had agreed that they wanted to run with this proposal, the context within which Stamford would need to design the payment portal became clear and tangible.

Now that you’ve seen a real-life case study, perhaps you’re wondering where to begin applying the triangulation principle to your own projects.

How to Use Triangulation

First and foremost, when applying the triangulation principle to requirements, you must create an opportunity to validate the requirements. The need to do this may exist in either of two contexts:

  • A client may already have drafted requirements before bringing a UX professional on board.
  • A client may not yet have defined requirements when a UX professional joins the project.

In the case where a client has already drafted the requirements, the UX professional might tell the project owner that their first exercise when starting the engagement would be to validate the requirements. This would consist of reviewing the draft requirements and analyzing them for understandability, verifiability, and achievability, then creating a list of suspected requirements impurities. Next, a meeting or workshop with the client would take place to work through the list of issues—hopefully, reconciling any conflicts and disjoints by bringing the UX professional’s perspective to bear. But also being prepared to agree to test the solutions with users—thus adding the third perspective—to resolve any particular points that are not easily reconcilable.

The UX professional would then engage users through workshops, focus groups, or interviews to determine whether the users considered the refined requirements to be useful, valuable, and complete. If there were any conflicts or disjoints between users’ needs and the refined requirements, the UX professional would need to reconcile them through another session with the client, then possibly engage with users again. Thus the requirements would go through as many rounds of refinement and validation as necessary for the size and complexity of the project, ideally until the process had filtered out all suspected impurities.

In the case where the client had not yet drafted the requirements, the UX professional would ask to be involved in requirements gathering and analysis to ensure that the project considers the users’ perspective early on—perhaps using the analogy of the development of a tree to explain the request. The UX professional would then proceed with conducting the usual user research activities—from focus groups to contextual inquiries, with either the client stakeholders and/or users—to identify the first perspective on what the requirements for the project should be. The UX professional would then follow the process I outlined earlier: analyze for impurities, hold a workshop to filter out as many impurities as possible, then engage the third perspective of the users to reconcile any remaining conflicts or disjoints.

In either case, the final set of project requirements should ideally be understandable, verifiable, and achievable, and three different sets of people should have agreed upon them. Thus, all parties could be confident that the UX professional would have the requirements necessary to design an objectively true solution.

This process naturally filters out any subjective limitations and biases, but what if there’s a stakeholder who insists?

Calming Stormy Seas

Reflecting again on triangulation as applied to social science research—“by combining multiple perspectives, social science researchers hope to overcome the limitations or intrinsic biases of any one perspective, and thereby obtain a confirmation of findings”—it seems that there are two distinct sources for requirements impurities. First, there are subjective limitations in a person’s perspective. We can easily understand this in the case of either highly specialized or inexperienced people, but this really applies to anyone. Second, there are a person’s intrinsic biases—or, in other words, ulterior motives such as fear, greed, and the like. Appreciating this distinction helps greatly when approaching the reconciliation of divergent perspectives.

In the case where a requirements impurity was introduced by a simple subjective limitation in a person’s perspective, the advice is to be patient and humble, trusting that the process will do the work for you. Even if a client disagrees with you, how can the client argue that they know better what users need than the users themselves or users argue that they know better what the client should offer than the client themselves? It’s just a matter of time before everything comes out in the wash, so to speak.

In the case where a requirements impurity was introduced because of someone’s ulterior motive—which, by definition, a person does not want to reveal—sometimes people will actually dig in their heels. We usually discover these types of impurities when people do not respond well to the rational argument that they couldn’t possibly know everything the other party knows. So, even if people hold their ground in the face of differing opinions and simple logic, don’t give up! You can still reconcile the perspectives—and avoid being charged with an impossible design task. But doing this requires something greater than you, the client, and the users. It requires purpose.

Does a proposed requirement clearly contribute to your achieving the project’s overarching mission? No matter who put a requirement forward, if it doesn’t contribute to achieving the vision, it should be challenged. How can anyone hold onto an idea that clearly doesn’t have any purpose? (This is another reason why it is so important to clearly articulate the project’s mission statement at the outset of the definition phase.)

A UX professional’s challenge at this point comes down to soft skills. He needs to listen attentively and try to understand where people are truly coming from—go beneath the surface and find out what they really want—then choose his own words carefully to gently and consistently refocus an insistent person on the project’s vision. Eventually, this approach will guide people to let go of their ulterior motives, because the pursuit of a greater purpose has the ability to lift individuals beyond their own personal, limited perspective into a place of true collaboration.

Thus, through a combination of applying the triangulation principle and using soft skills, we can ensure that we emerge from the project definition phase with clear, objectively true project requirements from which to begin the exciting journey of delivering great user experiences.

Triangulation Checklist

Want to give triangulation a go? Here’s your triangulation checklist:

  • Create an opportunity to validate the requirements.
  • Gather requirements from one perspective—unless they’ve already been drafted.
  • Analyze the requirements for understandably, verifiability, and achievability.
  • Create a list of suspected subjective limitations and biases.
  • Hold a workshop to reconcile conflicts and disjoints by adding your own perspective.
  • Test the refined requirements by applying a third perspective—that of users.
  • Hold a workshop to reconcile conflicts and disjoints through that third perspective.
  • Be patient and humble, listen, and gently and consistently refocus people on the vision.
  • Repeat this process as necessary, until the requirements are truly objective. 


[1] Bailey-Beckett, Sharon, and Gayle Turner. “Triangulation: How and Why Triangulated Research Can Help Grow Market Share and Profitability.”PDF Beckett Advisors Inc., May 2001.

[2] Jick, Todd D. “Mixing Qualitative and Quantitative Methods: Triangulation in Action.” Administrative Science Quarterly, Johnson Graduate School of Management, Cornell University, December 1979.

[3] Jakob, Alexander. “On the Triangulation of Quantitative and Qualitative Data in Typological Social Research.” Forum: Qualitative Social Research, February 2001.

[4] Olsen, Wendy. “Triangulation in Social Research: Qualitative and Quantitative Methods Can Really Be Mixed.”PDF From Development in Sociology. Manchester: Causeway Press, 2004.

[5] Egeland, Brad. “Gathering Good Requirements.” SmartSheet, April 2012.

Experience Design Manager at The Customer Experience Company

Melbourne, Victoria, Australia

Tal BloomTal has been working in the digital and consulting spaces since 2001, in roles such as Experience Designer, Information Architect, and Business Analyst. He has a passion for designing elegant solutions to complex business problems. With unwavering ethical integrity and purpose as his guiding light, he has consistently helped the people and the businesses with whom he engages to embrace change and grow in healthy and sustainable ways. He believes deeply in the human-centered approach to design, finds working with empathy meaningful, and cherishes seeing his peers and clients happy. Tal holds a Bachelor of Engineering (Electrical, First Class Honours) from N.S.W. University.  Read More

Other Articles on Requirements Definition

New on UXmatters