Proof in Practice
A working button is only the beginning.
A small fault on our own mobile site—and the stronger acceptance check it gave us.
We added a mobile shortcut bar to our own website so visitors could reach booking or chat quickly. Then an owner review caught a problem: the new bar partly covered the open menu.
The shortcut worked on its own. The menu worked on its own. Together, they got in each other’s way. It was a small visual fault with a very practical consequence: a visitor could struggle to reach the page they wanted.
The fault was in the overlap.
The header and shortcut bar shared the same display-layer priority. The later bar appeared over part of the dropdown. We moved the mobile header above it, then checked the expanded menu alongside the sticky bar.
What we actually checked
- Opened the menu at an actual 375-pixel phone viewport.
- Inspected the visible dropdown and checked that each of its three link centres hit the intended link, rather than the bar.
- Selected Industries and verified that it reached the correct section.
- Checked that the page had no horizontal overflow.
Those checks supported a specific conclusion: the reported overlap was repaired in the hosted preview. They did not establish a conversion increase or universal compatibility with every phone.
Test the combination, not just the feature.
For a website, that means opening the menu while a sticky bar is visible, checking a form while the keyboard is open and following a confirmation through to its next step.
The same principle applies to automation. A notification being sent does not prove it reached the right person. A saved file does not prove a client can open it. A chatbot offering a person does not prove the handoff happened.
A check worth repeating
- State the intended outcome. What should the visitor be able to do?
- Try the complete path. Include the awkward states: open menus, errors and small screens.
- Verify the destination. Open the result instead of trusting the success message.
- Keep the claim narrow. Record what passed, what failed and what remains untested.
This is the kind of evidence we want behind our work: a clear problem, a specific repair and an observable result.
Source: BlūLion’s own mobile-menu repair and hosted verification record, 21 September 2026. No client information is used.
Check your own enquiry journey