Projects
SOCAR Turkey
One design language, five companies that had not agreed on much yet.
Role: Senior UX/UI Designer
Scope: Digital design system derived from brand guidelines, main site and five subsidiary sites
Platform: Corporate web, one parent brand and five subsidiary companies
Agency: Project House - Havas
Client: SOCAR Turkey Enerji A.Ş.

Overview
When SOCAR entered the Turkish market, it brought its other investments with it. Petkim, Star Refinery, Petlim, SOCAR Fiber and TANAP are separate companies in separate industries, not divisions of one business.
The brief was to give all of them a single digital language without pretending they were the same company.

Translating a brand guideline into a system
There was a brand guideline. It was written for brand, not for screens.
My job was to turn it into something a website could be built from, and then into something six websites could be built from. Navigation, page templates and component behaviour were shared or closely parallel across all of them. Each company carried its own colour range within that structure.
The differentiation sits in tone rather than in layout. A refinery and a fibre infrastructure company do not need different navigation. They need to look like themselves inside the same system.
Components the energy sector actually uses
Sustainability reports and news modules were built as reusable components rather than as page designs.
That sounds administrative and it is the part that carried the most weight. These are high volume, continuously published, and they are the pages that regulators, investors and journalists actually open. Designing them once, properly, meant every company got the same standard without anyone rebuilding it.
Designing against a timeline nobody had agreed on
The design work went smoothly. The programme around it did not.
Five companies meant five sets of stakeholders with their own priorities, and they spent a lot of the project unable to settle on a shared schedule. Requests arrived late, and they arrived out of sequence.
Two things kept that from reaching the work. The first was hitting every date I had committed to, so my part was never the reason something slipped. The second was structural: because the sites were assembled from shared components rather than drawn as finished pages, a late request usually meant configuring something that already existed rather than reopening a design.
When you cannot control the schedule, the useful thing to control is how expensive a change is.





