Design workflow

Akram designs every interface in Claude Design over 21 working days — the design system first (days 1–4), the screen inventory validated with both developers on day 5, then the reseller app, the delegate app, the back-office and the reseller web, and the handoff on day 21 (cahier §14, phase 2 UX/UI). Then come one client feedback round (DES-22), the assets and templates, and design QA of each build. This page is the process. The content lives in the design plan, the design system, the screen inventory and the handoff pages.

Claude Design organisationCopy Anchor Link

• Claude Design projects under "HOCO B2B", owned by Akram. DES-01 creates the projects: Design system, Reseller app, Delegate app, Back-office, Reseller web, Prototypes. Each surface project has a Review page, the only page HOCO comments on.
• Frames are named by screen id from the inventory, then the state: RA-18 Checkout — default, RA-18 Checkout — error. States: default, loading, empty, error, offline, no-permission (back-office), success. Each state that looks different has its own frame.
• Both directions are linked. Each frame's description links its spec page (/docs/design/screens/reseller-app/ordering#ra-18), and each spec page links its frame.
• Tokens in Claude Design are named exactly like the code tokens in packages/ui and hoco_ui, and exported as the token file hoco.tokens.json. A token renamed in Claude Design is renamed in code in the same week.
• The 16 client reference screens (reference screens) are inputs. They are not validated designs.

StatusesCopy Anchor Link

A screen has a design status, shown as a prefix on the Claude Design section that holds its frames ([Ready for dev] RA-18 Checkout).

The plan schedules each app task right after its design day, before HOCO's validation sessions. Developers therefore build from Ready for dev, and HOCO's feedback arrives as tracked changes. That is why the feedback is consolidated into a single round per surface.

The 21-day plan and its checkpointsCopy Anchor Link

21 tasks · 21 d of open effort. Dates are computed — Sunday–Thursday weeks, holidays excluded.

Daily feasibility checkCopy Anchor Link

Every design day at 15:30, for 15 minutes: Akram and the developer of the platform designed that day.

Agenda:

1. Akram walks the day's frames (5 min).
2. The developer flags problems (5 min): data the API catalogue does not provide — the contract is being written during these same days (SRV-03) —, offline constraints of the delegate app, platform limits (native pickers, maps, camera, scanner), performance (long lists, image weight), missing states.
3. Decide (5 min). Akram sets Ready for dev on what passed.

Outputs: comments on the shared design resolved or turned into issues; a contract need goes to Anis the same day; a scope question goes to the decision register — it is never settled in the call. If the developer cannot attend, Akram posts the frame links by 15:00 and the developer answers in comments on the shared design before 10:00 the next morning.

Handoff packageCopy Anchor Link

A surface is handed off when every box is ticked (content on the handoff page):

• Every screen of the surface in the inventory is Ready for dev, with all its states.
• Only design-system components and tokens are used; a new component is added to the library and announced to both developers.
• Tokens v1.0 tagged; the Claude Design tokens equal the code token names.
• Real French copy everywhere, including error and empty messages; long texts and Arabic (RTL) noted on the key screens.
• Interactions annotated: navigation, validation rules, disabled states, gestures, offline behaviour.
• Assets exported and named (SVG icons, WebP images, illustrations); app icons and splash screens come with DQA-01.
• Prototype links for the main flows (reseller ordering, delegate visit day).
• The screen spec pages link their frames.
• Open questions are entries in the decision register, not design comments.

Design QA loopCopy Anchor Link

Each build is reviewed against the Claude Design handoff: DQA-02 (reseller app), DQA-03 (delegate app, including outdoor readability on a real phone), DQA-04 (back-office on desktop, tablet and large screens), DQA-05 (reseller web), DQA-12 (V2). Mobile fixes are batched in MOB-17.

5 tasks · 5 d of open effort. Dates are computed — Sunday–Thursday weeks, holidays excluded.

1. Trigger. The developer reports the surface done (definition of done) and on staging, or in the App Distribution build for mobile.
2. Review. Akram compares each screen with its frames, on the reference devices.
3. File. One issue per problem, in the repository of the surface, labelled design-qa, titled with the screen id ([RA-18] Primary button is 44 px high instead of 48), with the Claude Design link and a screenshot of the build next to the frame. Severity:
   • Major — wrong flow, missing state, wrong component, accessibility failure, illegible outdoors;
   • Minor — spacing, colour, icon, copy typo.
4. Fix. The developer fixes in batches; Akram re-checks within one working day.
5. Pass. A surface passes when no Major issue is open; Minors may stay scheduled. Akram marks the frames Completed.

Changing a design after handoffCopy Anchor Link

• Nobody implements a design change from a chat message, a call or a screenshot.
• A change is a GitHub issue labelled design-change, in the repository of the surface (hoco for the back-office and the reseller web, hoco-mobile for the apps), with: the screen ids; what changes and why (client feedback, feasibility, bug, pilot learning); the Claude Design link to the new version of the frame (Akram keeps the previous version next to it, named RA-18 Checkout v1.1, until it is built); the impact the developer estimates on tasks and on the contract; the decision.
• Anis decides, because he owns the plan. If the change alters validated scope or adds effort beyond the task's estimate, it becomes a change request.
• While the issue is open, the section reads Changed — #n; it returns to Ready for dev when the new version is final.
• Conformance problems found in design QA are not design changes: they are design-qa issues.

Client validation of the designsCopy Anchor Link

• People. HOCO names one project lead who consolidates feedback into one voice, and the people who attend each session: sales management for the reseller app; the field manager and one delegate for the delegate app; the commercial, stock, finance and delivery managers for the back-office. Akram leads the sessions, Anis attends all of them (scope), Imad attends the mobile ones.
• Sessions. One per surface at its milestone (reseller app, delegate app, back-office; the reseller web at the handoff presentation), 60 to 90 minutes, driven by the prototype.
• Feedback. HOCO sends one consolidated list per surface within 3 working days, as comments on the file's Review page or with the template below.
• One round per surface. Akram and Anis classify each item: an in-scope adjustment (done in DES-22), a change request (new scope), or declined with a reason (it contradicts the cahier or a recorded decision). The revised designs are shown in a short session, and HOCO's project lead validates by email (« Validé »). The frames become Validated v1.1.
• After validation, any further change is a change request.

Surface: Application revendeur — session du YYYY-MM-DD
Consolidé par : <nom, fonction>

| # | Écran | Remarque | Pourquoi | Priorité (indispensable / souhaitable / optionnel) |
| 1 | RA-18 | Afficher le mode de paiement choisi au-dessus du total | Les clients se trompent au téléphone | indispensable |