It's 4pm. A lighting designer is racing a deadline, and your product is on her shortlist. She needs three things fast: the beam angle, the IP rating, and a Revit file. If your site makes her dig for them, she picks a competitor's fixture instead and moves on. You never even know it happened.
She is who your website is really for. Not someone browsing for fun. Someone with a deadline. And keeping her happy has less to do with how the site looks, and more to do with one thing most people get wrong before a project even starts.
Here's the thing nobody tells you: a product website is not a design project. It's a data project wearing a design costume.

We learned that rebuilding the site for a premium architectural and outdoor lighting manufacturer. They're anonymous here, so we'll just call them the client. Excellent products, a deep range, serious testing and compliance behind them. But their old site was built like a shop, for an audience that never shops, and the data a specifier needs was buried or missing.
The pretty part was never going to be the problem. Hundreds of products sitting in spreadsheets with no web-ready structure was. So before we designed a single screen, we made five decisions that carried the whole project.

Five decisions before we touched a screen
Agree the data model first. One product template, one repeatable import, one structured layout every product follows. This was the backbone. Settle it early and the build stays sane. Skip it and you drown.
Give technical buyers four ways in. Browse by family, application, luminaire type, and mounting solution. Specifiers don't all think the same way.
Lock the design in Figma. Sign-off before development gave the build team a fixed target and gave the client confidence in exactly what they'd get.
Build a real downloads hub. Catalogues, BIM and Revit files, and compliance documents, all self-serve, so nobody has to email for a datasheet.
Hand it over properly. A clean CMS and real training, so the client's own team runs the site instead of depending on us forever.
None of those five are about how the site looks. All of them are why it works. That's the difference between a brochure, which is really just a PDF that loads slowly, and a tool your customers use to make a decision.

It wasn't friction-free. The client's main contact changed partway through, and new requirements arrived after sign-off, like they always do. We didn't absorb them silently and let the timeline bleed. We quoted them openly as a second phase. The client chose to take it, which is the clearest sign there is that the work landed.
Where it stands: built, run through user acceptance testing, handed over to the client's team, and ready to go live.
If you make a serious product range and your website doesn't help a specifier do their job, that's not a design problem. It's a revenue one. That's the kind of thing we fix. If this was useful, send it to someone wrestling with the same catalogue.
Anonymised case study. Client identity, product names, and confidential commercial details have been withheld.




