How and when to use a Proof of Concept

Since I started working in UX/UI Design in 2015, stakeholders have frequently employed the Proof of Concept methodology, prompting me to research the subject. According to Wikipedia:

"Also known as proof of principle, it is a realization of a particular method or idea to demonstrate its feasibility, or a demonstration of principle intended to verify whether a concept or theory has practical potential. A proof of concept is usually small and may or may not be complete. These collaborative tests aim to evaluate the feasibility of business concepts and proposals to solve problems and accelerate business innovation goals."

With this clarified, let's move forward…

💡 Some ideas are so elaborate that sometimes we need to show HOW to solve them, skipping directly to the delivery stage. In such cases, we might also test with a more selected audience aiming to clarify assumptions and doubts from the initial idea. This rarely happens, but let's assume it does…

What is it really used for?

Let's suppose you have an idea for an app... By talking with friends and family, you've realized your initial idea is genuinely very good, and you believe in it. You conduct brief or extensive research on the subject, or sometimes you already have experience in a specific field.

Believing in this idea, you understand it would be better to invest less time and resources initially to test your concept before committing substantial resources to a "full project," right? Well, this is precisely where the POC (Proof of Concept) comes into play.

Validating ideas

The importance of learning through testing is as crucial as learning from others' mistakes. I had to learn about the significance of this methodology to conclude that the most important aspect is:

Therefore, we can clearly see that developing a solution isn't something simple or cheap, but we do have a low-risk option available.

Proof of Concept and Discovery

I always recommend starting with Discovery, the initial research that lays the foundation for the entire business. To me, it has inherent value and clearly defines the purpose of the product. I consistently use it to gain an understanding of objectives and to perform technical, business, and UX reviews even before designing, developing, and investing in any project.

But as experience designers, we must adapt to what the market and users need at a given moment—or even teach them what they need. To do this effectively, we must research, test, adjust, and, in some cases, launch quickly.