Product presentation
Product website and workflow presentation
A multi-language product front end for a business tool, where the routing and layout had to work identically in two reading directions.
Interface built in code for this case study — not a client screen capture.
01Business problem
A business product that has to explain itself to two audiences reading in opposite directions, without maintaining two websites to do it.
Who feels it
A product site has one job: a visitor who has never heard of the tool should understand what it does, who it is for, and what happens next. That is harder for a workflow product than for a physical one, because the value is a sequence of steps rather than an object, and a list of features does not convey a sequence.
The complication here was language. Serving a Gulf market properly means Arabic is not a translation layer bolted onto an English site — it is a first-class version with its own reading direction, its own line lengths, and its own typographic rhythm. The usual approach, a language switcher that swaps strings inside a layout designed left-to-right, produces a version that technically works and visibly was not designed.
Doing it as two separate sites solves the design problem and creates a worse one: two codebases that drift, where a fix applied to one is forgotten in the other, and where the second language slowly becomes the neglected one.
02Product overview
One codebase, language as a route segment, and a layout system built on logical properties, so neither direction is a mirror of the other — both are the designed case.
Engineering notes
Language sits in the URL as the first path segment, which makes every page in every language a real address. That matters more than it sounds: a shareable link carries its language, search engines can index both versions independently, and the language a visitor chose survives a page reload — none of which is true of a client-side switcher holding the choice in memory.
The layout is written with logical CSS properties throughout, so the direction flip is a document attribute and not a second stylesheet. Margins, padding, borders and text alignment resolve relative to the reading direction, which means a layout adjustment lands in both languages simultaneously and cannot be applied to one and forgotten in the other.
Where that approach breaks is anything with an intrinsic direction, and those had to be handled individually, never flipped wholesale. An arrow indicating forward progress should reverse; a logo, a phone number and a screenshot of an interface should not. I went through the components and marked which category each visual element belonged to, because getting this wrong is the specific tell that a site has been mirrored by a stylesheet rather than designed in both directions.
Explaining the product itself is a presentation problem more than a copy problem. The workflow is shown as a sequence a visitor can move through, one step visible at a time with the whole path still legible around it, so the shape of the process is apparent before any of the detail is read. It degrades to a plain ordered list without JavaScript, because a marketing page that shows nothing while a bundle loads is worse than a static one.
Type was the last thing to settle and the most visible. Arabic and Latin text at the same nominal size do not read as the same size, and the line heights that suit one look wrong on the other. The scale is defined per language, not shared. It costs a little extra configuration, and it separates a site that reads naturally from one that reads like a translation.
03Key features
7 capabilities. Every one of them is deterministic software — there is no model in this build, and nothing here is described as AI.
Every page has a real address per language. Links are shareable with their language intact, both versions are independently indexable, and the choice survives a reload.
Logical properties throughout, so right-to-left is a designed case and not a mirrored afterthought. A spacing fix applies to both languages at once.
Directional icons flip; brand marks, numerals and interface captures do not. Each visual element was classified deliberately, because blanket mirroring is exactly what looks wrong.
The product’s process shown as a sequence a visitor advances through, with the full path visible around the current step. Keyboard operable, and a plain ordered list when scripting is unavailable.
Sizes and line heights defined per language instead of shared, because Arabic and Latin text at the same nominal size do not read at the same weight.
Breakpoints set from the real device range in the target market, not from a desktop design scaled down, with the narrow layout treated as the primary case.
Pages are generated per language at build time. Nothing about the first paint waits on a request, and on a mobile connection that is most of the performance story.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
The first path segment is the language. An unprefixed request is resolved to a language and redirected once, so there is exactly one canonical address per page per language.
Copy is keyed per language with a build-time check that no key is missing. A missing string fails the build; it never renders an English fragment inside an Arabic page.
The document direction is set from the route at render time, not by client-side script, so the first paint is already correct and nothing reflows.
Logical-property layout primitives compose the page. Direction-sensitive components consult the direction; everything else is unaware of it.
Every page is generated for every language at build time. Adding a language multiplies output pages — the intended trade for zero runtime content cost.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
Real addresses per language make links shareable, versions independently indexable and the choice persistent. A client-side switcher gives up all three for a slightly simpler router.
Trade-off
Every page exists in multiple canonical forms, so redirects, canonical tags and the sitemap all need to be right. That is a fixed cost paid once.
Why
One layout definition serving both directions means a fix cannot be applied to one language and forgotten in the other. Forgetting is how bilingual sites decay.
Trade-off
Slightly less familiar to write, and any third-party component using physical properties has to be wrapped or replaced — which ruled out a couple of otherwise convenient libraries.
Why
Blanket mirroring flips things that should never flip. The classification is manual because there is no rule that gets it right automatically.
Trade-off
It is a per-component judgement that a new contributor has to be told about. Documented in the component notes for that reason.
Why
A silent fallback ships a page that looks complete to everyone except the reader it was meant for, and nobody finds it because nothing errored.
Trade-off
Copy changes cannot land in one language ahead of the other. That is friction by design, and it is the reason both languages stayed complete.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Went through the components separating genuine direction-sensitivity from incidental mirroring, then rebuilt the affected ones — icons and progression indicators flip, brand marks and interface captures stay fixed.
Outcome
The Arabic version stopped reading as a flipped copy. This is the detail a native reader notices immediately and a developer testing in one language never sees.
Approach
Split the type scale per language, tuning size and line height separately, and reviewed both at real device widths instead of in a side-by-side browser window.
Outcome
Both versions read with the same weight and rhythm despite different numbers behind them.
Approach
Rebuilt it to render the complete sequence as an ordered list server-side, with the step-through behaviour layered on top as an enhancement.
Outcome
The page is informative at first paint and on a failed bundle, and the interaction is an improvement, never a requirement.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Language routing
The same page at its two addresses, with the direction attribute and alternate links shown.
Direction classification
Which elements flip and which are pinned, per component.
Workflow explainer
One step active with the full sequence still legible around it.
Type scale
The two scales side by side at the sizes that read as equivalent.
A diagram I drew from the implementation, showing the components that exist and how they call each other. It is evidence of how the system is put together. It is not a capture of a running system, and it does not by itself establish that the system shipped or was used by anyone.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
Implementation detail
11Technical preview
This build was delivered to a client, so the source belongs to them and is not republished here in any form — not as excerpts and not as a repository link.
Delivered work
For private client work, contact me for a walkthrough. On a call I can screen-share the build, go through the component structure, the decisions behind the interaction work and the parts that needed rewriting — the same ground a technical preview covers, without republishing a client's property to do it.
Or email directly: surajk86808@gmail.com
What is not published here
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.