Designing the conversation, not just the translation.
A browser-based workflow for face-to-face multilingual conversation, shaped by explicit turn-taking and testing under real conditions.
Working, field-tested MVP · Documentation-only public case study
I identified the product problem, designed the conversation workflow, made product/system decisions, used AI-assisted implementation, tested real-world behavior, reviewed failures and iterated the product.
- Conversation problem
- Explicit turn-taking
- Translation workflow
- Café field observations
Conversation has a workflow.
When two people do not share a language, the problem extends beyond translating a sentence. They need a clear way to take turns, understand when to speak, and continue while waiting for the result.
PyxMint explores this face-to-face communication problem through a practical browser-based MVP. The focus is the whole exchange: people, speaking actions, noisy surroundings and conversational pacing.
Who speaks next? What happens while they wait?
Unclear turns, noisy input and interruptions can make a conversation difficult to follow. A usable workflow needs to make the speaking action explicit and account for the time between a contribution and the next turn.
These are design concerns, not measured claims of time saved or errors reduced.
Make each speaking turn explicit.
The product was designed around push-to-talk rather than an unrestricted always-listening model. A participant contributes a turn in the browser; the translation function supports the exchange; participants continue with the next turn.
An optional transcript and a usage allowance based on active speaking time are part of the documented product scope. Their presence does not establish storage, retention or reliability guarantees.
- Use an explicit push-to-talk speaking action.
- Allow the translated exchange to complete.
- Continue with the next participant’s turn.
Product decisions with questions still to test.
- Browser-based interaction: a shared surface for face-to-face exchanges. Browser and device conditions still need a structured test matrix.
- Push-to-talk: an explicit speaking action. Turn length remains an important usability question.
- Optional transcript: a choice within the conversation workflow. Its usefulness for continuity needs further testing.
- Active-speaking time allowance: usage framed around speaking time. No quantities, pricing rules or private implementation details are disclosed here.
- Five-language scope: Persian, Armenian, English, German and Russian. This is not evidence of equal quality or validation of every language direction.
The diagram describes functional boundaries, not internal routes, provider orchestration or deployment architecture.
Direction, review and validation remain the work.
I used AI-assisted implementation to support the workflow and product decisions, then reviewed behavior, tested real-world use and iterated the product.
This case study demonstrates problem-solving and system delivery. It does not use coding volume as a proxy for value or imply independent hand-coding of every component.
Take the workflow into real conditions.
Café field testing in Gyumri brought the MVP into a noisy, face-to-face setting. The available evidence is qualitative: observations about input, sentence starts and waiting during longer turns.
Comparisons with synthetic Armenian input helped identify questions for further testing. They were not a controlled accuracy or latency benchmark.
What the field test exposed.
- Noisy input was a practical condition during café use.
- Some Armenian → Persian attempts showed sentence-start issues.
- Synthetic Armenian input performed better than some live/noisy attempts.
- Longer turns created more noticeable latency.
Observed failures informed the next decisions.
I reviewed failures and iterated the product around its conversation workflow. The public record supports that process, but does not establish a version-by-version change log or prove that a particular defect was fixed.
Turn-taking, noisy input and the experience of waiting remain explicit design and validation concerns. Specific remedies and causal explanations are intentionally not asserted.
A useful MVP with bounded evidence.
- Field evidence is qualitative and limited to the documented observations.
- Five supported languages do not imply equal performance or all-directions testing.
- No quantified accuracy or latency results are available here.
- Production maturity, commercial traction and production-scale reliability are not established.
- Application source, real transcripts and private operational data are excluded.
Make the next evaluation repeatable.
A proposed test matrix would vary language direction, quiet versus noisy input, live versus synthetic input, shorter versus longer turns, and browser/device conditions.
The aim is to document repeatable observations and failure paths before making stronger performance claims. These tests are future work, not completed coverage or promised results.
Working, field-tested MVP.
The public repository contains documentation, conceptual diagrams, qualitative café observations and a proposed test matrix. It is a documentation-only case study; the application implementation is not public.
© 2026 Farshid Ghaffari. Documentation and diagrams are presented as portfolio/reference material. Reuse or redistribution requires permission.
One example of a broader systems capability.
PyxMint is designed to reduce friction in multilingual face-to-face exchanges by making the conversation workflow explicit. Its practical focus is usability around turn-taking, noisy input and waiting; no measured time, cost or ROI benefit is claimed.
This case study is one example of my work in workflow design, practical business systems and testing under real conditions. The same approach starts with the problem, defines constraints, shapes the workflow and validates the result.
For a delivered operational-system example, see Industrial Operations Automation.
Where does your workflow lose clarity?
Describe the current process, the people involved and where work gets stuck. We can discuss what a practical first system should do.