Have you ever noticed that when teams talk about prototypes, the terminology seems to be different from project to project, and person to person? There doesn’t seem to be a common, useful vocabulary or model for talking about prototypes. This can be a problem. However, this problem can easily be resolved by using a trifecta.
The word trifecta is a late 20th century term originating from horse racing. The word trifecta is formed from a blend of the morpheme tri- (‘three’), the noun perfecta, and still seems to be largely confined to horse racing and other gambling contexts.
A trifecta is commonly known as:
- a bet in which the first, second, and third place winners are picked in the correct order
- a situation having three major achievements in a profession, sport, or other pastime
Trifecta, as it pertains to the health industry, is often used to describe the three goals of healthcare insurance… those being affordability, availability, and quality. I once listened to a presentation at the West Virginia University School of Public Health about the Affordable Care Act (ACA), and how it was trying to achieve a balance between those three goals (or metrics):
As everyone commonly knows, the ACA is by no means perfect. This is due to the balancing of the different metrics in the trifecta. Using the health insurance trifecta example (like the ACA), as quality increases, affordability would potentially decrease. Also, you may have great quality and affordability, but a patient would need to drive to a different state because there is no availability. This is commonly shown in the format of a net chart as seen above.
So in the healthcare insurance example, it’s almost impossible to have all of these three metrics available and in an ideal state with any given healthcare insurance – at least not at the beginning of a plan – but the goal would be to improve to that state over time.
A lot of industries, products, and services with many user touch points have trifectas. I know for certain that I see a similar trifecta a lot of times with digital products in the software industry. Specifically as it pertains to User Experience (UX), when people are talking about prototypes, there seems to be a misunderstanding of terminology, the metrics, and how the trifectas work.
For example, in the last 10 years working with digital product lifecycles, I have heard the following terms used interchangeably:
- Interactive Wireframes
- Interactive Mockups
- Prototype
- Minimum Viable Product (MVP)
- Mockups
- Wireframes
- Proof of Concept
- Minimum Viable Experience (MVE)
- Interactive Prototype
- High-Fidelity Mockups
So on, and so on, and so on… to the point of, and to such a degree, that I wonder how the terminology got so convoluted in the first place. It seems obvious that three aspects (or metrics) that people are trying to describe with the above terms are fidelity, interactivity, and operability. So why can’t we apply a trifecta to prototypes, and just speak in those terms?
The answer is, we can! So, let’s define those metrics more succinctly as it pertains to digital products or software:
Fidelity – the degree of accuracy and quality with which the user interface (UI) is produced
Interactivity – the ability to interact with a human user to obtain and give information
Operability – the data and technology capability of being put into use, operation, or practice
Ideally speaking, the goal of a prototype is not that of a finished product wherein the fidelity, interactivity, and operability are all three stellar (and off the chart). Absolutely not. That would be more along the lines of a finished product. This is a prototype, and as such should be constructed according to deadlines. You need to know what’s important to get in front of users, what’s important to show stakeholders, what do we need to demonstrate data/technology-wise… ultimately, what trifecta are we targeting?
So, just like the healthcare example above, as a prototype moves more towards fidelity – meaning that the design of the UI looks polished with the brand colors, fonts, and iconography of a final product – interactivity or operability will have to give a little (see Example 1).
Likewise, if we are trying to prove that we can create, update, read, or delete (CRUD) data dynamically from an external system, we aren’t going to be able to deliver a polished final look (see Example 2).
Too many times have I seen coworkers in Product Management (PM) confuse these terms, and without fail it leads to another meeting and conversation about what they meant. Wanting all three of these metrics in a prototype, and not being specific about the prototype trifecta, can cause problems down the road. It can lead to a lack of understanding within the team, not aligning on deliverables which causes more meetings and rushed work, or in some cases increases the potential of putting something bad in front of a stakeholder or user.
It would be easier to take a minute to align on the metrics, and just use the prototype trifecta. In the long run this will save you time, and if a PM just said, “hey… make it a low-fidelity interactive prototype, and we don’t need to worry about operability at this point,” isn’t that easier to understand?