top of page

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.Ş.

Frame 45.png

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.

01.SOCAR.jpg

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.

bottom of page