In one of our projects, the client shared a live application as a benchmark for the user interface. The objective was straightforward—use the application as a reference for the overall look and feel.
The team carefully studied the benchmark. Discussions were held, the UI was designed, and development moved ahead with confidence.
Everything appeared to be aligned.
Until the formal review.
The client looked at the screens and said,

“This isn’t what we had in mind.”
That moment changed the conversation.
The benchmark application had never been the problem.
The problem was that both sides had interpreted it differently.
The client assumed certain workflows, interactions and behaviours would naturally be part of the design because they existed in the reference application.
Our team assumed the benchmark was intended primarily for visual guidance and implemented the screens accordingly.
Neither assumption was documented.
Neither assumption was validated.
As a result, the UI was rejected, discussions had to be revisited, and the project lost nearly three weeks in redesign and review.
That experience fundamentally changed the way I approach benchmarking.
A benchmark is not a specification.
It is only a starting point for discussion.
Today, whenever a reference application is shared, I ask one additional question before development begins:

“What exactly are we benchmarking—visual design, user journey, functionality, or all three?”
That one conversation has helped eliminate countless assumptions before they become expensive rework.

Have you ever discovered that both the client and the project team were looking at the same reference—but seeing two completely different solutions?
#ProjectManagement #UserExperience #ProjectDelivery #RequirementsGathering #Benchmarking #DeliveryExcellence