Why a Working Proof of Concept Isn’t a Finished Product

What is a Proof of Concept?

A proof of concept is a little like a TV pilot.

It doesn’t need to have five seasons mapped out, every character fully developed, or every detail perfectly polished. Its job is to answer a much simpler question: Is there something here worth pursuing?

Digital products aren’t all that different.

A proof of concept might show that two systems can successfully talk to each other, that the right information can be retrieved, or that users actually want the capability you’re considering. That’s a huge win.

But proving that an idea works isn’t the same as proving that the experience works.

That’s where UX starts asking a different set of questions: What does the user actually need to see? What should they understand first? Does the language make sense to them? Can they tell where they are and what happens next?

In other words, the proof of concept tells you we can do this.

UX helps answer how should this actually work for people?

Just because the information is there doesn’t mean it’s useful

I saw this recently on a project where an organization wanted to give patrons access to information they previously had to call an employee to get.

They built a proof of concept, and it worked. The technology could pull information from an internal application, and patrons liked the idea of being able to self-serve.

When the product came to us, the initial ask seemed pretty simple: make it feel more like their brand.

Once we looked at the experience, though, branding was only part of the story.

The internal application had been designed for employees who understood the terminology, statuses, and details being shown. Patrons didn’t need—or necessarily understand—all of that information.

That meant we had to figure out what was actually useful, what needed more context, and what could take a back seat.

For example, the application included a process made up of 12 tasks. We could have simply shown all 12. Technically, everything the patron needed would be there.

But access to information isn’t the same as understanding it.

Instead, we grouped the tasks into a visual timeline so patrons could understand the larger process first, then expand into the details when they wanted them.

Same information. Much easier to absorb.

Good UX often happens in the small stuff

Not every UX improvement is a dramatic redesign.

During the same project, a calendar feature was added that displayed upcoming events. It worked, but there wasn’t an obvious distinction between a virtual meeting and an in-person one.

Technically, the information was there.

For someone trying to figure out whether they need to drive somewhere Tuesday morning, that missing distinction matters.

That little gap between “the information exists” and “the information is immediately useful” is where a lot of UX work happens.

The same goes for navigation, labels, hierarchy, and familiar interface patterns. Users bring expectations from every other digital experience they’ve had. The less energy they spend figuring out your interface, the more energy they can spend accomplishing what they came to do.

Working is a milestone

None of this means prototypes are bad. Quite the opposite. A proof of concept can validate the technology, the idea, and even whether users want the capability in the first place.

Proof of concepts doesn’t necessarily validate the experience.

That’s why UX is valuable before too much of the final interface becomes set in stone. It gives us a chance to work through hierarchy, language, navigation, and user needs while those decisions are still relatively easy to change.

“Can we build it?” is an important question.

Before calling it finished, there’s another one worth asking: Did we build it in a way that makes sense to the people who have to use it?

A working product is absolutely worth celebrating.

It just might not be the finish line.