Yaravan — a warranty platform that shows its open questions

01Context

A dormant identity, a working product

Yaravan is the warranty and after-sales brand of an Iranian mobile-phone retailer. An outside agency wrote its brand identity in 2024 — a strategy deck and a visual guideline — and then nothing was built on it.

From July 2026 the job was to turn that identity into a working product: an independent Persian website, a customer panel and a staff panel. The existing support system keeps the ticket queue and the repair operation; the product covers what the brand itself owns. The operation underneath, drawn process by process, is a case study of its own.

02Problem

Where a fact should be

The existing site promised more than the operation delivered. The requirements work found that its headline claims were not operational truth, and that no real warranty database existed — no data migration was needed, because there was no data.

The brand strategy promised more again — branches, round-the-clock service, delivery, bundled insurance — and the operation that would have to keep those promises was still being defined. A customer-facing site could quietly turn any of them into a commitment.

That left one real design question: what do you put on the page where a fact should be, when nobody can yet confirm the fact?

03My role

Leading the work, with the client’s team

I led the product — requirements, the interface specification and the build — with the client’s engineering team contributing. Business ownership stayed with the client: its business lead owned the commercial decisions and its after-sales lead owned the support operation the product depends on.

Owned

Requirements and scope
Brand system, derived from the source files
Interface specification
The unconfirmed-claim pattern
Customer and staff panel design
Hero videos for the home page, made with AI

Co-owned

The platform build, with the client’s engineering team

Collaborated

Commercial decisions (the business lead)
The support operation (the after-sales lead)

The build was AI-assisted, and the repository says so openly: its guide sets the source-of-truth order and the conflict rules that made that safe on a business where most facts were still open.

04Approach

Specified in writing, governed question by question

The requirements came from fifty direct multiple-choice questions to the business lead, against one success test: engineering can start without re-asking any fundamental question. The interface was then specified in writing rather than drawn — 49 component files — because the screens were the known part. The design effort went into the operation underneath and into the rules for what the screens may say.

Those rules are a conflict protocol, and it decides which source wins by type of question rather than once for all. The business documents win on service, warranty, price, SLA and behaviour; the brand files win on logo, colour and type. A customer-facing claim needs both a brand source and a confirmed operational basis, or it does not ship.

The 2024 brand strategy and the 2026 reality contradict each other constantly. The fix was never to pick a winner globally — it was to govern the gap, one kind of question at a time.

05Brand

Derived, never redrawn

The brand system was reverse-engineered from the agency’s two source files, and every statement in it is traceable to a page of them; where the files are silent, the documentation says so instead of filling the gap. Colour was read from the logo’s vector fill operators rather than sampled from a render — which settled a discrepancy between two blues as a colour-space conversion, not a second brand colour. A bright yellow that appears only as a one-pixel “you are here” outline became a functional highlight, never a brand colour.

The type pairing came with its licensing risk written down rather than discovered later: the display face is commercial and needs web-embedding rights confirmed. The logo library — 15 SVGs, 75 PNGs, 75 WebPs and 12 favicons — was generated from the original vector paths, and the lockup follows reading direction: symbol on the right in Persian, on the left in English. A logo is never mirrored to fake the other direction.

06Solution

The unconfirmed-claim marker

Where a page needs a fact nobody has approved, it renders an orange dashed box naming the missing item and its owner — a content block that editors place like any other. A sweep in mid-August counted 32 live open items on seven of the eight public pages, and found that five recurring subjects account for most of them. Closing five things closes most of the site.

The marker is the product’s answer to the design question. It turns a content problem — pages that need facts nobody will yet approve — into a list that can be counted, assigned and closed, and it keeps the site honest while it is incomplete: nothing a customer reads is a promise the business has not made.

Yaravan — the contact page in Persian: six dashed orange boxes, each naming a fact that still awaits approval — Figure 02The contact page: the facts it still needs, listed where they will go.

07Customer panel

Seven principles on every page

The customer panel replaces phone calls with a place to look. Eight destinations cover what a customer actually does — sign in, see where they stand, register a device, check a warranty, open a request, follow it, find past repairs and invoices, keep an address on file — and on a phone the four most used sit in the bottom bar, one tap away. Seven principles hold on all eleven pages:

No password: a mobile number and an SMS code, so there is nothing to forget.
Private by default: customers see only their own data, enforced on the server rather than hidden in the interface.
Mobile first: the four most-used destinations in the bottom bar.
Fully Persian: text, calendar and digits — with serials and IMEI kept left to right so they read correctly.
Empty states that teach: every empty page says why it is empty and what to do next.
Explicit, not ambiguous: “not yet synced” is kept apart from “you have no warranty” — two completely different states that most systems show as “nothing found”.
Accessible: the panel has its own accessibility test suite.

Small decisions carry the same care. Ticking “this device has a problem” while adding a device opens a repair request at the same time — two jobs in one form. The customer is told to write the tracking code inside the parcel, so the device joins its case the moment it arrives. And a case that belongs to someone else returns “not found”, never a message that reveals it exists.

Yaravan — step one of a new request on mobile in Persian: choose repair or warranty, complaint, or general question

Yaravan — an empty repair history on mobile in Persian that explains what will appear there and offers a button to view requests — Figure 04An empty state that teaches: the repair history before there is any history. Demo data.

08Status

Status never goes backwards

A repair or warranty request moves through four stages the customer can see — registered, under review or repair, ready for delivery, delivered — while a complaint or a question closes after review. Every change stays on the timeline with its date and time. Skipping a stage, going back, or changing a finalised status is rejected on the server, not just hidden in the interface, and sending the same form twice does not create a second request.

Behind those four stages, six happen at headquarters: intake and triage, receiving the device, diagnosis, the warranty-eligibility check, repair and quality control, and handover. The customer sees four, and the difference is deliberate — the panel says so in plain words, telling the customer that only the general stages are shown and the internal detail is kept out of view.

The status shown to the customer never lies: an unknown response from an outside system stays pending until it is reconciled, and is never shown as success.

Yaravan — a request in the customer panel on desktop in Persian: a four-stage progress bar, a sentence explaining the current stage and a dated status history — Figure 05A request on desktop: the four-stage bar, a sentence explaining the current stage, and the dated status history. Demo data.

09Key decisions

Six boundaries

Most of the design is about what the product refuses to do or say.

01
Show the gap and its owner, not a guess
A site that states an unapproved promise turns it into a commitment. Rendering the open item — with the person who owes the answer — keeps the site honest while it is incomplete, and turns a content problem into a list that can be tracked and closed.
Alternatives
Plausible placeholder copy, or hiding the section
Trade-off
The site visibly looks unfinished until the business answers.
02
A staff panel that is not an operations panel
Agents already work in the existing support system, and a second one would split the truth. The staff panel covers only the processes the product owns — invoices, activation codes, parts receipt, dealership review — and its sitemap says it must never grow into ticket queues, diagnosis or repair.
Alternatives
Rebuilding ticketing inside the new product
Trade-off
Staff work in two systems until the two are connected.
Evidence
The staff panel home: four counters for the work the product owns, and nothing from the ticket queue.

Yaravan — dealership applications in the staff panel in Persian: each request with its status and approve or reject buttons, the applicant marked as not yet defined

Yaravan — parts in the staff panel in Persian: a search, filters for requested and received, and three parts with their status

10What’s next

The market built the customer a website, not a way back

A study of 100 companies in Iran’s digital-goods warranty and repair market, 18 of them assessed in depth against a twelve-stage repair journey, found a cliff: the first five stages are largely digital, and from device handover onward almost nothing is. The best platform digitises six stages of twelve; the average is 4.1.

The study’s reframe is a data-model argument, which is why it reaches the product: the unit of information in this market is not the ticket or the invoice but the service case — one device’s whole life, from its condition at intake through diagnosis, cost approval, repair, quality control and return. The first decision it put forward is an itemised pre-invoice the customer approves online, which no company in the study offered. The product stops at the workshop door on purpose; the case for going further is now written down.

Yaravan market study — a chart of twelve repair-journey stages: the first five mostly digital, stages six to twelve between zero and eleven percent — Figure 07The cliff: stages one to five of the repair journey are 33–100% digital across the platforms studied; stages six to twelve, 0–11%.

11Every page

The public site, page by page

Every page of the public site, captured on 26 September 2026 at 1,440 pixels wide and on a 390-pixel phone: the home page, services, why us, the warranty terms, the customer charter, about, the dealership application, the FAQ, contact, the satisfaction survey, the feedback and complaints form, and sign-in.

The pages share one system: white pages broken by deep-blue bands, the same four-step request strip — request, inspection, repair, delivery — on the home and why-us pages, and on a phone a single column with the navigation behind a menu button. The company’s and the retailer’s names, the address, the phone number, the store photograph, the sample warranty card and the warranty lengths are masked in grey before capture; nothing else is retouched.

Yaravan on desktop — Home, the first screen, with identifying details masked

Yaravan on desktop — Services, the first screen, with identifying details masked

12Hero videos

The service in twenty seconds

The home page needed a hero that stops the scroll, so I made four short videos for it with AI. The main one runs twenty seconds and follows the four-step strip already on the page — request, inspection, repair, delivery: a customer walks in, a technician inspects the phone and repairs it, and the phone is handed back.

The other three are its scenes, ten seconds each: inspection, repair and handover. The main video opens on an arrival shot, then takes the first five seconds of each scene. All four are generated, not filmed, so they illustrate the service rather than record it. Making a site’s hero eye-catching with AI video is a skill I bring to any home page.

Figure 09Made for the home page: arrival, inspection, repair and handover in twenty seconds. Generated with AI.

Inspection

13Outcomes

A platform waiting on decisions

There are no business metrics, and there should not be: the platform is on staging, and the agreed measures have no approved formula or data source yet. The six-week Phase 1 target was missed. The three items blocking integration — access to the existing support system, a customer-sync contract, and a written security and privacy approval — are decisions, not engineering, and every other open item was re-tiered to gate only its own feature.

A public site: Eight pages, all Persian and right to left, with every unapproved fact shown as an owned open item.; Delivered output
A customer panel: Built on seven principles: no password, private by default, mobile first, and empty states that teach.; Delivered output
A staff panel: Only the work the product owns — invoices, activation codes, parts and dealership review — with segregation of duties enforced in the code.; Delivered output
A tested build: 26 collections and 92 test files across five levels, with CI on every push.; Delivered output

What was delivered

Public site
Customer panel
Staff panel
Unconfirmed-claim marker

14What I learned

The honest version of a product

01
Publishing the gap beats papering over it
The dashed orange box is the whole project in one component. It turned a content problem into a tracked, owned, countable list, and it made the site honest while it was still incomplete.
02
Say the difference out loud
“Not yet synced” and “you have no warranty” look alike in a database and mean opposite things to a customer. So do four stages and six. Naming the difference on the screen cost a sentence and saved a phone call.
03
A brand strategy is not a product spec
The fix for a strategy that contradicts reality is not to pick a winner once. It is a rule that says which source wins for which kind of question — and that no customer-facing claim ships without both.
04
Guardrails must keep pace with the build
The repository’s guide still described a codebase with no application source long after it had 26 collections and a staging deployment. Documentation that governs an AI-assisted build has to be maintained at the speed of the build, or it starts governing a codebase that no longer exists.

Language

Yaravan — a warranty platform that shows its open questions

A dormant identity, a working product

Where a fact should be

Leading the work, with the client’s team

Owned

Co-owned

Collaborated

Specified in writing, governed question by question

Derived, never redrawn

The unconfirmed-claim marker

Seven principles on every page

Status never goes backwards

Six boundaries

Show the gap and its owner, not a guess

A staff panel that is not an operations panel

The market built the customer a website, not a way back

The public site, page by page

The service in twenty seconds

A platform waiting on decisions

What was delivered

The honest version of a product

Publishing the gap beats papering over it

Say the difference out loud

A brand strategy is not a product spec

Guardrails must keep pace with the build

No integration is a launch prerequisite

Integrations fail closed

Segregation of duties in the product, not only on paper

Name what was not built, and why