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.
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.
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!
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.)
- 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.
