CX Engineering & Benchmarking

A customer who cannot get past the IBAN field, or who meets "System Error 500" with no
explanation, has hit a structural fault. The interface is where it shows. The cause usually sits
upstream, in how the flow was specified or in what the design assumed the customer already knew.

Fintechify treats the customer journey as a system and measures it. We score an application against
a fixed set of dimensions, state what each score rests on, and then design the structure that closes
the gap. What you get back is a number you can defend and a set of documents a delivery team can
start on.

Why this is measurement work

Most app reviews are opinion. Someone walks the product, lists what they dislike, and writes it up.
The result cannot be checked, ranked or tracked between releases, and it does not survive the first
question from an engineering lead.

Scoring changes that. Every application in a study is measured against the same dimensions with the
same evidence bar, so the numbers are comparable across products and stable enough to re-run after a
release. When we report that a flow is weak, we can show the observation that produced the score and
how many observations sit behind it. Anything derived from a screenshot rather than the live
application is marked as estimated rather than asserted.

The measurement model

The instrument is fixed: 48 measured metrics, grouped into dimensions. Three components are
scored against it, reported separately and then combined into one figure.

Heuristic evaluation. The ten established usability heuristics, assessed at every screen and key
flow. Each is rated from 0 to 3 at each observation point and normalised to a score out of 30. The
count of observation points is published alongside the score, because a result built on eight
observations means something different from one built on ninety.

Capability maturity. The core of the study. A fixed set of dimensions, each scored from 0.000 to
5.000, each backed by named data points: the specific screens, flows or features that justify the
number. The 48 metrics are the instrument; each dimension score is built from the metrics beneath
it. The set stays identical across every application in the study, because a ranking assembled from
different questions is not a ranking.

Issue severity. Every named failure is rated 0 to 4, from cosmetic through task-blocking to
abandonment and compliance risk. This is the step that turns a list of problems into a sequence of
work.

The composite carries its weights in the open. A single benchmark figure with hidden weighting is
not a measurement.

flowchart TD
    A["Observation points<br/>screens + key flows"] --> B["Heuristic evaluation<br/>0-3 per heuristic per point"]
    A --> C["Capability maturity<br/>0.000-5.000 per dimension"]
    A --> D["Issue severity<br/>0-4 per named failure"]

    B --> E["Normalised /30<br/>+ count of observations"]
    C --> F["Per-dimension score<br/>+ named data points"]
    D --> G["Aggregate /40<br/>ranked by severity"]

    E --> H["Weighted composite"]
    F --> H
    G --> H
    H --> I["Ranked position<br/>+ gap to the leader"]

    classDef src fill:#f4f6fb,stroke:#2733ab,color:#0b176d
    classDef mid fill:#ffffff,stroke:#c9c9d4,color:#1a1a2e
    classDef out fill:#fbecdb,stroke:#c9962a,color:#5a3d0a
    class A src
    class B,C,D,E,F,G mid
    class H,I out
  

What we can start from

An engagement begins one of three ways, and we treat all three honestly.

An existing audit corpus. Text is extracted from each report. Tables that arrive as images are
read and marked as estimated. Every competitor is identified from its own title block rather than
its filename, because audit folders accumulate dated copies of the same document and a filename is
not evidence.

A walkthrough recording. Frames are extracted and the flows are reconstructed as a connected
graph before anything is scored. Where a state never appears in the recording, it is recorded as not
observed.

A name and a store listing. This is a legitimate brief. Store screenshots, the product's own
published detail and regulator directories give first-hand evidence of what shipped. Press and
review aggregators carry real signal about perceived failure but are marked as secondary.

One rule holds across all three. A flow that cannot be seen is recorded as not observed, never
as absent and never as poor. The report states its corpus and its observation window, because a
benchmark is a snapshot and should say so.

flowchart TD
    A1["Audit corpus"] --> P
    A2["Walkthrough recording"] --> P
    A3["Name + store listing"] --> P

    P["Evidence capture"] --> C1["First-hand<br/>live app, screenshots, listing text"]
    P --> C2["Secondary<br/>press, review aggregators"]
    P --> C3["Estimated<br/>OCR, inference"]

    C1 --> S["Scoring"]
    C2 --> S
    C3 --> S
    S --> N["Not observed<br/>recorded as a gap, not a defect"]

    classDef in fill:#f4f6fb,stroke:#2733ab,color:#0b176d
    classDef cls fill:#ffffff,stroke:#c9c9d4,color:#1a1a2e
    classDef warn fill:#fbecdb,stroke:#c9962a,color:#5a3d0a
    class A1,A2,A3,P in
    class C1,C2,C3,S cls
    class N warn
  

From benchmark to structure

A benchmark that stops at a ranking has done half the job. The measured gaps, read against a
standing panel of 12 digital-first banks operating in the GCC, are structural decisions waiting to
be made, so we make them.

The gaps are ranked by distance from the best score in the field. Root-level destinations are the
scarce resource in any consumer banking app, and they are allocated to the places where an
institution can lead rather than match, not to the features every competitor already has.

Every dimension in the study is then traced to a named destination in the proposed structure, and
the check runs in both directions. If a dimension was scored, the structure has to contain it. That
constraint is what stops a proposal from claiming credit for a capability it never designed, and it
is the single check that most often finds a real hole.

Tap depth is set as a budget the structure must satisfy and then verified by walking the graph.
Depth that is discovered after the fact rather than budgeted is the most common structural failure
we find in banking apps.

flowchart TD
    G["Scored gaps<br/>5.000 minus score, ranked"] --> R["Root-level destinations<br/>allocated to differentiators"]
    R --> D["Dimension to named destination<br/>mapping table"]
    D --> V{"Every scored dimension<br/>has a destination?"}
    V -->|No| X["Close it in the structure<br/>never remove it from the benchmark"]
    X --> D
    V -->|Yes| T["Tap-depth budget<br/>verified by walking the graph"]
    T --> O["Information architecture proposal"]

    classDef gap fill:#f4f6fb,stroke:#2733ab,color:#0b176d
    classDef chk fill:#ffffff,stroke:#c9c9d4,color:#1a1a2e
    classDef fix fill:#fbecdb,stroke:#c9962a,color:#5a3d0a
    class G,R gap
    class D,V,T,O chk
    class X fix
  

Designing the answer, not describing it

Where a client has an approved visual language, we design against it. The colour, type scale,
spacing and components that have already been signed off are applied to every screen the proposed
structure resolves to. Each screen is produced in light and dark, and onboarding gets its own
sequence, since it is usually where the structure does its most important work.

Screens are laid out rather than generated as images, so type metrics, wrapping and overflow are
real rather than plausible. Every screen is then measured against its usable viewport: what the
navigation bar covers, what a raised centre control covers, whether a horizontal rail hides a
control at the end of the row. A screen that passes review as a thumbnail and clips in the build is
a defect, and it is cheaper to catch here.

A deck of screens also settles arguments that prose cannot. Reviewers approve a structure more
confidently when they can see the destination they are approving.

Arabic and right-to-left as engineering

Mechanical mirroring does not produce an Arabic interface. It produces clipped text, reversed
directional cues and a reading order that breaks in places the original never had.

Arabic is a joining script: a letter takes a different form depending on its neighbours. A pipeline
that treats each character in isolation renders every letter in its isolated form, in scrambled
order, which reads as garbage to anyone who speaks the language. We shape the whole string, scope
the layout direction to the application frame rather than the document, and set the text in a face
that covers all 33 Arabic presentation forms.

The result is verified with a controlled render of known phrases rather than by eye. Right-to-left
text looks reversed to anyone reading left to right, which makes "is this backwards?" almost
impossible to answer by looking at it.

flowchart TD
    E["English screen set<br/>HTML + CSS"] --> S1["Swap to an Arabic-capable face"]
    S1 --> S2["Scope direction: rtl<br/>to the app frame only"]
    S2 --> S3["Translate text nodes<br/>from a dictionary"]
    S3 --> S4["Shape each whole string<br/>never per character"]
    S4 --> S5["Remove Latin letter-spacing"]
    S5 --> R["Arabic RTL screen set<br/>light + dark"]

    V["Controlled render of known phrases<br/>order and joining"] --> R

    classDef en fill:#f4f6fb,stroke:#2733ab,color:#0b176d
    classDef st fill:#ffffff,stroke:#c9c9d4,color:#1a1a2e
    classDef out fill:#fbecdb,stroke:#c9962a,color:#5a3d0a
    class E en
    class S1,S2,S3,S4,S5,V st
    class R out
  

Verification

Everything handed over is checked against the artefact you receive rather than the intent behind
it. Page counts and image dimensions are read back out of the finished PDF. Text is swept for
anything that should not be in a client document. Screens are measured rather than eyeballed.

Where a check fails, it is reported as outstanding. A fix that was blocked is not called done.

What you receive

• An individual review per application, scored across all three components with the evidence attached
• A combined benchmark placing every application on the same dimension set, with a named leader per dimension and the gap stated
• An information architecture proposal, carrying a traceability table, an anti-pattern compliance table and the workflows as connected graphs
• A screen set in your approved visual language, light and dark
• The Arabic right-to-left set of the same screens
• A severity-ranked backlog, sequenced by effort and impact