Skip to content
Ibrandify
← All work

Selected Work · PACT — Purchasing & Approvals

Every request.A clear next step.

pact· B2B SaaS

A bilingual product experience for purchasing requests, decisions, and operations handoffs: clear status, named ownership, and native RTL symmetry.

app.pact.co/workspace/dashboard
EN · AR
PACT Bilingual Purchasing Dashboard: My Requests, KPI cards and Approval routing table
Client
PACT
Sector
B2B Operations Software
Our Role
UX Strategy · Product UI · Prototype
Languages
English + Arabic · LTR + RTL

[01]The Challenge

Move the request.Keep the context.

Purchasing involves people with fundamentally different responsibilities: requesters who need gear quickly, managers who evaluate budget, and operations who execute supplier orders.

The design challenge is to give each role exactly the right information while preserving one continuous, untruncated request record across every handoff.

REQUESTER

What happens next?

Prepare a complete request, understand the approval route, and track who owns the next step without ambiguity.

Role 01Dedicated View
APPROVER

Can I decide confidently?

Review the reason, amount, supplier quote, and delivery context together. Request changes without losing the record.

Role 02Dedicated View
OPERATIONS

Is the handoff complete?

Receive an approved request with supplier, quote, delivery date, and a named purchasing owner ready for immediate fulfillment.

Role 03Dedicated View

[02]Evidence Before Assumptions

Define what we know.Make questions visible.

The business brief establishes three roles and bilingual access. Role needs are working hypotheses; the research plan is designed to test them rather than present them as findings.

Working Hypothesis

Clarity depends on ownership.

A written status alone may not be enough. The interface therefore names the next reviewer and maintains an activity audit trail so teams always know who holds the baton.

Discovery Plan

Follow a recent purchase.

Ask each role to walk through its last purchase request: where the quote lived, what delayed the decision, and how the final handoff was confirmed between English and Arabic contexts.

[03]The Journey

One request. Three responsibilities.

Map the information that must survive each transition. This keeps the interface focused on the task and exposes the assumptions to validate with users.

01 / PREPARE

Build a complete request

Owner: Requester

Inputs: Title, cost center, supplier, delivery date, item and quote.

Risk: Incomplete context causes back-and-forth follow-up.

Design response: Persistent summary and explicit review step before submission.

02 / TRACK

Know who has the next step

Owner: Requester

Inputs: Submitted record routes directly to Omar Khalid.

Risk: Status alone may not explain ownership or accountability.

Design response: Named reviewer and timestamped audit activity trail.

03 / DECIDE

Approve with context

Owner: Approver

Inputs: Business reason, amount, quote and requested date.

Risk: Missing delivery detail blocks a confident decision.

Design response: Request changes without discarding or resetting the record.

04 / ACT

Receive an approved package

Owner: Operations

Inputs: Approved record, supplier quote, delivery context and owner.

Risk: Fragmented information complicates purchase ordering.

Design response: One centralized queue with a complete handoff summary.

[04]Information Architecture

Structure before surface.

The request form pairs a focused main form column with a persistent summary. Reviewer ownership appears before submission; a separate review step makes sending a deliberate commitment.

PACT Low-fidelity wireframe: Form layout and persistent summary

[05]The Requester Experience

Prepare once.Review with confidence.

Visible labels, an attached supplier quote, and a persistent live total make the record understandable before it reaches another person. Saving a draft remains a clear secondary action.

PACT Requester Experience: Step 01 Details with persistent total SAR 8,400.00 and reviewer Omar Khalid
01 / Context

Make routing explicit.

Cost center and team travel with the request. The summary names the reviewer before the request is submitted.

02 / Commitment

Keep review separate.

Preparing and sending are different psychological moments. The review screen surfaces total, quote, and route together.

03 / Continuity

Preserve the record.

The same PR-1042 identifier, twelve chairs, and SAR 8,400 total continue seamlessly through approval and purchasing queues.

[06]Decision & Handoff

Decide with context.Hand over with clarity.

The approver sees the reason, total, quote, and requested date together. Approval changes the request state; operations receives the same record with a named owner.

Approver View · Review PR-1042Omar Khalid · Team lead
PACT Approver UI: Review PR-1042 with Request Changes and Approve Request actions
Operations View · Purchasing QueueSara Ali · Purchasing owner
PACT Operations UI: Purchasing Queue with supplier quote, delivery context and accountability
The Record Stays Together

A decision becomes a complete handoff.

Operations can find the supplier, quote, delivery needs, and purchasing owner without reconstructing the request from fragmented emails or chat messages.

When Context Is Missing

Clear feedback without discarding.

The reviewer can request changes. The requester returns to the existing record with the exact question visible; the draft is never discarded.

07 / Arabic — Designed In Its Own Direction

The same task.A native reading order.

وضوح في كل موافقة.

Arabic is not an afterthought or an auto-translation. It is a complete, first-class product experience with native RTL navigation, Saudi date/currency standards, and typographic breathing room.

PACT Arabic RTL Purchasing Interface: إعداد طلبك, SAR 8,400 currency formatting and Noto Sans Arabic typography

Modern Standard Arabic · Saudi date and currency formatting · Noto Sans Arabic · Same request and workflow state

[08]Localization Beyond Translation

Mirror the structure.Respect the content.

Layout direction and content direction are separate decisions. The design mirrors navigation and action order while preserving the integrity of identifiers, filenames, and supplier names.

Design RuleEnglish (LTR)العربية (RTL)
Reading orderLeft navigation, first table column on the leftالتنقل على اليمين، والعمود الأول على اليمين
Currency formattingSAR 8,400.00٨,٤٠٠,٠٠ ر.س.
Date formatting28 Oct 2026٢٨ أكتوبر ٢٠٢٦
Stable identifierPR-1042PR-1042 (Latin alphanumeric preserved)
Attached filenamenorthline-quote.pdfnorthline-quote.pdf (Direct file integrity)
Workflow status chipAwaiting approvalبانتظار الموافقة
Layout

Use logical relationships.

Place leading content on the reading-start edge. Mirror directional arrows and action order; keep brand artwork and non-directional icons unchanged.

Typography

Give Arabic room to read.

Noto Sans Arabic uses its own line-height scale and zero tracking. Components allow longer labels without squeezing or truncating the meaning.

Data

Keep one source of truth.

Format amounts and dates from data for each locale. Keep Latin references in their own directional run and preserve request context when changing language.

[09]Accessibility As A Design Input

Make the state visible.Make the action clear.

Focus, errors, and status changes need more than subtle color tints. The component specifications define explicit labels, written feedback, readable contrast, and generous primary action targets.

PACT Accessibility & Focus States: Bilingual input validation, explicit error text, and 48px touch targets
Contrast

Choose readable pairs.

White on Blue: 6.71:1. Muted text on White: 5.30:1. The status palette pairs dark labels with pale surfaces for effortless readability.

Interaction

Specify the whole target.

Primary buttons are 48 px high. Handoff notes specify logical keyboard order, semantic aria-labels, and associated error text.

Status

Write what changed.

Draft, awaiting approval, approved, and info requested each carry a written label and icon. Color reinforces state instead of carrying it alone.

[10]Validation Plan

Can the next step be found?

The prototype was prepared for moderated usability testing in English and Arabic to examine task completion, ownership recognition, review confidence, and mixed-direction interpretation.

01
Continue PR-1042 and verify the amount
Can the requester identify the draft and confirm twelve chairs at SAR 8,400?
02
Find the reviewer before sending
Does the route make the next owner clear before the final commitment?
03
Approve or request missing information
Can the approver find the quote and choose the appropriate action?
04
Find the approved purchasing handoff
Can operations identify the supplier, delivery need and purchasing owner?
05
Change language during the active task
Do users retain context and correctly interpret IDs, dates, totals, and action order?

[11]A Usable Design Handoff

From screensto implementation.

Localized components, typography styles, and design tokens support the interface. The handoff documents the interactive states and behaviors that static artboards cannot convey.

Product System

Components with context.

English and Arabic buttons, inputs, navigation, request rows, and status chips with focus, validation, and disabled treatments included as reusable assets.

Localization

Direction is explicit.

Use lang and dir at the application boundary, logical spacing, and content-aware directional isolation to preserve workflow state across language switches.

Implementation

Behavior is specified.

Headings, table headers, form labels, errors, keyboard tab order, and screen-reader announcements are documented for frontend parity.

PACT / Product Design + RTL Localization

One shared record. Every role aligned.

طلب واحد. وضوح لكل دور.

A coherent purchasing platform designed to make requests, decisions, and operations handoffs completely understandable — in both directions.

Next case study

Aura Threads E-commerce Storefront

An eco-conscious high-street brand's storefront, with the energy of a fashion magazine and checkout built for conversion.

View project