A Potemkin Village is a product that looks considerably more impressive from the outside than it does once you try to walk through the front door.

In UX and product development, a Potemkin Village is a carefully constructed façade that creates the impression of a complete, successful, or functional product while hiding how little actually exists behind it. Sometimes this is perfectly legitimate prototyping. Sometimes it’s theater with a sprint number.

The difference is whether everyone knows they’re looking at something real or merely scenery.

ORIGIN

The expression Potemkin Village comes from a famous story involving Russian statesman Grigory Potemkin and Empress Catherine II. During Catherine’s journey through newly acquired southern territories and Crimea in 1787, Potemkin was accused of constructing elaborate fake settlements along her route. According to the legend, attractive façades and supposedly prosperous villages were erected to convince Catherine and her foreign guests that the region was thriving under his administration.

The story became even more spectacular over time. Some versions claimed the same portable villages were dismantled after Catherine passed and rebuilt farther down the river, complete with conveniently relocated happy peasants and livestock.

There is one small problem: historians generally consider the most elaborate version of the story to be exaggerated, if not largely mythical. Potemkin certainly decorated towns and settlements for Catherine’s visit, but evidence for entire fake villages being repeatedly assembled and moved is weak.

The metaphor survived anyway.

WHEN

You’ve encountered a Potemkin Village when:

• The demo works suspiciously well
  Every click follows one carefully rehearsed path. Deviate from it and you enter unexplored territory.

• The prototype looks more complete than it is
  Stakeholders understandably assume that something looking finished means it is nearly finished.

• Manual work hides behind apparent automation
  The magical automated workflow is powered by two spreadsheets and an intern.

• Progress is optimized for presentation
  The team spends more effort preparing what leadership will see than improving what users actually experience.

• You hear: “Whatever you do, don’t click that.”
  A traditional Potemkin city-limit sign.

If the product is impressive only from one carefully selected viewing angle, you may be standing in front of a very attractive façade.

WHY

Potemkin Villages describes impressively constructed façades to conceal a much less impressive reality. None of this is inherently bad; UX has always used mockups, clickable prototypes, Wizard of Oz testing, and simulated data to explore ideas before building them.

The problem begins when the audience isn’t told which parts are real. At that point, you’re no longer demonstrating the future – you’re misrepresenting the present.

Some of the reasons that’s happening include the following:

• Stakeholder pressure
  Leadership wants to see progress, and visible interfaces communicate progress much more effectively than architecture diagrams and partially completed infrastructure.

• Funding and approval
  A convincing prototype can unlock investment, resources, or organizational support.

• Demo-driven development
  When milestones revolve around presentations, teams naturally optimize for what will be presented.

• Fear of showing unfinished work
  Teams hide uncertainty because admitting that something doesn’t work yet feels riskier than making it appear that it does.

HOW

The goal isn’t to stop building convincing prototypes. A good façade can be extremely useful when everyone understands what’s behind it. Include the following strategies to make that clear:

• Label prototypes honestly
  Be explicit about what is functional, simulated, hard-coded, or conceptual.

• Show the seams
  Stakeholders should understand which pieces exist today and which represent intended future behavior.

• Separate demonstration from validation
  A successful demo proves that a story can be presented. It doesn’t prove that the product works.

• Test beyond the happy path
  Real users have an unfortunate habit of clicking the buttons you hoped they wouldn’t. Account for the Sad Path.

• Track real progress separately
  Measure usability, functionality, reliability, and outcomes – not just how convincing the latest demo looked.

PRO TIP

A prototype becomes a Potemkin Village when people stop knowing it’s a prototype. Great teams know when to spend time on appearances and when to pivot to user experience and functionality.

EXAMPLES

• A polished prototype presented as though it were a nearly finished product.
• A dashboard filled with carefully curated sample data that cannot yet connect to real data.
• An “AI-powered” workflow where humans secretly perform most of the work behind the scenes.
• A sales demo with one perfectly functioning path surrounded by polished screens that do nothing.
• A pilot project carefully designed for ideal conditions and presented as evidence that the solution will work everywhere.

CONCLUSION

A Potemkin Village isn’t necessarily a fake product. Prototypes, simulations, and carefully staged demos are essential tools for exploring ideas, communicating a vision, and learning before committing enormous amounts of time and money. Sometimes you need to build the façade before deciding whether the building is worth constructing.

The danger begins when representation becomes deception. A beautiful prototype can make unfinished technology feels finished, simulated behavior feel functional, and carefully selected success look like general reality. Once decisions, budgets, or expectations are based on that illusion, the façade stops being a design tool and becomes a liability.

As soon as possible, build the village using real content, paint the houses with actual brand colors, and populate it with wonderfully realistic sample data that helps you understand the art of the possible.