# DIREKT Design DNA Brief and Flagship Review Contract

**Programme:** VC1–VC8 world-class modernization  
**Governing issue:** #259  
**Status:** Three differentiated directions defined; final visual direction requires explicit owner approval during VC2  
**Primary surfaces:** Android, customer/provider web/PWA, privileged operations portal

## 1. Purpose

This brief controls high-fidelity visual exploration and the owner approval checkpoint before broad design propagation.

It does not authorize a replacement application or generated business logic. Existing canonical API, database, authorization, trust, privacy, payment and release controls remain authoritative.

## 2. Target character

DIREKT must feel:

- world-class and current;
- trustworthy but not governmental;
- local, human and Zambia-relevant without looking informal or low-budget;
- visually rich enough to feel like a real marketplace;
- precise around trust, verification and limitations;
- fast and task-oriented;
- accessible and low-bandwidth aware;
- consistent across Android/PWA/operations while allowing platform-native adaptation;
- AI-assisted without looking like a chatbot product.

Avoid:

- blanket `Verified` badges;
- decorative trust seals;
- generic fintech/glassmorphism;
- generic SaaS dashboard treatment for customer/provider journeys;
- luxury styling that suggests exclusivity;
- large marketing heroes that delay service discovery;
- primitive glyph navigation;
- developer/API/workstream labels;
- AI sparkle/robot decoration without clear function;
- AI-generated claims that appear equivalent to canonical trust decisions.

## 3. Composite global benchmark

Use benchmark capabilities rather than literal visual copying:

- Urban Company — marketplace maturity, provider professionalism and service-quality presentation;
- Checkatrade — visible trust/rechecking proposition;
- Taskrabbit — short customer path from need to provider/action;
- Thumbtack — AI-guided natural-language/multimodal project discovery;
- DIREKT — check-specific proof, privacy-by-precision, payment-independent trust, Africa-first resilience and human-accountable operations.

## 4. Immutable trust DNA

Every direction must preserve:

- service fit/locality before promotional storytelling;
- individual check states rather than one global verification badge;
- what was checked;
- check scope/category where relevant;
- date/currentness/expiry;
- limitations/what the result does not prove;
- public-safe source class where appropriate;
- commercial/payment state in a separate visual family;
- private evidence never used as public imagery.

Provider imagery can create confidence and context, but it must never visually overpower or substitute for proof.

## 5. Privacy DNA

Public-safe design content may include approved:

- provider display identity;
- service/category;
- public locality/service area;
- consented premises location;
- public work/premises imagery;
- public trust claims;
- reviews;
- availability.

Never expose in prototypes/creative tools/public screenshots:

- real identity/certificate evidence;
- storage object references;
- exact private base locations;
- unconsented contacts;
- private reviewer notes;
- secrets/tokens;
- real complaint/evidence material.

Use synthetic fixtures.

## 6. Accessibility and resilience DNA

Every direction demonstrates:

- readable body typography;
- 48dp-class primary interaction targets;
- keyboard/focus/TalkBack/screen-reader semantics;
- status not colour-only;
- 200% scaling/reflow;
- reduced motion;
- map/list equivalence;
- low-bandwidth imagery fallback;
- loading/empty/error/offline/retry;
- AI unavailable/manual fallback;
- no critical action dependent on image or AI alone.

## 7. AI experience DNA

AI should appear as bounded assistance embedded in the task.

Required patterns:

- `Describe what you need` composer;
- clarifying-question chips/cards;
- editable suggested category/query;
- `Why this result` explanation;
- provider comparison summary;
- provider onboarding assistant;
- operations case copilot;
- AI unavailable/manual fallback.

Visual hierarchy must distinguish:

1. user-entered facts;
2. canonical DIREKT facts;
3. AI-generated suggestion/summary;
4. user-confirmed content;
5. human-authorized outcome.

Never style AI output as a trust-success state.

## 8. Direction A — Structured Trust

**Intent:** calm, precise, confident marketplace with strongest information architecture and proof presentation.

### Visual character

- crisp neutral surfaces;
- deep ink typography;
- restrained green;
- moderate radii/elevation;
- generous whitespace;
- compact semantic iconography;
- supporting provider photography;
- trust cards that feel understandable and authoritative without becoming government forms.

### Customer

- compact search + area first;
- clean category tiles;
- provider cards with one strong work image, service/locality, availability and two trust snippets;
- provider profile puts `What DIREKT checked` immediately after identity/service;
- results use list-first fallback and desktop list/map split.

### Provider

- task-oriented readiness;
- `Next actions`, `Services & availability`, `Enquiries`, `Publication status`;
- vertical evidence requirement/timeline;
- calm action-required states.

### Operations

- dense three-pane queue/case/evidence-decision workspace;
- evidence central;
- neutral surfaces with semantic accents;
- strong keyboard/focus treatment.

### AI

- minimal assistant chrome;
- suggestions appear as precise contextual panels rather than conversational bubbles;
- strong separation between generated synthesis and canonical facts.

### Strengths

- strongest trust transparency;
- accessibility/low bandwidth;
- easiest cross-platform consistency.

### Risk

Can feel clinical unless imagery and copy add warmth.

## 9. Direction B — Neighbourhood Marketplace

**Intent:** warmer, more human and visually rich while keeping proof immediately accessible.

### Visual character

- brighter natural provider/work imagery;
- Zambia-relevant illustrated/photo category moments;
- warmer neutral surfaces;
- softer card shapes;
- stronger local marketplace personality.

### Customer

- friendly location context;
- visually rich category grid/mosaic;
- image-led provider cards with trust snippets directly below identity/service;
- provider profile uses stronger gallery/story but trust summary remains above reviews/storytelling.

### Provider

- welcoming business identity header;
- visual task/readiness cards;
- `What needs attention`, `Your services`, `New enquiries`, `How customers see you`.

### Operations

Consumer warmth is reduced. Operations remains structured and evidence-first with only modest softer surfaces.

### AI

- more conversational wording and approachable prompts;
- visual suggestions remain compact and confirmable;
- no cartoon assistant persona.

### Strengths

- strongest marketplace warmth and provider humanity;
- improves first impression and category discovery.

### Risk

Imagery may overpower proof or increase bandwidth unless tightly governed.

## 10. Direction C — Field Utility

**Intent:** fast, efficient, service-first product optimized for task completion, field use and operational density.

### Visual character

- flatter UI;
- fewer decorative containers;
- grouped rows and compact cards;
- strong labels and scan patterns;
- minimal decorative imagery outside customer discovery/profile.

### Customer

- extremely fast search/category/area entry;
- compact provider result rows/cards;
- list/map controls prominent;
- trust snippets highly scannable.

### Provider

- dashboard resembles an efficient business task center;
- strong pending-action queue;
- evidence and enquiry workflows optimized for one-hand mobile use.

### Operations

- strongest dense keyboard-driven queue/case review;
- table/list efficiency;
- evidence and decision always contextually adjacent.

### AI

- inline suggestions and command-like assistance;
- minimal conversational UI;
- ideal for operator summarization/checklist assistance.

### Strengths

- fastest low-bandwidth/task completion;
- strongest provider/operations efficiency.

### Risk

Can feel too enterprise/utility-like for customer marketplace discovery.

## 11. Recommended hybrid candidate for review, not pre-approval

A potentially strong combination to test is:

- A — trust hierarchy, semantic clarity, accessibility;
- B — category/provider imagery, marketplace warmth and local identity;
- C — provider workspace and operations density.

This is a hypothesis only. The owner must explicitly approve the final direction after seeing the same flagship scope rendered across candidates.

## 12. Required VC2 flagship review set

Each candidate direction renders the same seven experiences.

### Customer

1. **Discover/Home**
   - search;
   - area;
   - category discovery;
   - relevant provider preview;
   - concise trust education;
   - compact and desktop navigation.

2. **AI-assisted service-need entry**
   - natural-language problem description;
   - optional future photo/voice affordance shown only as concept if not runtime-active;
   - clarifying suggestion;
   - confirm/edit/manual category fallback;
   - AI unavailable state.

3. **Search results + map/list**
   - query/category/area context;
   - filters;
   - privacy-safe map/list equivalent;
   - provider cards with imagery/locality/availability/scoped trust;
   - explainable relevance treatment.

4. **Provider profile + trust detail**
   - public imagery separated from evidence;
   - services/coverage/availability;
   - check-specific trust summary/details;
   - dates/scope/limitations;
   - reviews;
   - save/share/enquiry.

### Provider

5. **Provider workspace/overview**
   - readiness;
   - next actions;
   - services/availability;
   - enquiries;
   - publication state;
   - commercial state separate from trust.

6. **Verification/evidence status**
   - requirements/timeline;
   - upload/retry;
   - action required;
   - expiry;
   - private evidence explanation;
   - optional AI quality assistance concept clearly labelled.

### Operations

7. **Verification queue + case/evidence review**
   - desktop queue/case/evidence-decision composition;
   - priority/SLA/ownership;
   - secure synthetic evidence state;
   - checklist/reason/decision;
   - audit/history;
   - AI summary/checklist assist clearly secondary;
   - compact triage/field sample.

## 13. Required variants

- compact/mobile customer/provider;
- expanded desktop customer/provider web;
- tablet/adaptive where composition materially changes;
- desktop operations review;
- compact operations triage/field;
- representative loading;
- empty/no results;
- error/offline;
- AI unavailable/manual fallback;
- dark state where required by final theme policy.

## 14. Owner decision record

VC2 exits only when exactly one is recorded:

- `APPROVE DIRECTION A`;
- `APPROVE DIRECTION B`;
- `APPROVE DIRECTION C`;
- `APPROVE HYBRID` with exact elements borrowed;
- `REVISE` with concrete required changes.

Silence or implementation convenience is never approval.

## 15. Design tooling contract

### Google Stitch

Use as the primary high-fidelity exploration source for:

- candidate directions;
- flagship screens;
- mobile/desktop/adaptive variants;
- visual Design DNA extraction.

Generated code/design metadata is advisory until reconciled with repository authority.

### Higgsfield

Use only as a secondary creative layer for:

- category concepts;
- generic provider/work imagery;
- illustrations;
- moodboards/store assets.

Never send private evidence, real participant data, raw contacts, exact private locations, restricted operations screenshots or secrets.

## 16. Implementation handoff

After owner approval:

1. record the approved reference/project/screens;
2. extract/reconcile Design DNA;
3. map tokens/components to existing Compose/web/operations stacks;
4. document rejected patterns;
5. create synthetic-safe visual baselines;
6. proceed VC3 onward in bounded exact-head tested slices.

No design tool may redefine canonical business logic, trust policy, authorization or integration truth.